而不是編寫自己的庫。爲什麼要使用AMQP/ZeroMQ/RabbitMQ
我們正在研究一個項目，這個項目將是一個自我分割的服務器池，如果一個部分變得太重，那麼管理員會將它分開並作爲一個單獨的進程放在另一臺機器上。它還會提醒所有連接的客戶端，這會影響連接到新的服務器。
我很好奇使用ZeroMQ進行服務器間和進程間通信。我的合作伙伴寧願推出自己的。我期待社區回答這個問題。
我自己是一個相當新手的程序員，只是瞭解了消息隊列。正如我已經搜索並閱讀，似乎每個人都在使用消息隊列來處理各種事情，但爲什麼？是什麼讓他們比寫自己的圖書館更好？他們爲什麼這麼常見，爲什麼會有這麼多？
是什麼讓他們比寫自己的圖書館更好？
當推出你的應用程序的第一個版本，可能沒什麼：您的需求是明確的，你將建立一個消息傳遞系統，將滿足您的需求：小功能列表中，小源代碼等
那些工具是非常有用有用第一個版本，當你實際上必須擴展你的應用程序並添加更多的功能。 讓我給你幾個用例：
在一開始，你有一臺局域網內的3臺機器，沒有明顯的延遲一切都得到每臺機器。你的客戶/老闆/尖頭髮魔鬼老闆出現並告訴你，你將在你不管理的WAN上安裝應用 - 然後你開始有連接失敗，延遲等問題，你需要存儲消息並重試發送他們後來：回到代碼並插入這些東西（並享受）
發送的郵件需要有回覆，但不是所有的人：你發送一些參數，並期望一個電子表格作爲結果，而不是隻是發送和確認，回到代碼並插入這些東西（並享受）。
和許多其它使用情況，我忘了... ...
您可以自己實現它，但不要花太多時間這樣做：你可能會稍後將其裝呢。
啊，非常感謝。這當然給了我一些思考的食物。 –
根據官方的zeromq指南，zeromq不提供持久性。該指南向您展示瞭如何做到這一點，但我寧願有持久性出現在框架中的東西，而不是使用一些測試不當的教程代碼！ –
對於「推出第一個版本的應用程序時可能沒有任何問題」持不同意見。您完成時說第一個版本將會被庫改寫，不妨從最終不會丟棄的東西開始。否則，我同意。 –
是什麼讓他們比寫自己的圖書館更好？
消息排隊系統是事務性的，它在概念上很容易用作客戶端，但作爲一個實現者很難正確使用，特別是考慮到持久隊列。你可能會認爲你可以通過編寫一個快速消息庫來逃避，但是如果沒有事務和持久性，你就沒有消息系統的全部好處。
在這種情況下的持久性意味着消息中間件在服務器停機的情況下將未處理的消息保存在永久存儲器（磁盤上）中;在重新啓動後，可以處理消息並且不需要重新發送（發送者甚至不知道有問題）。事務性意味着您可以讀取來自不同隊列的消息，並以事務方式將消息寫入不同的隊列，這意味着所有讀取和寫入都成功或（如果一個或多個失敗）都不成功。這與從數據庫接口中獲知的事務並無太大差別，並具有相同的好處（它簡化了錯誤處理;如果沒有事務處理，則必須確保每個讀寫成功，如果有一個或多個失敗，回滾那些成功的改變）。
我一直在想這個問題。交易和持久性究竟意味着什麼？我理解這些單詞，但不瞭解這裏的背景。簡而言之，它會發出熱門詞彙。 –
我不會稱這些流行語;幾十年來，這些名字一直都被稱爲持久性和交易。我編輯了我的答案，在消息傳遞的上下文中詳細說明了這些要點。 – pmf
有趣的，但是這些很難讓對方覺得怎麼樣？從我的角度來看，如果我正在編寫服務器和客戶端，則會發送消息，確保消息已全部接收，並保留存儲在磁盤上的消息的副本。這是結束。爲什麼這麼簡單的系統有這麼多版本？我的意思是，其中很多代碼都是相當小的代碼明智的，一旦你理解了它們的工作方式，似乎並不需要太多的實現。 所以回到爲什麼使用預先寫好的消息隊列。 –
這很像問：爲什麼使用數據庫時，你可以自己寫？
答案是，使用已經存在了一段時間並且在很多不同用例中都很好理解的工具，隨着時間的推移和隨着您的需求的變化，付出的代價將越來越大。如果一個項目涉及多個開發人員，情況尤其如此。如果您更改爲新項目，您是否希望成爲排隊系統的支持人員？使用工具可以防止這種情況發生。這成爲別人的問題。
案例：持久性。編寫一個工具將一條消息存儲在磁盤上很容易。在很多不同的使用情況下，編寫一個能夠穩定擴展和執行的非易失性存儲器，並且易於管理，而且價格便宜。如果你想看到有人抱怨它有多難，那麼看看這個：http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange
無論如何，我希望這有助於。通過一切手段編寫你自己的工具。許多人都這麼做了。無論怎樣解決你的問題，都是好事。
或者一個編譯器。爲什麼在編寫純粹，純淨的彙編語言時爲什麼要使用編譯語言呢？ :-) – Jeff
我正在考慮使用ZeroMQ自己 - 因此我偶然發現了這個問題。
讓我們假設你有能力實現一個滿足你所有需求的消息排隊系統。爲什麼要採用自己的方法來採用ZeroMQ（或其他第三方庫）？簡單 - 成本。
讓我們假設ZeroMQ已經滿足您的所有要求。所有需要做的就是將它集成到你的版本中，閱讀一些doco，然後開始使用它。這要比你自己的努力少得多。此外，維護負擔已轉移到另一家公司。由於ZeroMQ是免費的，就像您剛開發的開發團隊包含（部分）ZeroMQ團隊一樣。
如果您運行了軟件開發業務，那麼我認爲您會平衡使用第三方庫的成本/風險，而不是使用自己的產品，在這種情況下，使用ZeroMQ將勝出。
也許你（或者更確切地說，你的伴侶）會受到"Not Invented Here"綜合症的影響嗎？如果是這樣，請調整您的態度並重新評估ZeroMQ的使用情況。就我個人而言，我更喜歡Proudly Found Elsewhere的態度。我希望能爲找到ZeroMQ感到自豪......時間會證明。
編輯：我遇到了這個video從ZeroMQ開發人員談到爲什麼你應該使用ZeroMQ。
我傾向於同意你的看法。在過去的幾個月中，我一直在用C++編寫一些程序，因爲這個問題被問到了。而且我跑到了第三方庫的地獄。有些是相對無痛的，但他們中的許多人比他們值得添加更多的麻煩，只是試圖安裝它們。我仍然不確定爲什麼任何人都會對zeroMQ有所要求。我學會編寫的第一件事情之一是如何通過TCP和套接字將消息從一個程序發送到另一個程序，以實現一個非常簡單的聊天程序，這相對比較簡單.. –
完全同意許多（也許大多數？）第三方庫比他們的價值更麻煩。我想我多年來發現了一些真正的寶石，我非常樂意與之合作。我剛編譯過ZeroMQ並運行測試。它看起來不錯。它還沒有「寶石」的地位，但我們會看到... –
只是跟進 - 我發現ZeroMQ是相當不錯的。它的重量和速度都很輕。我不喜歡它們的Socket具有線程親和性的方式，因爲我想使用兩個線程來訪問套接字 - 一個用於讀取消息，另一個用於寫入消息。它認爲這樣做的「ZeroMQ」方式是使用進程內消息隊列來封送線程之間的消息......需要更多思考。 –
如果你有一點時間試試看，並推出自己的實現！這項練習的學習將使你確信使用已經測試過的庫的智慧。
寫你自己的圖書館之前，請閱讀0MQ指南這裏：http://zguide.zeromq.org/page:all
有機會，你要麼決定安裝RabbitMQ的，否則你會做出ZeroMQ的頂部您的圖書館，因爲他們已經做好了所有的硬件。
他們在指南中以教程方式完成了一些「難題」（例如持久化）。我寧願使用經過測試的實現，而不是一些測試不當的教程代碼。 –
如果你想要經過戰場測試的實現，那麼你會選擇AMQP而不是ZMQ，並使用像RabbitMQ –
你不應該編寫自己的庫的原因是，用你自己的話說，你是「一個相當新手的程序員」。爲什麼要使用新手程序員編寫的MQ庫？ – Jeff