0. Docker下RocketMq的搭建

官方提供多種玩法：

• Single Node.
• Cluster with docker-compose.
• Cluster on Kubernetes.
  這里采取docker-compose顶捷。

0.1 鏡像

docker hub有來自官方的鏡像促煮，只需要docker pull rocketmqinc/rocketmq即可。
自己build鏡像可以參考rocketmq-docker/image-build秧荆。

0.2 docker-compose玩法

查看rocketmq-docker/templates/docker-compose目錄，可以看到這里提供了相應(yīng)的配置文件和目錄結(jié)構(gòu)杭朱。于是我得到下面的目錄結(jié)構(gòu)：

image.png

version: '2'
services:
  #Service for nameserver
  namesrv:
    image: rocketmqinc/rocketmq
    container_name: rmqnamesrv
    ports:
      - 9876:9876
    volumes:
      - ./data/namesrv/logs:/home/rocketmq/logs
      - ./data/namesrv/store:/home/rocketmq/store
    command: sh mqnamesrv

  #Service for broker
  broker:
    image: rocketmqinc/rocketmq
    container_name: rmqbroker
    links:
      - namesrv
    ports:
      - 10909:10909
      - 10911:10911
    environment:
      - NAMESRV_ADDR=namesrv:9876
    volumes:
      - ./data/broker/logs:/home/rocketmq/logs
      - ./data/broker/store:/home/rocketmq/store
      - ./data/broker/conf/broker.conf:/opt/rocketmq-4.4.0/conf/broker.conf
    command: sh mqbroker -c ../conf/broker.conf

  #Service for another broker -- broker1
  broker1:
    image: rocketmqinc/rocketmq
    container_name: rmqbroker1
    links:
      - namesrv
    ports:
      - 10929:10909
      - 10931:10911
    environment:
      - NAMESRV_ADDR=namesrv:9876
    volumes:
      - ./data1/broker/logs:/home/rocketmq/logs
      - ./data1/broker/store:/home/rocketmq/store
      - ./data1/broker/conf/broker.conf:/opt/rocketmq-4.4.0/conf/broker.conf
    command: sh mqbroker -c ../conf/broker.conf

好了佑颇，docker-compose up運(yùn)行一下顶掉，為了看運(yùn)行狀態(tài)信息，這里沒加 -d挑胸，可以看到：

image.png

查看官方的README.md文件，驗(yàn)證一下是否正常。

image.png

image.png

這一步?jīng)]問題移袍，試試下一步：
2.Use docker exec -it {container_id} ./mqadmin clusterList -n {nameserver_ip}:9876
首先先獲取一下nameserver的容器IP。兩個(gè)命令老充，先拿nameserver的容器ID, ````：

image.png

image.png

image.png

image.png

image.png

- JAVA_HOME=/usr/lib/jvm/jre

完整配置如下：

version: '2'
services:
  #Service for nameserver
  namesrv:
    image: rocketmqinc/rocketmq
    container_name: rmqnamesrv
    ports:
      - 9876:9876
    volumes:
      - ./data/namesrv/logs:/home/rocketmq/logs
      - ./data/namesrv/store:/home/rocketmq/store
    command: sh mqnamesrv

  #Service for broker
  broker:
    image: rocketmqinc/rocketmq
    container_name: rmqbroker
    links:
      - namesrv
    ports:
      - 10909:10909
      - 10911:10911
    environment:
      - NAMESRV_ADDR=namesrv:9876
      - JAVA_HOME=/usr/lib/jvm/jre
    volumes:
      - ./data/broker/logs:/home/rocketmq/logs
      - ./data/broker/store:/home/rocketmq/store
      - ./data/broker/conf/broker.conf:/opt/rocketmq-4.4.0/conf/broker.conf
    command: sh mqbroker -c ../conf/broker.conf

  #Service for another broker -- broker1
  broker1:
    image: rocketmqinc/rocketmq
    container_name: rmqbroker1
    links:
      - namesrv
    ports:
      - 10929:10909
      - 10931:10911
    environment:
      - NAMESRV_ADDR=namesrv:9876
      - JAVA_HOME=/usr/lib/jvm/jre
    volumes:
      - ./data1/broker/logs:/home/rocketmq/logs
      - ./data1/broker/store:/home/rocketmq/store
      - ./data1/broker/conf/broker.conf:/opt/rocketmq-4.4.0/conf/broker.conf
    command: sh mqbroker -c ../conf/broker.conf

