Chủ đề JMS vs Hàng đợi


191

Tôi đã tự hỏi sự khác biệt giữa Chủ đề JMS và Chủ đề JMS là gì.

Trang ActiveMQ cho biết

Chủ đề

Trong JMS, một chủ đề thực hiện xuất bản và đăng ký ngữ nghĩa. Khi bạn xuất bản một tin nhắn, nó sẽ được gửi đến tất cả những người đăng ký quan tâm - vì vậy không có nhiều người đăng ký sẽ nhận được một bản sao của tin nhắn. Chỉ những thuê bao đã đăng ký hoạt động tại thời điểm người môi giới nhận được tin nhắn mới nhận được một bản sao của tin nhắn.

Hàng đợi

Một hàng đợi JMS thực hiện ngữ nghĩa cân bằng tải . Một tin nhắn sẽ được nhận bởi chính xác một người tiêu dùng. Nếu không có người tiêu dùng có sẵn tại thời điểm tin nhắn được gửi, nó sẽ được giữ cho đến khi có một người tiêu dùng có thể xử lý tin nhắn. Nếu một người tiêu dùng nhận được một tin nhắn và không thừa nhận nó trước khi đóng thì tin nhắn sẽ được gửi lại cho một người tiêu dùng khác. Một hàng đợi có thể có nhiều người tiêu dùng với tải thông điệp được cân bằng trên các người tiêu dùng có sẵn.

Tôi muốn có 'một cái gì đó' những gì sẽ gửi một bản sao của tin nhắn đến từng người đăng ký theo cùng một trình tự như trong đó tin nhắn đã được nhận bởi nhà môi giới ActiveMQ.

Có suy nghĩ gì không?

Câu trả lời:


146

Điều đó có nghĩa là một chủ đề là phù hợp. Một hàng đợi có nghĩa là một tin nhắn đến một và chỉ một thuê bao có thể. Một chủ đề đi đến từng người đăng ký.


4
Bất kỳ ý tưởng nào làm thế nào để cân bằng tải hoạt động cho Hàng đợi trong JMS hoặc WSO2 MB?
Kicesangar

Điều đó thật thú vị bởi vì tôi đã cố gắng gỡ lỗi một số thuê bao và khi gửi một chủ đề, thuê bao không được gọi nhưng khi gửi đến hàng đợi thì nó hoạt động
vmrvictor 23/07/19

54

Các chủ đề dành cho mô hình thuê bao của nhà xuất bản, trong khi hàng đợi dành cho điểm-điểm.


29

Một JMS chủ đề là loại đích trong một mô hình 1-nhiều của phân phối. Các tin nhắn được công bố tương tự được nhận bởi tất cả các thuê bao tiêu thụ . Bạn cũng có thể gọi đây là mô hình 'phát sóng'. Bạn có thể nghĩ về một chủ đề tương đương với Chủ đề trong mẫu thiết kế Observer cho tính toán phân tán. Một số nhà cung cấp JMS hiệu quả chọn thực hiện điều này như UDP thay vì TCP. Đối với chủ đề, việc gửi tin nhắn là 'cháy và quên' - nếu không có ai nghe, tin nhắn sẽ biến mất. Nếu đó không phải là điều bạn muốn, bạn có thể sử dụng 'đăng ký bền'.

Một JMS hàng đợi là một điểm đến 1-to-1 tin nhắn. Tin nhắn chỉ được nhận bởi một trong những người nhận tiêu thụ (xin lưu ý: sử dụng liên tục người đăng ký cho 'khách hàng chủ đề và người nhận cho hàng đợi của khách hàng để tránh nhầm lẫn). Tin nhắn được gửi đến một hàng đợi được lưu trữ trên đĩa hoặc bộ nhớ cho đến khi ai đó nhặt nó lên hoặc nó hết hạn. Vì vậy, hàng đợi (và đăng ký bền) cần một số quản lý lưu trữ tích cực, bạn cần suy nghĩ về người tiêu dùng chậm.

Trong hầu hết các môi trường, tôi sẽ tranh luận, các chủ đề là sự lựa chọn tốt hơn bởi vì bạn luôn có thể thêm các thành phần bổ sung mà không phải thay đổi kiến ​​trúc. Các thành phần được thêm vào có thể là giám sát, ghi nhật ký, phân tích, v.v. Bạn không bao giờ biết khi bắt đầu dự án, các yêu cầu sẽ như thế nào trong 1 năm, 5 năm, 10 năm. Thay đổi là không thể tránh khỏi, hãy nắm lấy nó :-)


