2009-09-17 34 views
12

Tôi đang viết một ứng dụng máy chủ Java khá phức tạp có phần xử lý nền quan trọng ngoài việc xử lý yêu cầu-phản hồi thông thường. Một số xử lý nền được thực hiện theo kiểu cron giống như sử dụng khung Quartz. Các tác vụ khác có nhiều yêu cầu hơn - nếu một khách hàng mới kết nối nó sẽ tạo thêm công việc để cập nhật nó một lần trong một thời gian. Các tác vụ cron cũng có thể thay đổi - một số làm theo dõi các ứng dụng bên ngoài, một số tính toán số liệu thống kê và vv.Một hoặc nhiều nhóm luồng cho máy chủ Java?

Tôi đang sử dụng một số nhóm luồng để chạy tất cả các công việc đó với ý tưởng rằng các công việc tương tự sẽ chia sẻ một nhóm luồng nhưng các công việc khác nhau sẽ không chia sẻ. Ví dụ các công việc giám sát sẽ không bao giờ chạy trên nhóm thống kê, và các công việc thống kê sẽ không bao giờ chạy trên màn hình.

Mặt khác, tôi biết một số người thích chỉ để có một hồ bơi chủ đề duy nhất và chạy mọi thứ trên đó mà không có bất kỳ sự tách biệt nào.

Tôi tự hỏi điều gì được coi là thực tiễn tốt nhất trong kịch bản như vậy.

Ưu điểm của nhược điểm khi tách các nhóm luồng là gì?

Liệu nó có quan trọng không?

+2

+1 câu hỏi thú vị. – KLE

Trả lời

0

Nó không thực sự là một câu trả lời trực tiếp, nhưng đề nghị khác :-(

việc Quartz của bạn có thể được tạm dừng, hủy bỏ và như vậy, chúng ta hãy gọi nó là "quản lý". Tôi đoán bạn sẽ tạo ra một số giao diện người dùng để

Bạn có nhận ra rằng các công việc khác của bạn ("theo yêu cầu") sẽ không được hưởng lợi từ các chức năng tương tự, trừ khi bạn thực hiện tất cả? Bạn có xem xét việc làm mọi thứ bằng công việc thạch anh (ngay cả khi nó bắt đầu ngay lập tức), để lấy mã thống nhất?

+0

Thực ra đó là một trong các tùy chọn. Mặc dù vậy, có hai vấn đề - một là AFAIK Quartz buộc phải sử dụng một nhóm luồng đơn - trong khi sở thích cá nhân của tôi là sử dụng nhiều. Thứ hai là Quartz API là tuyệt vời từ công việc loại cron nhưng cồng kềnh khi bạn chỉ cần nhanh chóng chạy một số thuật toán song song. –

+0

@Gregory Tôi hiểu mối quan tâm của bạn đối với số hồ bơi của chuỗi. Tôi không có đề nghị để thực hiện vào thời điểm này :-(Về Quartz cồng kềnh, đó là chính xác như thế nào tôi cảm thấy khi tôi làm việc với nó !! :-) Tôi đã đóng gói này vào một phương pháp đơn giản làm tại nhà. – KLE

+0

Để thẳng thắn, chúng tôi cũng gặp rắc rối với Quartz trên một cụm. Công việc bắt đầu ở bất cứ đâu, không phải trên máy chủ đang xử lý yêu cầu.Tôi nghĩ rằng Quartz được bắt đầu trên nút đầu tiên mà là lên, và rằng các nút khác không bắt đầu nó. Điều này dẫn đến một số vấn đề ... – KLE

6

Câu trả lời phụ thuộc vào việc bạn có cần phân tách tài nguyên ứng dụng giữa các loại hoạt động khác nhau hay không.

Ví dụ: Tôi hiện đang viết một ứng dụng máy chủ bao gồm một vài nhà văn thông lượng cao và nhiều người đọc tiềm năng. Người đọc sẽ truy cập vào ứng dụng một cách không thường xuyên nhưng có khả năng có thể yêu cầu nhiều dữ liệu (nghĩa là yêu cầu đang chạy dài). Tôi cần phải đảm bảo rằng các nhà văn không bao giờ bị bỏ đói vì vậy sẽ sử dụng hai hồ bơi thread trong thiết kế của tôi để đọc/viết. Nếu hồ sơ chủ đề đọc tạm thời cạn kiệt thì các tác giả sẽ không bị ảnh hưởng; chỉ các yêu cầu đọc sẽ bị trì hoãn.

Cách khác là sử dụng số PriorityQueue kết hợp với số ThreadPoolExecutor và chỉ định mức ưu tiên cao hơn để viết yêu cầu.

Vì vậy, trong kết luận - Lời khuyên của tôi sẽ là: Bắt đầu với một hồ bơi thread và chỉ làm cho thiết kế của bạn phức tạp hơn nếu có một lý do cụ thể để làm như vậy.

Các vấn đề liên quan