什麼場景會需要訊息佇列(MQ)？

message queue: 主要原因是由於在高併發環境下，由於來不及同步處理，請求往往會發生堵塞，比如說，大量的insert，update之類的請求同時到達資料庫，
直接導致無數的行鎖表鎖，甚至最後請求會堆積過多，從而觸發too many connections錯誤。通過使用訊息佇列，我們可以非同步處理請求，從而緩解系統的壓力。

什麼是分散式系統？

從RPC進化到Web Service，並在業界開始普遍推行SOA，再到後來的RESTful平臺以及SaaS概念的推廣，分散式架構在企業應用中開始呈現出不同的風貌，然而殊途同歸，這些分散式架構的目標仍然是希望實現系統之間的交流不再為不同語言與平臺的隔閡而產生障礙。

“整合之所以重要是因為相互獨立的應用是沒有生命力的。我們需要一種技術能將在設計時並未考慮互操作的應用整合起來，打破它們之間的隔閡，獲得比單個應用更多的效益”。這或許是分散式架構存在的主要意義。

“分散式系統就是這樣一個系統，系統中一個你甚至都不知道的計算機出了故障，卻可能導致你自己的計算機不可用。”

分散式系統具有複雜性與不可控性。我在一本關於分散式的書中看到某個大牛說到：分散式呼叫的第一原則就是不要分散式。這句話看似頗具哲理，然而就企業應用系統而言，只要整個系統在不停地演化，並有多個子系統共同存在時，這條原則就會被迫打破。因為在當今的企業應用系統中，很難尋找到完全不需要分散式呼叫的場景。作者提出的這條原則，一方面是希望設計者能夠審慎地對待分散式呼叫，另一方面卻也是分散式系統自身存在的缺陷所致。無論是RPC平臺，還是Web Service，都因為駐留在不同程序空間的分散式元件，而引入額外的複雜度，並可能對系統的效率、可靠性、可預測性等諸多方面帶來負面的影響。但是，是在企業應用系統領域，我們總是會面對不同系統之間的通訊、整合與整合的問題，尤其當面臨異構系統時，這種分散式的呼叫與通訊變得越重要，它在架構設計中就更加凸顯其價值。並且，從業務分析與架構質量的角度來講，我們也希望在系統架構中儘可能地形成對服務的重用，通過獨立執行在程序中服務的形式，徹底解除客戶端與服務端的耦合。這常常是架構演化的必然道路。