RocketMQ 是一個 佇列模型 的訊息中間件，具有高性能、高可靠、高實時、分布式 的特點，它是一個采用 Java 語言開發的分布式的訊息系統，由阿里巴巴團隊開發，在2016年底貢獻給 Apache ，成為了 Apache 的一個頂級專案，在阿里內部， RocketMQ 很好地服務了集團大大小小上千個應用，在每年的雙十一當天，更有不可思議的萬億級訊息通過 RocketMQ 流轉，

廢話不多說，想要了解 RocketMQ 歷史的同學可以自己去搜尋資料，聽完上面的介紹，你只要知道RocketMQ 很快、很牛、而且經歷過雙十一的實踐就行了！

三、佇列模型和主題模型

在談 RocketMQ 的技術架構之前，我們先來了解一下兩個名詞概念——佇列模型 和 主題模型 ，

首先我問一個問題，訊息佇列為什么要叫訊息佇列？

你可能覺得很弱智，這玩意不就是存放訊息的佇列嘛？不叫訊息佇列叫什么？

的確，早期的訊息中間件是通過佇列這一模型來實作的，可能是歷史原因，我們都習慣把訊息中間件成為訊息佇列，

但是，如今例如 RocketMQ 、 Kafka 這些優秀的訊息中間件不僅僅是通過一個佇列來實作訊息存盤的，

1.佇列模型

就像我們理解佇列一樣，訊息中間件的佇列模型就真的只是一個佇列，，，我畫一張圖給大家理解，

在一開始我跟你提到了一個 “廣播” 的概念，也就是說如果我們此時我們需要將一個訊息發送給多個消費者(比如此時我需要將資訊發送給短信系統和郵件系統)，這個時候單個佇列即不能滿足需求了，

當然你可以讓 Producer 生產訊息放入多個佇列中，然后每個佇列去對應每一個消費者，問題是可以解決，創建多個佇列并且復制多份訊息是會很影響資源和性能的，而且，這樣子就會導致生產者需要知道具體消費者個數然后去復制對應數量的訊息佇列，這就違背我們訊息中間件的解耦這一原則，

2.主題模型

那么有沒有好的方法去解決這一個問題呢？有，那就是 主題模型 或者可以稱為 發布訂閱模型 ，

感興趣的同學可以去了解一下設計模式里面的觀察者模式并且手動實作一下，我相信你會有所識訓的，

在主題模型中，訊息的生產者稱為 發布者(Publisher) ，訊息的消費者稱為 訂閱者(Subscriber) ，存放訊息的容器稱為 主題(Topic) ，

其中，發布者將訊息發送到指定主題中，訂閱者需要 提前訂閱主題 才能接受特定主題的訊息，

3.RocketMQ中的訊息模型

RockerMQ 中的訊息模型就是按照 主題模型 所實作的，你可能會好奇這個主題到底是怎么實作的呢？你上面也沒有講到呀！

其實對于主題模型的實作來說每個訊息中間件的底層設計都是不一樣的，就比如 Kafka 中的磁區， RocketMQ 中的佇列， RabbitMQ 中的 Exchange ，我們可以理解為 主題模型/發布訂閱模型 就是一個標準，那些中間件只不過照著這個標準去實作而已，

所以， RocketMQ 中的 主題模型 到底是如何實作的呢？首先我畫一張圖，大家嘗試著去理解一下，

我們可以看到在整個圖中有 Producer Group 、 Topic 、 Consumer Group 三個角色，我來分別介紹一下他們，

Producer Group 生產者組：代表某一類的生產者，比如我們有多個秒殺系統作為生產者，這多個合在一起就是一個 Producer Group 生產者組，它們一般生產相同的訊息，
Consumer Group 消費者組：代表某一類的消費者，比如我們有多個短信系統作為消費者，這多個合在一起就是一個 Consumer Group 消費者組，它們一般消費相同的訊息，
Topic 主題：代表一類訊息，比如訂單訊息，物流訊息等等，

你可以看到圖中生產者組中的生產者會向主題發送訊息，而 主題中存在多個佇列，生產者每次生產訊息之后是指定主題中的某個佇列發送訊息的，

