現在假設這樣乙個場景，使用者下單成功需要給使用者發簡訊，如果沒有訊息佇列，我們會選擇同步呼叫發簡訊的介面並等待簡訊傳送成功。現在假設簡訊介面實現出現了問題或者簡訊傳送短時間內達到了上限，這個時候是選擇重試幾次還是放棄傳送呢？這裡的設計會很複雜。如果使用了訊息佇列，我們選擇將發簡訊的操作封裝成一條訊息傳送到訊息佇列，訊息佇列通知乙個服務去傳送一條簡訊，即使出現了上述的問題，可以選擇把訊息重新放到訊息佇列裡等待處理。
通過上述了例子，我們看到訊息佇列完成了乙個非同步解耦的過程，簡訊傳送時我們只要保證簡訊發到訊息佇列成功就可以了，接下來就可以去做別的事情；其次，設計變得更簡單，在下單的場景下，我們不用過多考慮傳送簡訊的問題，交給訊息佇列管理就行了，可能簡訊傳送會有延遲，但是保證了最終的一致性。
（1）業務解耦
成功完成了乙個非同步解耦的過程。簡訊傳送時只要保證放到訊息佇列中就可以了，接著做後面的事情就行。乙個事務只關心本質的流程，需要依賴其他事情但是不那麼重要的時候，有通知即可，無需等待結果。每個成員不必受其他成員影響，可以更獨立自主，只通過乙個簡單的容器來聯絡。
對於我們的訂單系統，訂單最終支付成功之後可能需要給使用者傳送簡訊積分什麼的，但其實這已經不是我們系統的核心流程了。如果外部系統速度偏慢（比如簡訊閘道器速度不好），那麼主流程的時間會加長很多，使用者肯定不希望點選支付過好幾分鐘才看到結果。那麼我們只需要通知簡訊系統「我們支付成功了」，不一定非要等待它處理完成。
（2）最終一致性
主要是用記錄和補償的方式來處理；在做所有的不確定事情之前，先把事情記錄下來，然後去做不確定的事，它的結果通常分為三種：成功，失敗或者不確定；如果成功，我們就可以把記錄的東西清理掉，對於失敗和不確定，我們可以採用定時任務的方式把所有失敗的事情重新做一遍直到成功為止。
保證了最終一致性，通過在佇列中存放任務保證它最終一定會執行。
最終一致性指的是兩個系統的狀態保持一致，要麼都成功，要麼都失敗。當然有個時間限制，理論上越快越好，但實際上在各種異常的情況下，可能會有一定延遲達到最終一致狀態，但最後兩個系統的狀態是一樣的。
業界有一些為「最終一致性」而生的訊息佇列，如notify（阿里）、qmq（去哪兒）等，其設計初衷，就是為了交易系統中的高可靠通知。
以乙個銀行的轉賬過程來理解最終一致性，轉賬的需求很簡單，如果a系統扣錢成功，則b系統加錢一定成功。反之則一起回滾，像什麼都沒發生一樣。
然而，這個過程中存在很多可能的意外：
可見，想把這件看似簡單的事真正做成，真的不那麼容易。所有跨jvm的一致性問題，從技術的角度講通用的解決方案是：
回到剛才的例子，系統在a扣錢成功的情況下，把要給b「通知」這件事記錄在庫里（為了保證最高的可靠性可以把通知b系統加錢和扣錢成功這兩件事維護在乙個本地事務裡），通知成功則刪除這條記錄，通知失敗或不確定則依靠定時任務補償性地通知我們，直到我們把狀態更新成正確的為止。
訊息可能重複，注意訊息的重複和冪等。
（3）廣播
如果沒有訊息佇列，每當乙個新的業務接入時，我們都需要連線乙個新介面；有了訊息佇列，我們只需要關係訊息是否送到到訊息佇列，新接入的介面訂閱相關的訊息，自己去做處理就行了。
（4）錯峰與流控
利用訊息佇列，轉儲兩個系統的通訊內容，並在下游系統有能力處理這些訊息的時候再處理這些訊息。試想上下游對於事情的處理能力是不同的。比如，web前端每秒承受上千萬的請求，並不是什麼神奇的事情，只需要加多一點機器，再搭建一些lvs負載均衡裝置和nginx等即可。但資料庫的處理能力卻十分有限，即使使用ssd加分庫分表，單機的處理能力仍然在萬級。由於成本的考慮，我們不能奢求資料庫的機器數量追上前端。
這種問題同樣存在於系統和系統之間，如簡訊系統可能由於短板效應，速度卡在閘道器上（每秒幾百次請求），跟前端的併發量不是乙個數量級。但使用者晚上個半分鐘左右收到簡訊，一般是不會有太大問題的。如果沒有訊息佇列，兩個系統之間通過協商、滑動視窗等複雜的方案也不是說不能實現。但系統複雜性指數級增長，勢必在上游或者下游做儲存，並且要處理定時、擁塞等一系列問題。而且每當有處理能力有差距的時候，都需要單獨開發一套邏輯來維護這套邏輯。所以，利用中間系統轉儲兩個系統的通訊內容，並在下游系統有能力處理這些訊息的時候，再處理這些訊息，是一套相對較通用的方式。
總而言之，訊息佇列不是萬能的。對於需要強事務保證而且延遲敏感的，rpc是優於訊息佇列的。
對於一些無關痛癢，或者對於別人非常重要但是對於自己不是那麼關心的事情，可以利用訊息佇列去做。
支援最終一致性的訊息佇列，能夠用來處理延遲不那麼敏感的「分布式事務」場景，而且相對於笨重的分布式事務，可能是更優的處理方式。
當上下游系統處理能力存在差距的時候，利用訊息佇列做乙個通用的「漏斗」。在下游有能力處理的時候，再進行分發。
如果下游有很多系統關心你的系統發出的通知的時候，果斷地使用訊息佇列吧。
訊息佇列入門
訊息佇列功能介紹 字面上說的訊息佇列是資料結構中 先進先出 的一種資料結構，但是如果要求消除單點故障，保證訊息傳輸可靠性，應對大流量的衝擊，對訊息佇列的要求就很高了。現在網際網路的 微架構 模式興起，原有的大型集中式的it服務因為各種弊端，通常被拆分成細粒度的多個 微服務 這些微服務可以在乙個區域網...
單調佇列 入門
今天寫了人生中第乙個單調佇列,激動ing 先看一道單調佇列的入門題 乙個含有n項的數列 n 2000000 求出每一項前面的第m個數到它這個區間內的最小值。先寫出動規方程 f i min j合法 很明顯的,這是乙個n 2的動規,但是,我們可以注意到,數列中有些數無論如何都不會被選到.如 1 2 8 ...
C STL 佇列入門
2 queue queue 模板類的定義在標頭檔案中。與stack 模板類很相似，queue 模板類也需要兩個模板引數，乙個是元素型別，乙個容器類 型，元素型別是必要的，容器型別是可選的，預設為deque 型別。定義queue 物件的示例 如下 queueq1 queueq2 queue 的基本操作...