如何避免丟棄消息zeromq pub sub

Question

我已經看到了幾個關於這個問題，但沒有答案，我發現令人滿意。這個問題，特別是zeromq pattern: pub/sub with guaranteed delivery是類似的，儘管我願意使用任何其他的zeromq機制來實現相同的效果。

我的問題是，有沒有辦法在風扇將郵件發送像出版商訂戶模式在ZeroMQ與保證該信息將被傳遞？看起來好像零拷貝的經銷商可以做到這一點，但它會比pub-sub更混亂。有更好的選擇嗎？除了編寫更多的代碼之外，這樣做還有什麼缺點？

原因需要這樣的：

我寫代碼來分析數據，從儀表到來。連接到儀器的模塊需要能夠將數據廣播到其他模塊供他們分析。反過來，他們需要將他們的分析數據廣播到輸出模塊。

乍一看發佈 - 訂閱與ZeroMQ似乎完美的人選，但如果任何用戶放緩，命中高水位標記的消息會被丟棄。在這個系統的情況下，由於事件的連續性，僅僅在一小部分模塊上丟棄消息是不可接受的。所有模塊都需要分析輸出的事件纔有意義。但是，如果沒有模塊收到事件消息，那就沒問題。出於這個原因，如果其中一個分析模塊達到高水位標記，阻止發佈者（儀器模塊）就可以了。

我想另一種選擇是應對事後錯過的消息，但只是浪費上，將在稍後丟棄的事件處理時間。

編輯： 我猜想進一步，我目前預計發送消息=消息傳遞，因爲我正在使用inproc和線程之間進行通信。但是，如果我要通過tcp發送消息，則即使ZeroMQ不會故意丟棄消息，該消息也可能會丟失。這是否意味着我可能需要處理丟棄的郵件，即使我使用阻止發送？使用inproc是否有任何有關郵件傳遞的保證？

Answer 1

在一般情況下，我認爲沒有提供有關其自身與0MQ發佈/訂閱擔保的方式。如果你真的需要完全可靠的消息，你將不得不推出自己的消息。

網絡是根本不可靠，這就是爲什麼TCP做了這麼多的握手只是爲了讓對面的包。

一如既往，它是延遲和吞吐量之間的平衡。如果您準備犧牲吞吐量，您可以自己進行消息握手 - 可能使用REQ/REP並自己處理廣播。

的0MQ手冊裏有關於如何去你想要什麼here圍繞至少一部分的一些想法。

Answer 2

我同意SteveL。如果你真的需要100％的可靠性（或接近它），ZeroMq可能不是你的解決方案。您最好使用可保證消息傳遞和持久性的商業消息產品，否則，您將在ZeroMq中對可靠性功能進行編碼，並可能在此過程中脫穎而出。如果您需要應用程序和數據庫之間的ACID兼容性，您會實現自己的應用程序服務器嗎？除非你想實現自己的事務管理器，否則你會購買WebLogic，WebSphere或JBoss來爲你做。

這是否意味着我可能需要處理丟棄的消息，即使我 使用阻塞發送？

我會遠離明確阻止任何東西，它太脆弱了。如果消費方出現問題，同步發送方可能無限期地掛起。你可以使用輪詢和超時來解決這個問題，但是它又是脆弱和雜亂的代碼;堅持異步。

使用inproc是否有任何有關郵件傳遞的保證？

那麼，有一件事是有保證的;你沒有處理物理套接字，所以任何網絡問題都被消除了。