ZeroMQ選擇性發布/訂閱模式？

Question

我正在嘗試為N個前端服務器和M個后端工作器設計ZeroMQ架構，其中前端服務器會將任務發送到后端服務器。 前端服務器確實具有有關后端服務器的信息，但是后端服務器不知道有關前端服務器的信息。 我有兩種類型的任務，一種類型應該使用輪詢，並且僅轉到一台后端服務器，而另一種類型應該廣播到所有后端服務器。 我不想有一個中央經紀人，因為這將是單點故障。

對於第一種任務，請求/響應模式似乎是正確的，而對於第二種任務，則是發布者/訂閱者模式。 但是如何將兩者進行模式組合？ 如果要向所有或僅一個隨機后端服務器發送消息，是否有任何模式可以讓我在發送時進行選擇？

我想出的解決方案是僅使用發布者/訂閱者，並在消息前添加后端服務器ID和一些神奇的值（如果尋址到所有人）。 但是，這會產生很多不必要的流量。 有沒有更清潔，更有效的方法？

Answer 1

我可能會使用pub sub郵件信封 -如果您使用的是UDP上的pub / sub廣播，我不認為它會產生不必要的網絡流量，但是會引起額外的處理，但是像大多數其他情況一樣，這是一個折衷方案設計優雅和性能。 ØMQ傾向於首先采用性能路線，但我傾向於對其進行衡量，並使用量化的性能結果來確定這是否可以接受。

對我來說，一種優雅的解決方案是使用兩組套接字，因為這本身就可以區分整個系統的工作流程-而使用單個套接字以一種非常非ØMQ的方式混合事物，則這些套接字應該有所不同以允許將來進行更改和動態/不穩定的系統。

Answer 2

我認為唯一的可能性是使用DEALER-ROUTER組合。 前端為DEALER，后端為ROUTER。 每個前端服務器都應為每個后端服務器（用於廣播）包含一個DEALER套接字，並在頂部將一個DEALER套接字一次連接到所有后端服務器，以進行輪詢。 現在讓我解釋一下原因。

1. 在這種緊急情況下，您不能真正使用PUB-SUB，因為該模式可以很容易地以靜默方式丟棄消息，並且不會排隊。 因此，實際上，發布到PUB的消息可以到達SUB的任何子集，因為它在后台（斷開）連接。 因此，您需要通過循環分配給所有后台服務器的DEALER套接字來模擬廣播。 如果未連接后端部分，但請注意HWM，它將使消息排隊。 唯一的最終解決方案是使用心跳來了解后端何時死亡，並銷毀分配給它的套接字。
2. 后台的ROUTER套接字是一種邏輯解決方案，因為您可以異步接受任意數量的請求，並且由於它是ROUTER套接字，因此將響應發送回請求任務的前端非常容易。 通過在后台服務器中使用一個ROUTER，您可以使他們甚至不知道發生廣播的事實，從而將一切視為對他們的直接請求。 廣播純粹是前端的事情。 此解決方案的唯一問題可能是，如果您的后端服務器不夠快，則所有前端服務器可能會填滿它，以使其到達HWM並開始丟棄程序包。 您可以通過讓更多線程/進程處理ROUTER套接字中的消息來防止此情況。 zmq_proxy（）是此功能有用的功能。

希望這可以幫助 ;-）