每個主題中都有多個佇列(這里還不涉及到 Broker )，集群消費模式下，一個消費者集群多臺機器共同消費一個 topic 的多個佇列，一個佇列只會被一個消費者消費，如果某個消費者掛掉，分組內其它消費者會接替掛掉的消費者繼續消費，就像上圖中 Consumer1 和 Consumer2 分別對應著兩個佇列，而Consuer3 是沒有佇列對應的，所以一般來講要控制 消費者組中的消費者個數和主題中佇列個數相同，

當然也可以消費者個數小于佇列個數，只不過不太建議，如下圖，

每個消費組在每個佇列上維護一個消費位置 ，為什么呢？

因為我們剛付訓的僅僅是一個消費者組，我們知道在發布訂閱模式中一般會涉及到多個消費者組，而每個消費者組在每個佇列中的消費位置都是不同的，如果此時有多個消費者組，那么訊息被一個消費者組消費完之后是不會洗掉的(因為其它消費者組也需要呀)，它僅僅是為每個消費者組維護一個 消費位移(offset) ，每次消費者組消費完會回傳一個成功的回應，然后佇列再把維護的消費位移加一，這樣就不會出現剛剛消費過的訊息再一次被消費了，

可能你還有一個問題，為什么一個主題中需要維護多個佇列 ？

答案是 提高并發能力 ，的確，每個主題中只存在一個佇列也是可行的，你想一下，如果每個主題中只存在一個佇列，這個佇列中也維護著每個消費者組的消費位置，這樣也可以做到 發布訂閱模式 ，如下圖：

但是，這樣我生產者是不是只能向一個佇列發送訊息？又因為需要維護消費位置所以一個佇列只能對應一個消費者組中的消費者，這樣是不是其他的 Consumer 就沒有用武之地了？從這兩個角度來講，并發度一下子就小了很多，

所以總結來說， RocketMQ 通過使用在一個 Topic 中配置多個佇列并且每個佇列維護每個消費者組的消費位置 實作了 主題模式/發布訂閱模式 ，

四、RocketMQ的架構圖

講完了訊息模型，我們理解起 RocketMQ 的技術架構起來就容易多了，

RocketMQ 技術架構中有四大角色 NameServer 、 Broker 、 Producer 、 Consumer ，我來向大家分別解釋一下這四個角色是干啥的，

Broker ：主要負責訊息的存盤、投遞和查詢以及服務高可用保證，說白了就是訊息佇列服務器嘛，生產者生產訊息到 Broker ，消費者從 Broker 拉取訊息并消費，
這里，我還得普及一下關于 Broker 、 Topic 和佇列的關系，上面我講解了 Topic 和佇列的關系——一個 Topic 中存在多個佇列，那么這個 Topic 和佇列存放在哪呢？
一個 Topic 分布在多個 Broker 上，一個 Broker 可以配置多個 Topic ，它們是多對多的關系，
如果某個 Topic 訊息量很大，應該給它多配置幾個佇列(上文中提到了提高并發能力)，并且 盡量多分布在不同 Broker 上，以減輕某個 Broker 的壓力 ，
Topic 訊息量都比較均勻的情況下，如果某個 broker 上的佇列越多，則該 broker 壓力越大，

所以說我們需要配置多個Broker，

NameServer ：不知道你們有沒有接觸過 ZooKeeper 和 Spring Cloud 中的 Eureka ，它其實也是一個 注冊中心 ，主要提供兩個功能：Broker管理 和 路由資訊管理 ，說白了就是 Broker 會將自己的資訊注冊到NameServer 中，此時 NameServer 就存放了很多 Broker 的資訊(Broker的路由表)，消費者和生產者就從 NameServer 中獲取路由表然后照著路由表的資訊和對應的Broker 進行通信(生產者和消費者定期會向 NameServer 去查詢相關的 Broker 的資訊)，
Producer ：訊息發布的角色，支持分布式集群方式部署，說白了就是生產者，
Consumer ：訊息消費的角色，支持分布式集群方式部署，支持以push推，pull拉兩種模式對訊息進行消費，同時也支持集群方式和廣播方式的消費，它提供實時訊息訂閱機制，說白了就是消費者，

聽完了上面的解釋你可能會覺得，這玩意好簡單，不就是這樣的么？

嗯？你可能會發現一個問題，這老家伙 NameServer 干啥用的，這不多余嗎？直接 Producer 、 Consumer 和 Broker 直接進行生產訊息，消費訊息不就好了么？