重啟，再試一下：

image.png

1.服務(wù)端組件介紹

RocketMQ服務(wù)端的組件有三個(gè)窘拯，NameServer，Broker坝茎，F(xiàn)ilterServer（可選涤姊，部署于和Broker同一臺(tái)機(jī)器）

• Name Server
  Name Server是RocketMQ的尋址服務(wù)。用于把Broker的路由信息做聚合景东。客戶端依靠Name Server決定去獲取對(duì)應(yīng)topic的路由信息奔誓，從而決定對(duì)哪些Broker做連接斤吐。
  Name Server是一個(gè)幾乎無狀態(tài)的結(jié)點(diǎn)，Name Server之間采取share-nothing的設(shè)計(jì)厨喂，互不通信和措。
  對(duì)于一個(gè)Name Server集群列表，客戶端連接Name Server的時(shí)候蜕煌，只會(huì)選擇隨機(jī)連接一個(gè)結(jié)點(diǎn)派阱，以做到負(fù)載均衡。
  Name Server所有狀態(tài)都從Broker上報(bào)而來斜纪，本身不存儲(chǔ)任何狀態(tài)贫母，所有數(shù)據(jù)均在內(nèi)存。
  如果中途所有Name Server全都掛了盒刚，影響到路由信息的更新腺劣，不會(huì)影響和Broker的通信。

• Broker
  Broker是處理消息存儲(chǔ)因块，轉(zhuǎn)發(fā)等處理的服務(wù)器橘原。
  Broker以group分開，每個(gè)group只允許一個(gè)master，若干個(gè)slave趾断。
  只有master才能進(jìn)行寫入操作拒名，slave不允許。
  slave從master中同步數(shù)據(jù)芋酌。同步策略取決于master的配置增显，可以采用同步雙寫，異步復(fù)制兩種隔嫡。
  客戶端消費(fèi)可以從master和slave消費(fèi)甸怕。在默認(rèn)情況下，消費(fèi)者都從master消費(fèi)腮恩，在master掛后梢杭，客戶端由于從Name Server中感知到Broker掛機(jī)，就會(huì)從slave消費(fèi)秸滴。
  Broker向所有的NameServer結(jié)點(diǎn)建立長連接武契，注冊(cè)Topic信息。

• Filter Server（可選）
  RocketMQ可以允許消費(fèi)者上傳一個(gè)Java類給Filter Server進(jìn)行過濾荡含。
  Filter Server只能起在Broker所在的機(jī)器咒唆。
  拉取消息的時(shí)候，消息先經(jīng)過Filter Server释液，F(xiàn)ilter Server靠上傳的Java類過濾消息后才推給Consumer消費(fèi)全释。
  客戶端完全可以消費(fèi)消息的時(shí)候做過濾，不需要Filter Server误债。
  FilterServer存在的目的是用Broker的CPU資源換取網(wǎng)卡資源浸船。因?yàn)锽roker的瓶頸往往在網(wǎng)卡，而且CPU資源很閑寝蹈。在客戶端過濾會(huì)導(dǎo)致無需使用的消息在占用網(wǎng)卡資源李命。
  使用 Java 類上傳作為過濾表達(dá)式是一個(gè)雙刃劍，一方面方便了應(yīng)用的過濾操作且節(jié)省網(wǎng)卡資源箫老，另一方面也帶來了服務(wù)器端的安全風(fēng)險(xiǎn)封字，這需要足夠謹(jǐn)慎，消費(fèi)端上傳的class要保證過濾的代碼足夠安全——例如在過濾程序里盡可能不做申請(qǐng)大內(nèi)存耍鬓，創(chuàng)建線程等操作阔籽，避免 Broker 服務(wù)器資源泄漏。

2.核心概念及術(shù)語

角色

• Producer
  生產(chǎn)者牲蜀。發(fā)送消息的客戶端角色仿耽。發(fā)送消息的時(shí)候需要指定Topic。
