ZeroMQ有選擇的酒吧/分模式？

我試圖設計ZeroMQ架構N前端服務器和M後端工作者，前端服務器將發送任務到後端服務器。前端服務器確實有關於後端服務器的信息，但後端服務器不知道前端服務器。我有兩種類型的任務，一種類型應該使用輪循機制，並且只轉到一個後端服務器，而其他類型應該被轉播到所有後端服務器。我不想有一箇中央經紀人，因爲這將是單點失敗。ZeroMQ有選擇的酒吧/分模式？

對於第一種類型的任務，請求/響應模式似乎是正確的，而第二種模式則是發佈者/訂戶模式。但是如何組合這兩者呢？如果我想將消息發送到全部或只是一個隨機後端服務器，是否有任何模式可以讓我在發送時選擇？

我提出的解決方案只是使用發佈者/訂閱者，並將消息與後端服務器標識相加，並在發送給所有人時使用一些魔術值。但是，這會造成很多不必要的流量。有更乾淨更有效的方法嗎？

來源

2012-04-13 vartec

你可以使用兩套插座？所以每個後端都會在REP套接字和SUB套接字上偵聽。 – 2012-04-13 16:56:33

@ThomasK：我認爲這就是他說他現在正在做的事情。 OP想知道是否有某種模式將功能組合到單個套接字中？ – jdi 2012-04-13 16:57:25

@jdi：不，他說他目前只使用一套套接字，並將後端ID放入消息中。這完全不同。 – 2012-04-13 17:00:55

我可能會使用pub sub message envelopes - 如果你使用UDP上的pub/sub廣播，我不相信它會產生不必要的網絡流量，但它會產生額外的處理，但是像大多數這些東西是一種折衷在設計優雅和表現之間。 ØMQ傾向於首先考慮績效的路線，但我傾向於衡量它，並使用量化的績效結果來決定這是否可以接受。

對我來說，優雅的解決方案是使用兩套套接字，因爲這本身就是通過系統區分工作流 - 而使用單套接字以非常非ØMQ的方式進行混合，這些應該不同於考慮到未來的變化和動態/不穩定的系統。

來源

2012-05-15 11:56:30

我認爲唯一的可能性是使用DEALER-ROUTER組合。經銷商在前端，ROUTER在後端。每個前端服務器應該爲每個後端服務器（用於廣播）包含一個DEALER套接字，並且一個連接到所有後端服務器上的一個DEALER套接字用於循環的事情。現在讓我解釋一下爲什麼。

在這種嚴重的情況下，您不能真正使用PUB-SUB，因爲該模式可以非常輕鬆地放置消息，它不會排隊。所以實際上發佈到PUB的消息可以到達SUB的任何子集，因爲它在後臺連接（dis）。出於這個原因，您需要通過循環遍歷分配給所有後臺服務器的DEALER套接字來模擬廣播。如果後端部分未連接，它將排隊消息，但要注意HWM。唯一的最終解決方案是使用心跳來了解後端何時死亡並銷燬分配給它的套接字。
因爲您可以異步接受任意數量的請求，並且由於它是ROUTER套接字，所以後臺的ROUTER套接字是一個合理的解決方案，因此將響應發送回請求任務的前端非常容易。通過在後臺服務器中安裝一個ROUTER，你可以使他們不知道有廣播發生的事實，他們將所有事情視爲對他們的直接請求。廣播純粹是一種前端事物。此解決方案的唯一問題可能是，如果您的後端服務器速度不夠快，所有前端服務器可能會將其填滿以便它到達HWM並開始丟棄程序包。您可以通過讓更多的線程/進程處理來自ROUTER套接字的消息來防止這種情況。 zmq_proxy（）是這個東西的一個有用的函數。

希望這有助於;-)

來源

2013-01-15 00:48:34 tchap

ZeroMQ有選擇的酒吧/分模式？

回答

相關問題