但是，我們上文提到過 Broker 是需要保證高可用的，如果整個系統僅僅靠著一個 Broker 來維持的話，那么這個 Broker 的壓力會不會很大？所以我們需要使用多個 Broker 來保證 負載均衡 ，

如果說，我們的消費者和生產者直接和多個 Broker 相連，那么當 Broker修改的時候必定會牽連著每個生產者和消費者，這樣就會產生耦合問題，而 NameServer 注冊中心就是用來解決這個問題的，

如果還不是很理解的話，可以去看我介紹 Spring Cloud 的那篇文章，其中介紹了 Eureka 注冊中心，

當然， RocketMQ 中的技術架構肯定不止前面那么簡單，因為上面圖中的四個角色都是需要做集群的，我給出一張官網的架構圖，大家嘗試理解一下，

其實和我們最開始畫的那張乞丐版的架構圖也沒什么區別，主要是一些細節上的差別，聽我細細道來，

第一、我們的 Broker 做了集群并且還進行了主從部署 ，由于訊息分布在各個 Broker 上，一旦某個 Broker 宕機，則該 Broker 上的訊息讀寫都會受到影響，所以 Rocketmq 提供了 master/slave 的結構， salve 定時從 master 同步資料(同步刷盤或者異步刷盤)，如果 master 宕機，則 slave 提供消費服務，但是不能寫入訊息 (后面我還會提到哦)，

第二、為了保證 HA ，我們的 NameServer 也做了集群部署，但是請注意它是 去中心化 的，也就意味著它沒有主節點，你可以很明顯地看出 NameServer 的所有節點是沒有進行 Info Replicate 的，在 RocketMQ 中是通過 單個Broker和所有NameServer保持長連接 ，并且在每隔30秒 Broker 會向所有 Nameserver 發送心跳，心跳包含了自身的 Topic 配置資訊，這個步驟就對應這上面的 Routing Info ，

第三、在生產者需要向 Broker 發送訊息的時候，需要先從 NameServer 獲取關于 Broker 的路由資訊，然后通過輪詢的方法去向每個佇列中生產資料以達到 負載均衡 的效果，

第四、消費者通過 NameServer 獲取所有 Broker 的路由資訊后，向 Broker 發送 Pull 請求來獲取訊息資料， Consumer 可以以兩種模式啟動—— 廣播（Broadcast）和集群（Cluster），廣播模式下，一條訊息會發送給 同一個消費組中的所有消費者 ，集群模式下訊息只會發送給一個消費者，

五、如何解決順序消費、重復消費

其實，這些東西都是我在介紹訊息佇列帶來的一些副作用的時候提到的，也就是說，這些問題不僅僅掛鉤于 RocketMQ ，而是應該每個訊息中間件都需要去解決的，

在上面我介紹 RocketMQ 的技術架構的時候我已經向你展示了 它是如何保證高可用的 ，這里不涉及運維方面的搭建，如果你感興趣可以自己去官網上照著例子搭建屬于你自己的 RocketMQ 集群，

其實 Kafka 的架構基本和 RocketMQ 類似，只是它注冊中心使用了 Zookeeper 、它的磁區就相當于 RocketMQ 中的佇列，還有一些小細節不同會在后面提到，

1.順序消費

在上面的技術架構介紹中，我們已經知道了 RocketMQ 在主題上是無序的、它只有在佇列層面才是保證有序 的，

這又扯到兩個概念——普通順序 和 嚴格順序 ，

所謂普通順序是指消費者通過 同一個消費佇列收到的訊息是有順序的 ，不同訊息佇列收到的訊息則可能是無順序的，普通順序訊息在 Broker 重啟情況下不會保證訊息順序性 (短暫時間) ，

所謂嚴格順序是指消費者收到的 所有訊息 均是有順序的，嚴格順序訊息 即使在例外情況下也會保證訊息的順序性 ，

但是，嚴格順序看起來雖好，實作它可會付出巨大的代價，如果你使用嚴格順序模式， Broker 集群中只要有一臺機器不可用，則整個集群都不可用，你還用啥？現在主要場景也就在 binlog 同步，

一般而言，我們的 MQ 都是能容忍短暫的亂序，所以推薦使用普通順序模式，