• Consumer
  消費(fèi)者各薇。消費(fèi)消息的客戶端角色项贺。通常是后臺(tái)處理異步消費(fèi)的系統(tǒng)君躺。 RocketMQ中Consumer有兩種實(shí)現(xiàn)：PushConsumer和PullConsumer。
  1).PushConsumer
  推送模式（雖然RocketMQ使用的是長輪詢）的消費(fèi)者开缎。消息的能及時(shí)被消費(fèi)棕叫。使用非常簡單，內(nèi)部已處理如線程池消費(fèi)奕删、流控俺泣、負(fù)載均衡、異常處理等等的各種場景完残。
  2).PullConsumer
  拉取模式的消費(fèi)者伏钠。應(yīng)用主動(dòng)控制拉取的時(shí)機(jī)，怎么拉取谨设，怎么消費(fèi)等熟掂。主動(dòng)權(quán)更高。但要自己處理各種場景扎拣。

概念術(shù)語

• Producer Group
  標(biāo)識(shí)發(fā)送同一類消息的Producer赴肚，通常發(fā)送邏輯一致。發(fā)送普通消息的時(shí)候二蓝，僅標(biāo)識(shí)使用誉券，并無特別用處。若事務(wù)消息刊愚，如果某條發(fā)送某條消息的producer-A宕機(jī)踊跟，使得事務(wù)消息一直處于PREPARED狀態(tài)并超時(shí)，則broker會(huì)回查同一個(gè)group的其 他producer鸥诽，確認(rèn)這條消息應(yīng)該commit還是rollback商玫。但開源版本并不完全支持事務(wù)消息（閹割了事務(wù)回查的代碼）。
• Consumer Group
  標(biāo)識(shí)一類Consumer的集合名稱衙传，這類Consumer通常消費(fèi)一類消息决帖，且消費(fèi)邏輯一致厕九。同一個(gè)Consumer Group下的各個(gè)實(shí)例將共同消費(fèi)topic的消息蓖捶，起到負(fù)載均衡的作用。
  消費(fèi)進(jìn)度以Consumer Group為粒度管理扁远，不同Consumer Group之間消費(fèi)進(jìn)度彼此不受影響俊鱼，即消息A被Consumer Group1消費(fèi)過，也會(huì)再給Consumer Group2消費(fèi)畅买。
• Topic
  標(biāo)識(shí)一類消息的邏輯名字并闲，消息的邏輯管理單位。無論消息生產(chǎn)還是消費(fèi)谷羞，都需要指定Topic帝火。
• Tag
  RocketMQ支持給在發(fā)送的時(shí)候給topic打tag溜徙，同一個(gè)topic的消息雖然邏輯管理是一樣的。但是消費(fèi)topic1的時(shí)候犀填，如果你訂閱的時(shí)候指定的是tagA蠢壹，那么tagB的消息將不會(huì)投遞。
• Message Queue
  簡稱Queue或Q九巡。消息物理管理單位图贸。一個(gè)Topic將有若干個(gè)Q。若Topic同時(shí)創(chuàng)建在不同的Broker冕广，則不同的broker上都有若干Q疏日，消息將物理地存儲(chǔ)落在不同Broker結(jié)點(diǎn)上，具有水平擴(kuò)展的能力撒汉。
  無論生產(chǎn)者還是消費(fèi)者沟优，實(shí)際的生產(chǎn)和消費(fèi)都是針對(duì)Q級(jí)別。例如Producer發(fā)送消息的時(shí)候神凑，會(huì)預(yù)先選擇（默認(rèn)輪詢）好該Topic下面的某一條Q地發(fā)送净神；Consumer消費(fèi)的時(shí)候也會(huì)負(fù)載均衡地分配若干個(gè)Q，只拉取對(duì)應(yīng)Q的消息溉委。
  每一條message queue均對(duì)應(yīng)一個(gè)文件鹃唯，這個(gè)文件存儲(chǔ)了實(shí)際消息的索引信息。并且即使文件被刪除瓣喊，也能通過實(shí)際純粹的消息文件（commit log）恢復(fù)回來坡慌。
