我不是高級程序員，但我一直在部署應用程序並開發了一些小型完整系統。爲什麼要使用排隊系統，如RabbitMQ
我開始聽說排隊系統，如RabbitMQ。可能是，我從來沒有開發過任何必須使用排隊系統的系統。但是，如果我不使用它，我很擔心，因爲我不知道該怎麼做。我在他們的網站上閱讀過RabbitMQ教程，但我不確定爲什麼我會使用它。我不確定是否有任何這些不能通過傳統編程實現，沒有額外的組件和常規數據庫或類似的。
有人可以請解釋爲什麼我會用一個小例子來使用排隊系統。我的意思不是一個你好世界的例子，而是一個實際的場景。
非常感謝您的時間
像一個消息隊列中間件的主要用途是爲了能夠給非均質系統之間發送數據。信息本身可以是很多東西。字符串是不同系統上不同語言最容易理解的，但對於傳輸更有意義的數據通常不太有用。因此，JSON和XML在消息中非常流行。這些只是結構化的字符串，可以在消費者端以選擇的語言轉換爲對象。
其它有用的功能：
這裏有一些可能做作的例子。本地系統上的Java程序想要將消息發送到通過互聯網連接的系統。本地系統有一臺連接到互聯網的服務器。除了與MQ的連接之外，一切都被阻止來自互聯網。 Java程序可以將消息發佈到MQ而無需訪問互聯網。消息位於隊列中，直到外部系統啓動。 Java程序發佈消息，可以說XML，而消費者可以是Perl程序。只要他們有一些用預定義的序列化和反序列化方式來理解XML的方式，它就沒問題。
MQ系統傾向於在「即燃即用」情況下工作得最好。如果事件發生並且其他人需要得到通知，但源系統不需要其他系統的反饋，那麼MQ可能非常適合。
如果您瞭解MQ的優缺點，仍然不明白爲什麼它適合特定的系統，那麼它可能不是。我見過使用MQ的系統，但不需要，結果並不美觀。
我見過的大部分場景都是在無關係統（通常是開箱即用的系統）之間進行整合。假設您有一個系統接受訂單，另一個系統填寫訂單並將其發運。在這種情況下，訂單系統可以使用MQ來通知訂單系統的訂單，但是訂單系統沒有興趣等待訂單系統收到訂單。所以它會將消息放入隊列中繼續前進。
這是一個非常簡單的答案，但它給出了一般的想法。
讓我們從電話和電子郵件的角度思考這個問題。假裝電子郵件不存在一分鐘。爲了完成工作，你必須給每個人打電話。當你通過電話與某人溝通時，你需要讓他們在他們的辦公桌前接觸他們（假設他們在工廠，不能聽到他們的手機響了）:-)如果你想要的人不是' t在辦公桌前，你一直在等待，直到他們回覆你的電話（或者更有可能，你稍後再打電話給他們）。這與你一樣 - 在有人打電話給你之前，你沒有任何工作要做。如果多人同時打電話，你不知道，因爲你一次只能處理一個人。
但是，如果我們有電子郵件，您可能會將您的請求「排隊」給其他人，以便在方便時回答（但更可能忽略）。如果他們確實忽略了你的電子郵件，你可以隨時重新發送。您不必等待他們在辦公桌前，他們不必等到您關閉電話。工作量增加，事情運行更加順利。作爲額外的好處，你可以將你不想處理的消息轉發給你的peons。
在系統工程中，我們使用術語「緊密耦合」來定義像上述電話場景一樣工作的程序（或部分程序）。他們非常相互依賴，經常在程序的各個部分之間共享實現。在這些程序中，數據按順序處理，每次處理一個。這些系統通常很容易構建，但是需要考慮一些重要的缺陷：（1）更改程序的任何部分可能會導致整個代碼中的級聯更改，這會引入錯誤; （2）系統不具有可擴展性，通常必須隨着需求的增長而被廢棄和重建; （3）系統的所有部分必須同時工作，否則整個系統將無法工作。
基本上，如果程序非常簡單，或者如果有一些專門的理由使用緊密耦合的程序，緊密耦合的程序是很好的。
在現實世界中，事情要複雜得多。程序不能那麼簡單，以緊密耦合的方式開發企業應用程序變成了一場噩夢。因此，我們使用術語「鬆散耦合」來定義由許多小塊組成的大系統。這些作品具有非常明確的界限和功能，因此可以更輕鬆地完成系統更改。這是面向對象設計的本質。消息隊列（如RabbitMQ）允許在各種程序和部分程序之間進行類似電子郵件的通信，從而使工作流程更像人。無論你需要什麼，增加額外的容量然後成爲一個簡單的啓動和額外的計算機的問題。
很顯然，這是一種粗略的簡化，但我認爲它表達了總體思路。構建使用消息隊列的應用程序使您能夠利用雲服務提供商部署大規模可伸縮的應用程序。這裏是一篇文章，談論雲設計： http://blogs.msdn.com/b/silverlining/archive/2011/08/23/designing-and-building-applications-for-the-cloud.aspx