那么，我們現在使用了 普通順序模式 ，我們從上面學習知道了在 Producer 生產訊息的時候會進行輪詢(取決你的負載均衡策略)來向同一主題的不同訊息佇列發送訊息，那么如果此時我有幾個訊息分別是同一個訂單的創建、支付、發貨，在輪詢的策略下這 三個訊息會被發送到不同佇列 ，因為在不同的佇列此時就無法使用 RocketMQ 帶來的佇列有序特性來保證訊息有序性了，

那么，怎么解決呢？

其實很簡單，我們需要處理的僅僅是將同一語意下的訊息放入同一個佇列(比如這里是同一個訂單)，那我們就可以使用 Hash取模法 來保證同一個訂單在同一個佇列中就行了，

2.重復消費

emmm，就兩個字—— 冪等，在編程中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同，比如說，這個時候我們有一個訂單的處理積分的系統，每當來一個訊息的時候它就負責為創建這個訂單的用戶的積分加上相應的數值，可是有一次，訊息佇列發送給訂單系統 FrancisQ 的訂單資訊，其要求是給 FrancisQ 的積分加上 500，但是積分系統在收到 FrancisQ 的訂單資訊處理完成之后回傳給訊息佇列處理成功的資訊的時候出現了網路波動(當然還有很多種情況，比如Broker意外重啟等等)，這潭訓應沒有發送成功，

那么，訊息佇列沒收到積分系統的回應會不會嘗試重發這個訊息？問題就來了，我再發這個訊息，萬一它又給 FrancisQ 的賬戶加上 500 積分怎么辦呢？

所以我們需要給我們的消費者實作冪等，也就是對同一個訊息的處理結果，執行多少次都不變，

那么如何給業務實作冪等呢？這個還是需要結合具體的業務的，你可以使用寫入 Redis 來保證，因為 Redis 的 key 和 value 就是天然支持冪等的，當然還有使用 資料庫插入法 ，基于資料庫的唯一鍵來保證重復資料不會被插入多條，

不過最主要的還是需要 根據特定場景使用特定的解決方案 ，你要知道你的訊息消費是否是完全不可重復消費還是可以忍受重復消費的，然后再選擇強校驗和弱校驗的方式，畢竟在 CS 領域還是很少有技術銀彈的說法，

而在整個互聯網領域，冪等不僅僅適用于訊息佇列的重復消費問題，這些實作冪等的方法，也同樣適用于，在其他場景中來解決重復請求或者重復呼叫的問題 ，比如將HTTP服務設計成冪等的，解決前端或者APP重復提交表單資料的問題 ，也可以將一個微服務設計成冪等的，解決 RPC 框架自動重試導致的重復呼叫問題 ，

六、分布式事務

如何解釋分布式事務呢？事務大家都知道吧？要么都執行要么都不執行 ，在同一個系統中我們可以輕松地實作事務，但是在分布式架構中，我們有很多服務是部署在不同系統之間的，而不同服務之間又需要進行呼叫，比如此時我下訂單然后增加積分，如果保證不了分布式事務的話，就會出現A系統下了訂單，但是B系統增加積分失敗或者A系統沒有下訂單，B系統卻增加了積分，前者對用戶不友好，后者對運營商不利，這是我們都不愿意見到的，

那么，如何去解決這個問題呢？

如今比較常見的分布式事務實作有 2PC、TCC 和事務訊息(half 半訊息機制)，每一種實作都有其特定的使用場景，但是也有各自的問題，都不是完美的解決方案，

在 RocketMQ 中使用的是 事務訊息加上事務反查機制 來解決分布式事務問題的，我畫了張圖，大家可以對照著圖進行理解，

在第一步發送的 half 訊息，它的意思是 在事務提交之前，對于消費者來說，這個訊息是不可見的 ，

那么，如何做到寫入訊息但是對用戶不可見呢？RocketMQ事務訊息的做法是：如果訊息是half訊息，將備份原訊息的主題與訊息消費佇列，然后 改變主題 為RMQ_SYS_TRANS_HALF_TOPIC，由于消費組未訂閱該主題，故消費端無法消費half型別的訊息，然后RocketMQ會開啟一個定時任務，從Topic為RMQ_SYS_TRANS_HALF_TOPIC中拉取訊息進行消費，根據生產者組獲取一個服務提供者發送回查事務狀態請求，根據事務狀態來決定是提交或回滾訊息，