• Offset
  RocketMQ中，有很多offset的概念藻三。但通常我們只關(guān)心暴露到客戶端的offset洪橘。一般我們不特指的話，就是指邏輯Message Queue下面的offset棵帽。
  可以認(rèn)為一條邏輯的message queue是無限長的數(shù)組熄求。一條消息進(jìn)來下標(biāo)就會(huì)漲1。下標(biāo)就是offset逗概。
  一條message queue中的max offset表示消息的最大offset弟晚。注：這里從源碼上看，max_offset并不是最新的那條消息的offset逾苫，而是表示最新消息的offset+1卿城。
  而min offset則標(biāo)識(shí)現(xiàn)存在的最小offset。
  由于消息存儲(chǔ)一段時(shí)間后铅搓，消費(fèi)會(huì)被物理地從磁盤刪除瑟押，message queue的min offset也就對(duì)應(yīng)增長。這意味著比min offset要小的那些消息已經(jīng)不在broker上了星掰，無法被消費(fèi)多望。
• Consumer Offset
  用于標(biāo)記Consumer Group在一條邏輯Message Queue上嫩舟，消息消費(fèi)到哪里了。
  消費(fèi)者拉取消息的時(shí)候需要指定offset怀偷，broker不主動(dòng)推送消息至壤，而是接受到請(qǐng)求的時(shí)候把存儲(chǔ)的對(duì)應(yīng)offset的消息返回給客戶端。這個(gè)offset在成功消費(fèi)后會(huì)更新到內(nèi)存枢纠，并定時(shí)持久化像街。在集群消費(fèi)模式下，會(huì)同步持久化到broker晋渺。在廣播模式下镰绎，會(huì)持久化到本地文件。
  實(shí)例重啟的時(shí)候會(huì)獲取持久化的consumer offset木西，用以決定從哪里開始消費(fèi)畴栖。
• 集群消費(fèi)
  消費(fèi)者的一種消費(fèi)模式。一個(gè)Consumer Group中的各個(gè)Consumer實(shí)例分?jǐn)側(cè)ハM(fèi)消息八千，即一條消息只會(huì)投遞到一個(gè)Consumer Group下面的一個(gè)實(shí)例吗讶。
  實(shí)際上，每個(gè)Consumer是平均分?jǐn)侻essage Queue的去做拉取消費(fèi)恋捆。例如某個(gè)Topic有3條Q照皆，其中一個(gè)Consumer Group 有 3 個(gè)實(shí)例（可能是 3 個(gè)進(jìn)程，或者 3 臺(tái)機(jī)器）沸停，那么每個(gè)實(shí)例只消費(fèi)其中的1條Q膜毁。
  而由Producer發(fā)送消息的時(shí)候是輪詢所有的Q,所以消息會(huì)平均散落在不同的Q上，可以認(rèn)為Q上的消息是平均的愤钾。那么實(shí)例也就平均地消費(fèi)消息了瘟滨。
  這種模式下，消費(fèi)進(jìn)度的存儲(chǔ)會(huì)持久化到Broker能颁。
• 廣播消費(fèi)
  消費(fèi)者的一種消費(fèi)模式杂瘸。消息將對(duì)一個(gè)Consumer Group下的各個(gè)Consumer實(shí)例都投遞一遍。即即使這些 Consumer 屬于同一個(gè)Consumer Group伙菊，消息也會(huì)被Consumer Group 中的每個(gè)Consumer都消費(fèi)一次败玉。
  實(shí)際上，是一個(gè)消費(fèi)組下的每個(gè)消費(fèi)者實(shí)例都獲取到了topic下面的每個(gè)Message Queue去拉取消費(fèi)占业。所以消息會(huì)投遞到每個(gè)消費(fèi)者實(shí)例绒怨。
  這種模式下纯赎，消費(fèi)進(jìn)度會(huì)存儲(chǔ)持久化到實(shí)例本地谦疾。
• 順序消息
  消費(fèi)消息的順序要同發(fā)送消息的順序一致。由于Consumer消費(fèi)消息的時(shí)候是針對(duì)Message Queue順序拉取并開始消費(fèi)犬金，且一條Message Queue只會(huì)給一個(gè)消費(fèi)者（集群模式下）念恍，所以能夠保證同一個(gè)消費(fèi)者實(shí)例對(duì)于Q上消息的消費(fèi)是順序地開始消費(fèi)（不一定順序消費(fèi)完成六剥，因?yàn)橄M(fèi)可能并行）。

