Rabbitmq- Thiết kế dịch vụ phát lại tin nhắn

Question

Tôi đang cố gắng thiết kế cơ chế phát lại cho phép người dùng phát lại tin nhắn từ hàng đợi. Việc thiết kế tốt nhất mà tôi đã đưa ra cho một cuộc trao đổi có chứa nhiều hàng đợi và nhiều người tiêu dùng là:

1. Tạo một dịch vụ ghi rằng sẽ:

   • Tạo một danh sách và ràng buộc tất cả các phím định tuyến để nó .
   • Tiêu thụ tất cả thư từ trao đổi.
   • Lưu tất cả thư vào DB.

2. Yêu cầu đăng ký phát lại.

   • Mỗi người đăng ký tạo một trao đổi, xếp hàng mới và liên kết với nó với cùng một ràng buộc như hàng đợi thông thường.
   • Người đăng ký gửi yêu cầu còn lại tới máy chủ web để bắt đầu phát lại bằng bộ lọc (bắt đầu, v.v ...). Yêu cầu chứa tên trao đổi phát lại của nó.
   • Máy chủ web lấy dữ liệu từ DB và xuất bản dữ liệu đó đến trao đổi cụ thể
   • sàng lọc có thể được thêm như đính kèm RequestId và lặp lại nó.

Câu hỏi:
1. Việc đó có ý nghĩa?
2. Tôi có phát minh ra bánh xe không? Có một giải pháp vốn có của thỏ không? cắm vào?
3. Việc tạo nhiều trao đổi có được coi là thực hành tốt không?
Trong trao đổi giải pháp này cho mỗi hàng đợi được tạo để xuất bản cùng một thông điệp.

Một giải pháp khác:
1. Tạo hàng đợi bổ sung "ReplayQueue" cho mỗi hàng đợi. đặt TTL (giả sử một tháng).
2. Mỗi khi người dùng yêu cầu phát lại, hãy để anh phát lại từ ReplayQueue của riêng mình mà không cần nhấn.

Giải pháp này có vấn đề một chút vì.

• Để phát lại ngày hôm qua, người tiêu dùng sẽ phải tìm nạp tất cả 29 ngày trước đó và lọc chúng ra.
• Giải pháp này tăng lên - Hàng đợi sẽ lớn hơn (không giống như bộ nhớ db có thể mở rộng).

Answer 1

1. Điều đó có hợp lý không?

Có

2. Tôi phát minh ra bánh xe? Có một giải pháp vốn có của thỏ không? cắm vào?

Bạn không phát minh lại bánh xe. Có AFAIK không có giải pháp thỏ và không có giải pháp hộp.

Giải pháp đầu tiên của bạn là theo ý kiến ​​của tôi. Các Another solution là rất có vấn đề bởi vì một con thỏ khỏe mạnh là một con trống và thỏ không phải là một kho dữ liệu.

Bạn sẽ có hàng đợi (STORE) trong đó tất cả thư được xuất bản sẽ được định tuyến đến. Thay vì ràng buộc STORE với tất cả các khóa ràng buộc, bạn có thể xem xét sử dụng trao đổi chủ đề. Ở mức giá mà khóa ràng buộc không được chứa . # * và phí trên đầu khi thông báo được định tuyến. Hàng đợi STORE sẽ liên kết với khóa ràng buộc #.

Bạn có thể xem firehose.

Tại sao yêu cầu web? Bạn không thể sử dụng Rabbit với số RPC call:

• Người đăng ký gửi yêu cầu amqp để bắt đầu phát lại bằng bộ lọc (startdate, v.v ...).
• Yêu cầu chứa tên hàng đợi reply-to. Hàng đợi có thể dành riêng cho khách hàng và yêu cầu.
• máy chủ RPC kéo dữ liệu từ DB và xuất bản nó vào trả lời để xếp hàng

Bạn có thể có một cái nhìn quá tại mô hình direct-reply-to.

Tạo nhiều trao đổi có được coi là thực tiễn tốt không?

Có, ngay khi bạn cần. Đối với trường hợp cụ thể của bạn, theo ý kiến ​​của tôi, một trao đổi cho mỗi thuê bao là không cần thiết. Yêu cầu chứa tên hàng đợi. Bạn chỉ có thể xuất bản lên hàng đợi này bằng cách sử dụng trao đổi mặc định amq.direct với khóa định tuyến bằng với tên hàng đợi. Nếu bạn muốn trao đổi, tôi sẽ tạo một trao đổi duy nhất (ví dụ: "phát lại"). Mỗi người đăng ký liên kết hàng đợi phát lại của họ với cuộc trao đổi này. Trao đổi "phát lại" có thể là một quy ước hoặc được gửi cùng với yêu cầu.

Answer 2

Giải pháp đầu tiên là khả thi. Cho rằng con thỏ MQ tàu với một tracing plugin, lưu trữ các tin nhắn trong DB trở nên dễ dàng hơn vì nó chỉ đơn giản là sôi xuống để tiêu thụ từ một hàng đợi ràng buộc để amq.rabbitmq.trace trao đổi.

Trao đổi này cụ thể cho một vhost và mọi vhost đều có giao dịch riêng của mình amq.rabbitmq.trace. Ngoài ra khi tạo một dấu vết mới, có thể hạn chế hàng đợi/trao đổi nào cho phép truy tìm, do đó cho phép tính linh hoạt để vô hiệu hóa truy tìm nơi nó không được yêu cầu.

Tham khảo các liên kết sau đây để cấu hình truy tìm:
https://www.rabbitmq.com/firehose.html
https://www.rabbitmq.com/blog/2011/09/09/rabbitmq-tracing-a-ui-for-the-firehose/