你可以試想一下，如果沒有從第5步開始的 事務反查機制 ，如果出現網路波動第4步沒有發送成功，這樣就會產生 MQ 不知道是不是需要給消費者消費的問題，他就像一個無頭蒼蠅一樣，在 RocketMQ 中就是使用的上述的事務反查來解決的，而在 Kafka 中通常是直接拋出一個例外讓用戶來自行解決，

你還需要注意的是，在 MQ Server 指向系統B的操作已經和系統A不相關了，也就是說在訊息佇列中的分布式事務是——本地事務和存盤訊息到訊息佇列才是同一個事務，這樣也就產生了事務的最終一致性，因為整個程序是異步的，每個系統只要保證它自己那一部分的事務就行了，

七、訊息堆積問題

在上面我們提到了訊息佇列一個很重要的功能——削峰，那么如果這個峰值太大了導致訊息堆積在佇列中怎么辦呢？

其實這個問題可以將它廣義化，因為產生訊息堆積的根源其實就只有兩個——生產者生產太快或者消費者消費太慢，

我們可以從多個角度去思考解決這個問題，當流量到峰值的時候是因為生產者生產太快，我們可以使用一些 限流降級 的方法，當然你也可以增加多個消費者實體去水平擴展增加消費能力來匹配生產的激增，如果消費者消費過慢的話，我們可以先檢查 是否是消費者出現了大量的消費錯誤 ，或者列印一下日志查看是否是哪一個執行緒卡死，出現了鎖資源不釋放等等的問題，

當然，最快速解決訊息堆積問題的方法還是增加消費者實體，不過 同時你還需要增加每個主題的佇列數量 ，
別忘了在 RocketMQ 中，一個佇列只會被一個消費者消費 ，如果你僅僅是增加消費者實體就會出現我一開始給你畫架構圖的那種情況，

八、回溯消費

回溯消費是指 Consumer 已經消費成功的訊息，由于業務上需求需要重新消費，在 RocketMQ 中， Broker 在向 Consumer 投遞成功訊息后，訊息仍然需要保留 ，并且重新消費一般是按照時間維度，例如由于 Consumer 系統故障，恢復后需要重新消費1小時前的資料，那么 Broker 要提供一種機制，可以按照時間維度來回退消費進度， RocketMQ 支持按照時間回溯消費，時間維度精確到毫秒，

九、RocketMQ 的刷盤機制

上面我講了那么多的 RocketMQ 的架構和設計原理，你有沒有好奇

在 Topic 中的 佇列是以什么樣的形式存在的？

佇列中的訊息又是如何進行存盤持久化的呢？

我在上文中提到的 同步刷盤 和 異步刷盤 又是什么呢？它們會給持久化帶來什么樣的影響呢？

下面我將給你們一一解釋，

1.同步刷盤和異步刷盤

如上圖所示，在同步刷盤中需要等待一個刷盤成功的 ACK ，同步刷盤對 MQ 訊息可靠性來說是一種不錯的保障，但是 性能上會有較大影響 ，一般地適用于金融等特定業務場景，

而異步刷盤往往是開啟一個執行緒去異步地執行刷盤操作，訊息刷盤采用后臺異步執行緒提交的方式進行，降低了讀寫延遲 ，提高了 MQ 的性能和吞吐量，一般適用于如發驗證碼等對于訊息保證要求不太高的業務場景，

最后

權威指南-第一本Docker書

引領完成Docker的安裝、部署、管理和擴展，讓其經歷從測驗到生產的整個開發生命周期，深入了解Docker適用于什么場景，并且這本Docker的學習權威指南介紹了其組件的基礎知識，然后用Docker構建容器和服務來完成各種任務：利用Docker為新專案建立測驗環境，演示如何使用持續集成的作業流集成Docker，如何構建應用程式服務和平臺，如何使用Docker的API，如何擴展Docker，

總共包含了：簡介、安裝Docker、Docker入門、使用Docker鏡像和倉庫、在測驗中使用Docker、使用Docker構建服務、使用Fig編配Docke、使用Docker API、獲得幫助和對Docker進行改進等9個章節的知識，