在RocketMQ中峰伙，順序消費(fèi)主要指的是都是Queue級(jí)別的局部順序疗疟。這一類消息為滿足順序性，必須Producer單線程順序發(fā)送瞳氓，且發(fā)送到同一個(gè)隊(duì)列策彤，這樣Consumer就可以按照Producer發(fā)送的順序去消費(fèi)消息。

生產(chǎn)者發(fā)送的時(shí)候可以用MessageQueueSelector為某一批消息（通常是有相同的唯一標(biāo)示id）選擇同一個(gè)Queue匣摘，則這一批消息的消費(fèi)將是順序消息（并由同一個(gè)consumer完成消息）店诗。或者M(jìn)essage Queue的數(shù)量只有1音榜，但這樣消費(fèi)的實(shí)例只能有一個(gè)庞瘸，多出來的實(shí)例都會(huì)空跑。

• 普通順序消息
  順序消息的一種赠叼，正常情況下可以保證完全的順序消息擦囊，但是一旦發(fā)生異常，Broker宕機(jī)或重啟嘴办，由于隊(duì)列總數(shù)發(fā)生發(fā)化瞬场，消費(fèi)者會(huì)觸發(fā)負(fù)載均衡，而默認(rèn)地負(fù)載均衡算法采取哈希取模平均涧郊，這樣負(fù)載均衡分配到定位的隊(duì)列會(huì)發(fā)化泌类，使得隊(duì)列可能分配到別的實(shí)例上，則會(huì)短暫地出現(xiàn)消息順序不一致底燎。

如果業(yè)務(wù)能容忍在集群異常情況（如某個(gè) Broker 宕機(jī)或者重啟）下刃榨，消息短暫的亂序，使用普通順序方式比較合適双仍。

• 嚴(yán)格順序消息
  順序消息的一種枢希，無論正常異常情況都能保證順序，但是犧牲了分布式 Failover 特性朱沃，即 Broker集群中只要有一臺(tái)機(jī)器不可用苞轿，則整個(gè)集群都不可用，服務(wù)可用性大大降低逗物。

如果服務(wù)器部署為同步雙寫模式搬卒，此缺陷可通過備機(jī)自動(dòng)切換為主避免，不過仍然會(huì)存在幾分鐘的服務(wù)不可用翎卓。（依賴同步雙寫契邀，主備自動(dòng)切換，自動(dòng)切換功能目前并未實(shí)現(xiàn)）

3. 水平擴(kuò)展及負(fù)載均衡詳解

Broker端水平擴(kuò)展

Broker負(fù)載均衡

Broker是以group為單位提供服務(wù)失暴。一個(gè)group里面分master和slave,master和slave存儲(chǔ)的數(shù)據(jù)一樣坯门，slave從master同步數(shù)據(jù)（同步雙寫或異步復(fù)制看配置）微饥。
過nameserver暴露給客戶端后，只是客戶端關(guān)心（注冊(cè)或發(fā)送）一個(gè)個(gè)的topic路由信息古戴。路由信息中會(huì)細(xì)化為message queue的路由信息欠橘。而message queue會(huì)分布在不同的broker group。所以對(duì)于客戶端來說现恼，分布在不同broker group的message queue為成為一個(gè)服務(wù)集群肃续，但客戶端會(huì)把請(qǐng)求分?jǐn)偟讲煌膓ueue。

而由于壓力分?jǐn)偟搅瞬煌膓ueue,不同的queue實(shí)際上分布在不同的Broker group叉袍，也就是說壓力會(huì)分?jǐn)偟讲煌腷roker進(jìn)程痹升，這樣消息的存儲(chǔ)和轉(zhuǎn)發(fā)均起到了負(fù)載均衡的作用。

Broker一旦需要橫向擴(kuò)展畦韭，只需要增加broker group疼蛾，然后把對(duì)應(yīng)的topic建上，客戶端的message queue集合即會(huì)變大艺配，這樣對(duì)于broker的負(fù)載則由更多的broker group來進(jìn)行分擔(dān)察郁。

