Viết một công việc duy nhất. Để nó thực thi thường xuyên.
Một cách hiệu quả, bạn sẽ thực hiện một số việc có tính chất:
SELECT count(*) FROM table WHERE new = 1;
(hoặc bất cứ điều gì)
Chạy như vậy mỗi giây, 5 giây, 10 giây, bất cứ điều gì có vẻ hợp lý dựa trên hoạt động của bạn.
Khi đếm ==N, hãy chạy quy trình của bạn. Khi "thời gian kể từ lần chạy cuối cùng" ==5 phút, hãy chạy quy trình của bạn.
Quá trình này giống nhau, bạn chỉ cần kiểm tra nó thường xuyên hơn với hai tiêu chí.
Điều này mang lại một lợi thế là bạn sẽ không gặp phải tình trạng chạy đua bất hảo trong đó công việc sa thải TWICE (vì Công việc A đã tìm thấy số lượng chèn chỉ xảy ra là 5 phút kể từ khi công việc cuối cùng chạy). Hiếm thì có, nhưng các điều kiện về chủng tộc dường như luôn tích cực tìm kiếm các sự kiện "hiếm" mà "không bao giờ xảy ra".
Đối với việc lập lịch, crontab rất dễ dàng vì bạn không phải duy trì quy trình của mình, giữ cho nó tồn tại, daemonize, v.v.
Nếu bạn đang chạy trong một vùng chứa đang hoạt động lâu dài (máy chủ ứng dụng, tomcat, v.v.) thì vấn đề đó đã được giải quyết và bạn chỉ có thể tận dụng điều đó.
Nhược điểm của cron là tính chi tiết, nó chỉ chạy nhiều nhất mỗi phút. Nếu điều đó quá lâu, nó sẽ không hiệu quả với bạn. Nhưng nếu nó ổn, thì có giá trị thực sự trong việc có một quy trình đơn giản chỉ sáng lên, kiểm tra và thoát. Tất nhiên, nó sẽ phải duy trì trạng thái của nó bằng cách nào đó (ví dụ:nó có thể xem trong nhật ký công việc để xem khi nào công việc cuối cùng chạy).
Trong java, có rất nhiều tùy chọn:chủ đề thô, đang ngủ, Bộ hẹn giờ, SchedisedExecutorService, một cái gì đó như Quartz, EJB Timer bean (nếu bạn đang chạy một vùng chứa Java EE).
Nhưng, tôi là một fan hâm mộ của KISS. Nếu một công việc cron có thể làm được, hãy để nó và làm nó một lần.
