RocketMQ的前身是Metaq
- 能夠保證嚴格的消息順序
- 提供豐富的消息拉取模式
- 高效的訂閱者水平擴展能力
- 實時的消息訂閱機制
- 支持事務消息
- 億級消息堆積能力
1單節點rocketMQ安裝
1.1 在hosts文件中配置地址與IP映射關係
[root@localhost rocketmq4.4.0]# vim /etc/hosts
192.168.100.100 rocketmq-nameserver1
192.168.100.100 rocketmq-master1
1.2 將解壓文件放到 /opt 目錄下
[root@localhost opt]# pwd
/opt
[root@localhost opt]# unzip rocketmq-all-4.4.0-bin-release.zip
[root@localhost opt]# mv rocketmq-all-4.4.0-bin-release rocketmq4.4.0
創建rocketMQ存儲文件的目錄：
logs：存儲rocketMQ日誌的目錄
store：存儲rocketMQ數據文件的目錄
commitlog：存儲rocketMQ消息信息
consumequeue、index：存儲消息的索引數據
[root@localhost rocketmq4.4.0]# mkdir logs
[root@localhost rocketmq4.4.0]# mkdir store
[root@localhost rocketmq4.4.0]# cd store/
[root@localhost store]# mkdir commitlog consumequeue index
conf目錄配置文件說明
2m-2s-async ：2主2從異步
2m-2s-sync ：2主2從同步
2m-noslave ：2主無從
先配置單節點，修改2m-2s-async的配置實現：
#所屬集羣名字
brokerClusterName=rocketmq-cluster
#broker名字，注意此處不同的配置文件填寫的不一樣
brokerName=broker-a
#0 表示 Master，>0 表示 Slave
brokerId=0
#nameServer地址，分號分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876
#在發送消息時，自動創建服務器不存在的topic，默認創建的隊列數
defaultTopicQueueNums=4
#是否允許 Broker 自動創建Topic，建議線下開啓，線上關閉
autoCreateTopicEnable=true
#是否允許 Broker 自動創建訂閱組，建議線下開啓，線上關閉
autoCreateSubscriptionGroup=true
#Broker 對外服務的監聽端口
listenPort=10911
#刪除文件時間點，默認凌晨 4點
deleteWhen=04
#文件保留時間，默認 48 小時
fileReservedTime=120
#commitLog每個文件的大小默認1G
mapedFileSizeCommitLog=1073741824
#ConsumeQueue每個文件默認存30W條，根據業務情況調整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#檢測物理文件磁盤空間
diskMaxUsedSpaceRatio=88
#存儲路徑
storePathRootDir=/usr/local/rocketmq/store
#commitLog 存儲路徑
storePathCommitLog=/usr/local/rocketmq/store/commitlog
#消費隊列存儲路徑存儲路徑
storePathConsumeQueue=/usr/local/rocketmq/store/consumequeue
#消息索引存儲路徑
storePathIndex=/usr/local/rocketmq/store/index
#checkpoint 文件存儲路徑
storeCheckpoint=/usr/local/rocketmq/store/checkpoint
#abort 文件存儲路徑
abortFile=/usr/local/rocketmq/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 異步複製Master
#- SYNC_MASTER 同步雙寫Master
#- SLAVE
brokerRole=SYNC_MASTER
#刷盤方式
#- ASYNC_FLUSH 異步刷盤
#- SYNC_FLUSH 同步刷盤
flushDiskType=SYNC_FLUSH
#checkTransactionMessageEnable=false
#發消息線程池數量
#sendMessageThreadPoolNums=128
#拉消息線程池數量
#pullMessageThreadPoolNums=128
RocketMQ默認使用3個端口：9876 、10911 、11011 。如果防火牆沒有關閉的話，那麼防火牆就必須開放這些端口：
nameserver默認使用 9876 端口master默認使用 10911 端口slave默認使用11011 端口
刷盤機制
RocketMQ的消息是存儲到磁盤上的，這樣既能保證斷電後恢復， 又可以讓存儲的消息量超出內存的限制。RocketMQ爲了提高性能，會盡可能地保證磁盤的順序寫。消息在通過Producer寫入RocketMQ的時 候，有兩種寫磁盤方式，分佈式同步刷盤和異步刷盤。
1）同步刷盤
在返回寫成功狀態時，消息已經被寫入磁盤。具體流程是，消息寫入內存的PAGECACHE後，立刻通知刷盤線程刷盤， 然後等待刷盤完成，刷盤線程執行完成後喚醒等待的線程，返回消息寫 成功的狀態。
2）異步刷盤
在返回寫成功狀態時，消息可能只是被寫入了內存的PAGECACHE，寫操作的返回快，吞吐量大；當內存裏的消息量積累到一定程度時，統一觸發寫磁盤動作，快速寫入。
3）配置
同步刷盤還是異步刷盤，都是通過Broker配置文件裏的flushDiskType 參數設置的，這個參數被配置成SYNC_FLUSH、ASYNC_FLUSH中的 一個。
集羣工作流程
- 啓動NameServer，NameServer起來後監聽端口，等待Broker、Producer、Consumer連上來，相當於一個路由控制中心。
- Broker啓動，跟所有的NameServer保持長連接，定時發送心跳包。心跳包中包含當前Broker信息(IP+端口等)以及存儲所有Topic信息。註冊成功後，NameServer集羣中就有Topic跟Broker的映射關係。
- 收發消息前，先創建Topic，創建Topic時需要指定該Topic要存儲在哪些Broker上，也可以在發送消息時自動創建Topic。
- Producer發送消息，啓動時先跟NameServer集羣中的其中一臺建立長連接，並從NameServer中獲取當前發送的Topic存在哪些Broker上，輪詢從隊列列表中選擇一個隊列，然後與隊列所在的Broker建立長連接從而向Broker發消息。
- Consumer跟Producer類似，跟其中一臺NameServer建立長連接，獲取當前訂閱Topic存在哪些Broker上，然後直接跟Broker建立連接通道，開始消費消息。
1）單Master模式
這種方式風險較大，一旦Broker重啓或者宕機時，會導致整個服務不可用。不建議線上環境使用,可以用於本地測試。
2）多Master模式
一個集羣無Slave，全是Master，如2個Master或者3個Master，這種模式的優缺點如下：
- 優點：配置簡單，單個Master宕機或重啓維護對應用無影響，在磁盤配置爲RAID10時，即使機器宕機不可恢復情況下，由於RAID10磁盤非常可靠，消息也不會丟（異步刷盤丟失少量消息，同步刷盤一條不丟），性能最高；
- 缺點：單臺機器宕機期間，這臺機器上未被消費的消息在機器恢復之前不可訂閱，消息實時性會受到影響。
3）多Master多Slave模式（異步）
每個Master配置一個Slave，有多對Master-Slave，HA採用異步複製方式，主備有短暫消息延遲（毫秒級），這種模式的優缺點如下：
- 優點：即使磁盤損壞，消息丟失的非常少，且消息實時性不會受影響，同時Master宕機後，消費者仍然可以從Slave消費，而且此過程對應用透明，不需要人工干預，性能同多Master模式幾乎一樣；
- 缺點：Master宕機，磁盤損壞情況下會丟失少量消息。
4）多Master多Slave模式（同步）
每個Master配置一個Slave，有多對Master-Slave，HA採用同步雙寫方式，即只有主備都寫成功，才嚮應用返回成功，這種模式的優缺點如下：
- 優點：數據與服務都無單點故障，Master宕機情況下，消息無延遲，服務可用性與數據可用性都非常高；
- 缺點：性能比異步複製模式略低（大約低10%左右），發送單個消息的RT會略高，且目前版本在主節點宕機後，備機不能自動切換爲主機。