并且由于每個(gè)group下面的topic的配置都是獨(dú)立的，也就說可以讓group1下面的那個(gè)topic的queue數(shù)量是4转唉，其他group下的topic queue數(shù)量是2皮钠，這樣group1則得到更大的負(fù)載。

commit log

雖然每個(gè)topic下面有很多message queue赠法，但是message queue本身并不存儲(chǔ)消息麦轰。真正的消息存儲(chǔ)會(huì)寫在CommitLog的文件，message queue只是存儲(chǔ)CommitLog中對(duì)應(yīng)的位置信息砖织，方便通過message queue找到對(duì)應(yīng)存儲(chǔ)在CommitLog的消息款侵。

不同的topic，message queue都是寫到相同的CommitLog 文件侧纯，也就是說CommitLog完全的順序?qū)憽?/p>

具體如下圖：

image.png

Producer

Producer端新锈，每個(gè)實(shí)例在發(fā)消息的時(shí)候，默認(rèn)會(huì)輪詢所有的message queue發(fā)送眶熬，以達(dá)到讓消息平均落在不同的queue上妹笆。而由于queue可以散落在不同的broker，所以消息就發(fā)送到不同的broker下娜氏，如下圖：

image.png

Consumer負(fù)載均衡

集群模式

在集群消費(fèi)模式下拳缠，每條消息只需要投遞到訂閱這個(gè)topic的Consumer Group下的一個(gè)實(shí)例即可。RocketMQ采用主動(dòng)拉取的方式拉取并消費(fèi)消息贸弥，在拉取的時(shí)候需要明確指定拉取哪一條message queue窟坐。
而每當(dāng)實(shí)例的數(shù)量有變更，都會(huì)觸發(fā)一次所有實(shí)例的負(fù)載均衡，這時(shí)候會(huì)按照queue的數(shù)量和實(shí)例的數(shù)量平均分配queue給每個(gè)實(shí)例狸涌。
默認(rèn)的分配算法是AllocateMessageQueueAveragely，如下圖：

image.png

還有另外一種平均的算法是AllocateMessageQueueAveragelyByCircle最岗，也是平均分?jǐn)偯恳粭lqueue帕胆，只是以環(huán)狀輪流分queue的形式，如下圖：

image.png

通過增加consumer實(shí)例去分?jǐn)俼ueue的消費(fèi)，可以起到水平擴(kuò)展的消費(fèi)能力的作用薇正。而有實(shí)例下線的時(shí)候片酝，會(huì)重新觸發(fā)負(fù)載均衡，這時(shí)候原來分配到的queue將分配到其他實(shí)例上繼續(xù)消費(fèi)挖腰。

但是如果consumer實(shí)例的數(shù)量比message queue的總數(shù)量還多的話雕沿，多出來的consumer實(shí)例將無法分到queue，也就無法消費(fèi)到消息猴仑，也就無法起到分?jǐn)傌?fù)載的作用了审轮。所以需要控制讓queue的總數(shù)量大于等于consumer的數(shù)量。

廣播模式

由于廣播模式下要求一條消息需要投遞到一個(gè)消費(fèi)組下面所有的消費(fèi)者實(shí)例辽俗，所以也就沒有消息被分?jǐn)傁M(fèi)的說法疾渣。

在實(shí)現(xiàn)上，其中一個(gè)不同就是在consumer分配queue的時(shí)候崖飘，會(huì)所有consumer都分到所有的queue稳衬。

image.png

4.消息ACK機(jī)制及消費(fèi)進(jìn)度管理

https://zhuanlan.zhihu.com/p/25140744 中剖析過，consumer的每個(gè)實(shí)例是靠隊(duì)列分配來決定如何消費(fèi)消息的坐漏。那么消費(fèi)進(jìn)度具體是如何管理的薄疚，又是如何保證消息成功消費(fèi)的（RocketMQ有保證消息肯定消費(fèi)成功的特性（失敗則重試）？
本文將詳細(xì)解析消息具體是如何ack的赊琳，又是如何保證消費(fèi)肯定成功的街夭。