訊息佇列提供了分布式集群系統架構中各個服務模組之間的訊息通訊，主
要解決應用解耦，非同步訊息，流量削鋒等問題，實現高效能，高可用，可伸縮
和最終一致性架構，其模型如下：
應用解耦
✓ 模組之間僅依賴「通知」，而沒有直接的介面呼叫，所以不存在依賴
◼ 可擴充套件性
✓ 佇列支援高可用部署，水平擴充套件容量和吞吐量
✓ 生產者和消費者都只關心「通知」，訊息佇列提供通知機制，業務眾向擴充套件
◼ 非同步處理
✓ 生產者只管保證把「通知」傳送出去，並不關心下游處理結果，允許多個消費者同時消費
◼ 削峰填谷
✓ 訊息佇列「堆積」訊息，只要不溢位就行
發布訂閱的兩種模式
第一種：生產者發布給mq，然後由mq推送給訂閱訊息的消費者。
mq不斷主動把訊息推送給消費者，如果消費者處理能力不高，有可能造成消費者本地快取溢位，但是訊息能及時被消費；例如rabbitmq就支援這種模式。
模型如下：
第二種：消費者主動到mq拉取訊息，所以會造成訊息並沒有即時消費，但是能控制消費的速度，例如kafka支援這種模式。
模型如下：
可靠投遞
✓ 事物機制
比如rabbitmq中與事務機制有關的方法有三個： txselect(), txcommit()以及txrollback(),
txselect用於將當前channel設定成transaction模式， txcommit用於提交事務， txrollback用於回
滾事務，在通過txselect開啟事務之後，我們便可以發布訊息給broker**伺服器了，如果
txcommit提交成功了，則訊息一定到達了broker了，如果在txcommit執行之前broker異常崩潰
或者由於其他原因丟擲異常，這個時候我們便可以捕獲異常通過txrollback回滾事務了。
✓ 確認機制
假如現在有m1,m2兩個訊息，為了能夠讓兩個訊息順序被消費，那生產者需要順序的往同乙個route去發布訊息。
網路始終有時候是不可靠的，所以為了可靠投遞和可靠消費，都會設計重發
某條沒有收到ack的訊息，那麼這就有可能導致消費端重複消費訊息，那如何去
重？✓ 冪等性
消費端處理業務訊息要保持冪等性，也就是同乙個東西執行多次會得到相同結果；
✓ 去重表
保證每條訊息都有唯一編號且保證訊息處理成功與去重表的日誌同時出現；
有意思的是rocketmq恰恰把這個問題丟給了使用者，而rocketmq本身沒有實現。
是指產生訊息的業務動作、訊息傳送和訊息消費的一致性，比如一筆訂單
支付成功了，需要扣庫存。
場景：支付業務處理成功，執行傳送訊息的時候應用出現故障，導致沒有傳送訊息（後續服務沒有收到訊息處
理業務，結果資料不一致）
業務處理成功，執行傳送訊息的時候，訊息系統（mq）故障，導致訊息傳送失敗（後續服務沒有收到
訊息處理業務，結果資料不一致）
扣庫存失敗，導致資料不一致
高併發與分布式
一提到高併發很多人就會想到分布式，那麼二者到底有什麼區別呢？併發和分布是完全不同的概念。分布是將任務分發到不同的點上去，一般分布式最多的就是分布式計算。通過某種分布式程式設計方式，在不同的系統上利用各自的cpu，記憶體等進行計算，將結果匯集至控制中心，進行處理。比如最有名的就是分布式計算天氣的氣候阿...
分布式，避免高併發
高併發 high concurrency 是網際網路分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。吞吐量 單位時間內處理的請求數量。qps 每秒響應請求數。在網際網路領域，這個指標和吞吐量區分的沒有這麼明顯。網際網路分布式架構設計，提高系統併發能力的方...
高併發 分布式事務
一 2pc two phase commitment 請求進來，生成全域性雪花id，存本地執行緒變數，存request請求頭部head 消費者請求走服務1，自己做hystrix熔斷 服務裡面以標籤配置事務，事務做切點的攔截，切面幹事情，開啟子執行緒，且把子執行緒阻塞，一旦放開阻塞走提交。請求主線程繼...