Khi nào, ở đâu và hàng đợi nên được sử dụng như thế nào?

Question

Tôi mới phát triển Java cho doanh nghiệp, mặc dù tôi chắc chắn câu hỏi này cũng áp dụng như nhau đối với bất kỳ ngôn ngữ hoặc nền tảng nào, chẳng hạn như .NET.

Lần đầu tiên kể từ bây giờ tôi đang xử lý hàng đợi tin nhắn và tôi rất bị hấp dẫn bởi chúng. (cụ thể, chúng tôi đang sử dụng ActiveMQ). Lãnh đạo công nghệ của tôi muốn hàng đợi ActiveMQ trở thành những người chạy trước cho tất cả các cơ sở dữ liệu và dịch vụ web nội bộ của chúng tôi; do đó thay vì truy vấn cơ sở dữ liệu bị sa thải khỏi máy khách và đi trực tiếp vào cơ sở dữ liệu, nó được xếp hàng đợi trước.

Câu hỏi của tôi là: xếp hàng đợi cách đi với mỗi thành phần xử lý chính? Thực hành tốt nhất có đặt ra chúng trước các thành phần hệ thống thường bị tấn công với số lượng lớn yêu cầu không? Có những tình huống không được sử dụng hàng đợi không?

Cảm ơn mọi thông tin chi tiết tại đây!

Answer 1

Dưới đây là một số ví dụ trong đó hàng đợi thư có thể hữu ích.

Tài nguyên giới hạn
Cho phép nói rằng bạn có nhiều người dùng yêu cầu dịch vụ. Nếu dịch vụ chỉ có thể xử lý một số lượng nhỏ yêu cầu đồng thời thì bạn có thể sử dụng hàng đợi làm bộ đệm.

Dịch vụ tách
Một khái niệm hội nhập doanh nghiệp chủ chốt là tách hệ thống in cho ví dụ một công việc. Thay vì có hệ thống nói chuyện trực tiếp với nhau, họ gửi thông điệp một cách không đồng bộ vào hàng đợi. Thành phần tích hợp sau đó định tuyến và truyền thông điệp đến hệ thống thích hợp.

nhắn replay
Trong ví dụ hàng đợi trên cũng có thể cung cấp giao hàng đáng tin cậy và xử lý các yêu cầu. Nếu một thành phần của quy trình làm việc bị phá vỡ, những thành phần khác không bị ảnh hưởng và vẫn có thể hoạt động và đăng thông báo lên thành phần bị hỏng. Khi thành phần bị hỏng phục hồi nó có thể xử lý tất cả các tin nhắn xếp hàng đợi.

Các khái niệm chính ở đây là điều chỉnh tải, khớp nối lỏng lẻo, độ tin cậy và hoạt động không đồng bộ.

Để xem chúng có phải là cách để đi cho mỗi thành phần chính, tôi sẽ nói không, đây không phải là lựa chọn tự động, bạn phải xem xét từng thành phần riêng lẻ.

Answer 2

Xin hãy kiểm tra này:

http://code.google.com/p/disruptor/

Không chỉ hàng đợi đang có trong tự nhiên để giải quyết những loại vấn đề.

Trả lời câu hỏi của bạn. Hàng đợi trong trường hợp này sẽ giới thiệu hành vi không đồng bộ trong truy cập vào cơ sở dữ liệu của bạn. Trong trường hợp này, nó là một câu hỏi của bạn có thể đủ khả năng tác động lớn đến các hệ thống cũ của bạn. Nó chỉ có thể là quá nhiều thay đổi để đẩy mọi thứ vào hàng đợi. Vui lòng mô tả mục đích chung của các hệ thống của bạn là gì. Sau đó, nó sẽ được dễ dàng hơn để trả lời câu hỏi của bạn đầy đủ.

Answer 3

Hàng đợi thực sự là một công cụ rất mạnh mẽ và hữu ích, nhưng giống như mọi công cụ bạn chỉ nên sử dụng nó cho công việc mà nó dự định.

IMO họ là không phải cách để đi cho mỗi thành phần xử lý chính.

Theo nguyên tắc chung, tôi sẽ sử dụng hàng đợi nơi tài nguyên yêu cầu không yêu cầu phản hồi ngay lập tức, đồng bộ. Tôi sẽ không sử dụng một hàng đợi mà thời gian và trình tự xử lý là rất quan trọng.

Trường hợp xử lý không đồng bộ được phép và bạn muốn điều chỉnh lượng lưu lượng truy cập cho dịch vụ thì hàng đợi có thể là cách để thực hiện.

Xem câu trả lời của @ Qwerky nữa, anh ấy (hoặc cô ấy) có một số điểm tốt.

Answer 4

Hàng đợi thư về cơ bản là không đồng bộ hệ thống liên lạc. Trong trường hợp này, nó có nghĩa là ngoài hàng đợi liên kết người gửi và người nhận, cả người gửi và người nhận đều hoạt động độc lập; người nhận tin nhắn không (và không nên) yêu cầu tương tác với người gửi. Tương tự, người gửi tin nhắn không (và không nên) yêu cầu tương tác với người nhận.

Nếu người gửi cần đợi kết quả xử lý tin nhắn, thì hàng đợi tin nhắn có thể không phải là giải pháp tốt vì điều này sẽ buộc hệ thống không đồng bộ phải đồng bộ, so với thiết kế lõi. Có thể xây dựng một hệ thống truyền thông đồng bộ trên đầu hàng đợi thông điệp, nhưng bản chất không đồng bộ cơ bản của hàng đợi thông báo sẽ làm cho chuyển đổi này trở nên khó xử.