Đề xuất về cách tổ chức Hàng đợi trong Nhà môi giới dịch vụ

Tôi có một ứng dụng môi giới dịch vụ hiện có 5 hoặc 6 hàng đợi trên hai máy chủ.

Quy trình công việc chung là:

Máy chủ A

• Người dùng điền vào một số bảng
• Người dùng kích hoạt Proc được lưu trữ, đặt một thông điệp vào hàng đợi tiêu đề cho biết có nhiều việc phải làm
• Nhà môi giới đọc từ hàng đợi tiêu đề này và tạo ra một số lượng lớn thư có thể gửi đến Máy chủ B

Máy chủ B

• Tất cả tin nhắn đi đến 1 hàng đợi
• Trong hàng đợi này, thông báo được kiểm tra và giải nén, tải trọng được chạy và phản hồi được thu thập từ một tập hợp các procs / bảng khác mà chúng ta tương tác
• Thông báo phản hồi được tạo và gửi lại cho Máy chủ A

Máy chủ A

• Thông báo phản hồi đi đến một hàng đợi đặc biệt và được sử dụng để cập nhật các bảng mà người dùng cư trú ở trên cùng
• Thông báo hộp thoại kết thúc được đọc từ hàng đợi của người khởi tạo và được sử dụng để cập nhật một bảng khác theo dõi tiến trình của bản ghi tiêu đề (tức là 50 trong số 100 tin nhắn được xử lý)
• Khi chúng tôi phát hiện ra rằng bản ghi tiêu đề đã được xử lý hoàn toàn, một tin nhắn mới sẽ được gửi đến một hàng đợi khác gửi email thông báo

Tôi đã có một đề xuất để hợp nhất một số hàng đợi trên Máy chủ A và tôi không chắc cách thực hành tốt nhất cho việc này là gì. Hai trong số các hàng đợi sẽ có khối lượng xử lý thư tương đối cao và hàng đợi email sẽ khá chậm.

Chúng tôi đã làm (tôi nghĩ) một công việc tốt trong việc quản lý các loại tin nhắn nên về mặt lý thuyết chúng tôi có thể đặt tất cả vào một hàng đợi và ứng dụng vẫn hoạt động.

Có cách thực hành tốt nhất về thời điểm duy trì hàng đợi riêng biệt và khi nào hợp nhất trong một kịch bản như thế này?

Đây là một câu hỏi mở không có sự lựa chọn rõ ràng. YMMV vì vậy bạn phải kiểm tra. Đây là ý kiến ​​của tôi:

Có một hàng đợi để xử lý mọi thứ là một lựa chọn tốt nếu bạn muốn có thể kiểm soát số lượng tác vụ được kích hoạt, vì không có max_queue_readers toàn cầu. Ngoài ra, tôi không thấy nhiều lợi thế. Người ta có thể lập luận rằng một Proc được kích hoạt sẽ dễ bảo trì hơn, nhưng tôi nghĩ bạn nên sử dụng một số loại tạo mã / mẫu khi tạo quy trình kích hoạt SSB, vì thông thường phần lớn là mã cắt cookie và ít đặc trưng cho logic nghiệp vụ dịch vụ.

Tuy nhiên, tôi có thể thấy một số vấn đề tiềm ẩn với một hàng đợi và tất cả chúng đều là loại sự cố chỉ biểu hiện khi mọi thứ trở nên tồi tệ (ví dụ: dưới áp lực / tải):

• độ trễ và xử lý tuần tự hóa. Chỉ với một hàng đợi là có thể để cao nguyên max_queue_readers ở mức tối đa và có các thông báo yêu cầu xử lý ít trong hàng đợi chờ đến lượt được chọn. Các hàng đợi riêng biệt cho phép các dịch vụ có độ trễ thấp thoát nhanh hàng đợi của chúng, trong khi hàng đợi tải cao khuấy động theo tốc độ (chậm hơn) của riêng chúng.
• một tin nhắn cho bất kỳ dịch vụ nào ảnh hưởng đến tất cả các dịch vụ. Tương tự như trên, nhưng cho gai. Một số lượng lớn tin nhắn (ví dụ: một số thủ công 'chúng ta cần xử lý lại các mục 1MM này') sẽ khiến tất cả các dịch vụ khác trên cùng một hàng đợi phải chờ cho đến khi hết đột biến trước khi chúng có quyền truy cập vào tin nhắn của chúng (là phức tạp hơn một chút do khóa nhóm hội thoại, nhưng cuối cùng xử lý là FIFO).
• chuyến thăm có thể tránh được vào vùng đất xấu xí của hàng đợi lớn . Nếu xảy ra sự cố hàng đợi lớn trên mã RAM / IO / CPU / kích hoạt của bạn tại các tin nhắn N, thì một hàng đợi cho tất cả các dịch vụ sẽ đạt N nhanh hơn / thường xuyên hơn một hàng đợi cho mỗi dịch vụ.

Nói chung, khuyến nghị của tôi là có một hàng đợi cho mỗi dịch vụ.