Play Framework: Tác động của Jobs trên mô hình không quốc tịch

Question

Một trong những điều tuyệt vời về khung chơi là nó hoàn toàn không trạng thái và chỉ yêu cầu/trả lời theo định hướng. Điều này thực sự tốt đẹp vì nó cho phép tôi triển khai ứng dụng của mình lên đám mây và mở rộng số lượng các bản sao phát sau cân bằng tải của tôi mà không phải lo lắng về bản sao trạng thái (phiên) ...

Gần đây, tuy nhiên, tôi cần thực hiện một số logic ứng dụng bên ngoài yêu cầu HTTP và phát hiện ra rằng Play có khả năng xác định Công việc được quản lý hoàn toàn bởi khung công tác. Âm thanh rực rỡ nhưng nó đặt ra câu hỏi: làm thế nào để những công việc này phù hợp với mô hình không quốc tịch được Play sử dụng?

Giả sử tôi có nhiệm vụ bảo trì cần chạy mỗi giờ và tôi xác định công việc đã lên lịch cho điều đó. Nếu sau đó tôi triển khai nhiều phiên bản Play phía sau bộ cân bằng tải, công việc đó có được bắt đầu cùng một lúc trên mỗi phiên bản không? Và nếu như vậy, cách tiếp cận tốt để xử lý các công việc cần phải chạy "độc quyền" là gì?

Tôi đã nghĩ đến việc tạo một cá thể phát mới trên máy chủ không được nhóm, tái sử dụng mô hình JPA của cá thể hiện có (nhóm) (và do đó kết nối với cùng một cơ sở dữ liệu). Ví dụ mới này sẽ chỉ chứa các công việc bảo trì và vì nó được lưu trữ trên một máy chủ không được nhóm, không có nguy cơ một công việc chạy cùng một lúc. Đồng thời, điều này sẽ cho phép tôi giữ cho trường hợp hiện tại, nhóm của tôi hoàn toàn không quốc tịch và dễ dàng lưu trữ/cân bằng tải. Đây có phải là một cách tiếp cận tốt không?

Answer 1

Tôi cũng khuyên bạn nên nhóm công việc. Bạn có thể đặt một semaphore trong cơ sở dữ liệu để đảm bảo rằng chỉ có một công việc đang chạy. Một ý tưởng khác là xem xét Khung công tác Akka, sẽ được đưa vào Play 2.0. Tôi nghĩ rằng nó đã xây dựng trong cơ chế với xử lý vấn đề này, nhưng tôi không chắc chắn. Tôi không có kinh nghiệm với akka.

Answer 2

Như neils đã đề cập việc giữ một lá cờ trong DB giúp tìm hiểu xem công việc đã chạy chưa. Tôi sử dụng một semaphore db với cờ khác để cho tôi tình trạng công việc và thông tin thêm.

Một điều bạn có thể làm là sử dụng Play.id để làm việc và xác định cá thể nào sẽ chạy công việc. Chúng tôi sử dụng "chơi bắt đầu -% sản", "bắt đầu chơi -% prod1" ... để bắt đầu ứng dụng và sau trong doJob của tôi) phương pháp (:

doJob(){ 
    if ("prod".equalsIgnoreCase(Play.id)) { 
    ... 
    } 
} 

Answer 3

Sau khi đã có một cái nhìn nhanh chóng vào mã nguồn của Play Framework (các lớp Job và JobsPlugin) Tôi nghĩ những điều này không phù hợp để sử dụng trong môi trường cụm khi điều quan trọng là Công việc chỉ chạy một lần trong một khoảng thời gian nào đó (không giới thiệu các hacks xấu xí).

tôi thấy ba giải pháp khả thi:

1. Sử dụng một lịch trình công việc mà hỗ trợ clustering. Lựa chọn hiển nhiên là Quartz. Play cũng sử dụng các phần của Quartz (để phân tích các biểu thức CRON), nhưng không phải là phần lập lịch biểu.

2. Khi sử dụng Play 2, có thể đi theo số Akka, cung cấp a scheduler.

3. Thay đổi công việc của bạn sao cho nó không quan trọng khi nó được chạy hai lần (có thể cho một số trường hợp sử dụng).