26

Nó là đơn giản như vậy:

Hàng đợi = Chèn> Rút tiền (gửi cho một thuê bao) 1: 1

Chủ đề = Chèn> Phát sóng (gửi cho tất cả người đăng ký) 1: n

nhập mô tả hình ảnh ở đây


2
Một ví dụ có thể cho một mạng xã hội đơn giản. Ai đó 'thích' một bài đăng. Phần phụ trợ xuất bản một sự kiện 'POST THÍCH' cho chủ đề. Nó được tiêu thụ bởi 3 người đăng ký: notificationProcessor(gửi thông báo đến người đăng), karmaProcessor(cung cấp nghiệp lực cho người thích và người đăng), feedProcessor(di chuyển ghi chú lên trên vào nguồn cấp dữ liệu của mọi người). Tất cả không đồng bộ tất nhiên.
Siddhartha

@Siddhartha, đây có thể là một câu trả lời - trong một ví dụ, cảm ơn!
selem mn

8

Đối với việc bảo quản đơn hàng, xem trang ActiveMQ này . Tóm lại: đơn hàng được bảo tồn cho người tiêu dùng đơn lẻ, nhưng với nhiều người tiêu dùng, đơn hàng giao hàng không được đảm bảo.


7

Hàng đợi

Ưu

  • Mẫu tin nhắn đơn giản với luồng liên lạc trong suốt
  • Tin nhắn có thể được phục hồi bằng cách đưa chúng trở lại hàng đợi

Nhược điểm

  • Chỉ một người tiêu dùng có thể nhận được tin nhắn
  • Ngụ ý sự kết hợp giữa nhà sản xuất và người tiêu dùng vì đó là mối quan hệ một đối một

Chủ đề

Ưu

  • Nhiều người tiêu dùng có thể nhận được một tin nhắn
  • Phân tách giữa nhà sản xuất và người tiêu dùng (mẫu xuất bản và đăng ký)

Nhược điểm

  • Lưu lượng truyền thông phức tạp hơn
  • Một tin nhắn không thể được phục hồi cho một người nghe

4

Nếu bạn có N người tiêu dùng thì:

Chủ đề JMS gửi tin nhắn đến N của N Hàng đợi JMS gửi tin nhắn đến 1 trong N

Bạn nói rằng bạn "đang tìm kiếm một 'thứ' sẽ gửi một bản sao của tin nhắn đến từng người đăng ký theo cùng một trình tự như trong đó người nhận được tin nhắn của nhà môi giới ActiveMQ."

Vì vậy, bạn muốn sử dụng một Chủ đề để tất cả người đăng ký N nhận được một bản sao của tin nhắn.


1

TOPIC :: topic là một trong nhiều giao tiếp ... (đa điểm hoặc xuất bản / đăng ký) EX: -imagine một nhà xuất bản xuất bản phim trong youtub thì tất cả những người đăng ký của nó sẽ nhận được thông báo .... QUEVE :: queve là một -một giao tiếp ... Ví dụ: -Khi xuất bản yêu cầu nạp tiền, nó sẽ chỉ chuyển đến một qreciever ... luôn nhớ nếu yêu cầu goto tất cả các qreceivers sau đó nhiều lần sạc lại xảy ra trong khi phát triển phân tích phù hợp với ứng dụng


-1

Hàng đợi là đối tượng được quản lý JMS được sử dụng để giữ tin nhắn đang chờ người đăng ký sử dụng. Khi tất cả các thuê bao tiêu thụ tin nhắn, tin nhắn sẽ bị xóa khỏi hàng đợi.

Chủ đề là tất cả những người đăng ký một chủ đề nhận được cùng một tin nhắn khi tin nhắn được xuất bản.


2
Thông điệp Queue sẽ chỉ được tiêu thụ một lần bởi một đơn tiêu dùng, đó là lý do tại sao một hàng đợi cụ một cân bằng tải. Đăng ký chủ đề có thể bền : người đăng ký có thể nhận được tin nhắn rất lâu sau khi xuất bản (ví dụ: nếu người đăng ký đã tắt và xuất hiện lại).
Gruber
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.