隨著技術的發展分布式系統已經成為標配，分布式系統就存在著各式各樣的程序間通訊。訊息對列實際上就是程序間通訊方式的一種，是生產者消費者模式在分布式場景下的實現。
訊息佇列主要由以下作用：解耦，削峰，非同步，其實還有乙個作用是提高接收著效能。
我們以乙個快遞員送快遞的栗子來描述下佇列的作用。
送快遞送出了煩心事
快遞員給小明送快遞分為幾步？
分為3步，
第一步把快遞拿到小明家門口（省略了前n步，從小明家樓下開始）
第二步敲門（模擬程式設計世界的呼叫第三方介面）
第三步小明開門拿走快遞（第三方介面執行過程）
好了上邊是送快遞最簡單的三步，讓我們想想，這簡單的三步會有什麼問題？
快遞員什麼時候完成這一單或者是否能順利完成，十分依賴於小明的相應速度。如果小明還沒起床，聽見敲門聲再穿衣服開門，可能消耗很多時間。如果小明沒在家呢？那就要配送失敗了，如何判斷配送失敗呢？快遞員需要判斷等多久開門（超時時間），打**判斷是否在家（健康檢查），最終鬱悶的離開，下次再來一次（重試）。
快遞員直接與小明互動，對小明的狀態強依賴，產生了耦合現象。那有辦法避免這種耦合呢？
快遞員的配送速度收到小明的響應速度影響極大，有一兩個需要長時間等待的快件，快遞員的配送效率（吞吐率）會收到很大影響。
雙11，618，每次到購物節的時候，快遞員都很煩躁。快遞太多，來的比送得快，這可如何是好。
小明也很煩躁，一天要收100個快遞，可是家裡的空間都滿了，要邊收拾出地方邊進一件快遞。
如果小明準備和女朋友告白，此時來了一陣敲門聲，你好，快遞。
– 還雙11，小明買了100件商品，明天不定時一件件送到，小明這一天都要搭進去了。
接收快遞也成為了一件煩心事，好想把其他事情處理完再收快遞，也好想一塊收100件快遞。
現在快遞員和小明都很煩躁，這個時候有個叫x巢（沒收廣告費）的快遞櫃出現了，快遞員可以把快遞放到櫃子裡，發條簡訊通知小明過來取快遞。小明看到簡訊可以先做自己的事情，有空的時候過來拿走快遞。
終於，我們再看到小明和快遞員的時候每個人都笑容滿面。
這裡的快遞櫃就相當於是程式設計世界的訊息佇列，讓我們看看訊息佇列到底起到了什麼作用。
此時，快遞員只需要把快遞放到櫃子裡，不需要關心小明是否在家，是否在睡覺。小明也不需要一直等待給快遞員開門，兩個人解耦了。
快遞員把快遞放到櫃子裡發個資訊就可以去送下一件，不需同步等待結果。
這樣每個快遞的處理速度（響應時間）都變得極短，每天送的快遞數量（吞吐量）也變多了。
這次又到了雙十一，小明還是一天要到100個快遞，由於小明一天只能消化10個快遞，剩下的就放在了櫃子裡，等10天後才拿完。
快遞員由於是非同步送快遞，雙11根本不是事，這點吞吐量完全搞得定。
小明以前需要一件一件收取快遞，現在放在了櫃子（佇列）裡，那等攢夠了10件去取一次（buffer->reduce），好省時間！其他時間都可以快快樂樂約會了。
讓我們再來總結一下非同步訊息佇列的作用
解耦，生產端和消費端不需要相互依賴
非同步，生產端不需要等待消費端響應，直接返回，提高了響應時間和吞吐量
削峰，打平高峰期的流量，消費端可以以自己的速度處理，同時也無需在高峰期增加太多資源，提高資源利用率
提高消費端效能。消費端可以利用buffer等機制，做批量處理，提高效率。
解耦的簡單理解
重用性是物件導向設計的主要目標之一，而緊耦合便是它的敵人。當我們看到系統中乙個元件的改變迫使系統其他許多地方也發生改變的時候，就可以診斷為緊耦合了。簡單實現 class registrationmgr abstract class notifier else abstract function in...
對於解耦的理解
以三層為例子 在bll層中建立dal層的某個物件 iuserdal userdal dalabstractfactory.createuserdal 即層之間的關聯降到最低，這樣我們很容易想到引用乙個第三方來作為中間介質。這就引出了介面，在層中要建立其他層的某個物件時，用介面來接收這個物件，這個介面...
非同步解耦日誌模組實現思路
日誌使我們系統中必不可少的元素，他的特點是比較多。為了不讓日誌影響我們的正常的業務響應速度，採用了如下設計。1 採用日誌池概念，當業務系統產生一條日誌時候，我們直接丟在日誌池裡面，單獨開乙個執行緒把日誌池中快取的日誌寫入資料庫。2 業務系統解耦，一般的操作我們都想記錄使用者的 ip所以我們可以新建 ...