RocketMQ的安裝與啟動
一、基本概念
1 、消息（Message）
消息是指，消息系統所傳輸資訊的實體載體，生産和消費資料的最小機關，每條消息必須屬于一個主題。
2、 主題（Topic）
Topic表示一類消息的集合
，每個主題包含若幹條消息，每條消息隻能屬于一個主題，是RocketMQ進行消息訂閱的基本機關。 topic:message 1:n message:topic 1:1
一個生産者可以同時發送多種Topic的消息；而一個消費者隻對某種特定的Topic感興趣，即隻可以訂閱和消費一種Topic的消息。 producer:topic 1:n consumer:topic 1:1
3、标簽（Tag）
為消息設定的标簽，用于同一主題下區分不同類型的消息。來自同一業務單元的消息，可以根據不同業務目的在同一主題下設定不同标簽。标簽能夠有效地保持代碼的清晰度和連貫性，并優化RocketMQ提供的查詢系統。消費者可以根據Tag實作對不同子主題的不同消費邏輯，實作更好的擴充性。Topic是消息的一級分類，Tag是消息的二級分類。
Topic：貨物
tag=上海
tag=江蘇
tag=浙江
------- 消費者 -----
topic=貨物 tag = 上海
topic=貨物 tag = 上海|浙江
topic=貨物 tag = *
4、隊列（Queue）
存儲消息的實體實體。一個Topic中可以包含多個Queue，每個Queue中存放的就是該Topic的消息。一個Topic的Queue也被稱為一個Topic中消息的分區（Partition）。
分區=queue
一個Topic的Queue中的消息隻能被一個消費者組中的一個消費者消費。
一個Queue中的消息不允許同一個消費者組中的多個消費者同時消費。
在學習參考其它相關資料時，還會看到一個概念：
分片
（Sharding）。分片不同于分區。在RocketMQ中，分片指的是存放相應Topic的Broker。每個分片中會建立出相應數量的分區，即Queue，每個Queue的大小都相同的。
5、消息辨別（MessageId/Key）
有可能重複
RocketMQ中每個消息擁有唯一的MessageId，且可以攜帶具有業務辨別的Key，以友善對消息的查詢。
不過需要注意的是，MessageId有兩個：在生産者send()消息時會自動生成一個MessageId（msgId)，當消息到達Broker後，Broker也會自動生成一個MessageId(offsetMsgId)。msgId、offsetMsgId與key都稱為消息辨別。
- msgId：由producer端生成，其
生成規則
-
producerIp + 程序pid + MessageClientIDSetter類的ClassLoader的hashCode +目前時間 + AutomicInteger自增計數器
-
- offsetMsgId：由broker端生成，其生成規則為：
brokerIp + 實體分區的offset（Queue中的偏移量）
- key：由使用者指定的業務相關的唯一辨別
二、系統架構
RocketMQ架構上主要分為四部分構成：
1、Producer
消息生産者，負責生産消息。Producer通過MQ的負載均衡子產品選擇相應的Broker叢集隊列進行消息投遞，投遞的過程支援快速失敗并且低延遲。
例如，業務系統産生的日志寫入到MQ的過程，就是消息生産的過程
再如，電商平台中使用者送出的秒殺請求寫入到MQ的過程，就是消息生産的過程
RocketMQ中的消息生産者都是
以生産者組（Producer Group）的形式
出現的。生産者組是同一類生産者的集合，這類Producer發送相同Topic類型的消息。一個生産者組可以同時發送
多個主題
的消息。
2、Consumer
消息消費者，負責消費消息。一個消息消費者會從Broker伺服器中擷取到消息，并對消息進行相關業務處理。
例如，QoS系統從MQ中讀取日志，并對日志進行解析處理的過程就是消息消費的過程。
再如，電商平台的業務系統從MQ中讀取到秒殺請求，并對請求進行處理的過程就是消息消費的過程。
RocketMQ中的消息消費者都是以消費者組（Consumer Group）的形式出現的。消費者組是同一類消費者的集合，這類
Consumer消費的是同一個Topic類型的消息
。消費者組使得在消息消費方面，實作
負載均衡
（将一個Topic中的不同的Queue平均配置設定給同一個Consumer Group的不同的Consumer，注意，他是對queue的負載均衡，不是将消息負載均衡）和
容錯
（一個Consmer挂了，該Consumer Group中的其它Consumer可以接着消費原Consumer消費的Queue）的目标變得非常容易。
一個消費者可以消費多個queue，一個queue隻能被一個消費者消費
消費者組中Consumer的數量應該小于等于訂閱Topic的Queue數量。如果超出Queue數量，則多出的Consumer将不能消費消息。
不過，一個Topic類型的消息可以被多個消費者組同時消費。
注意:
1）消費者組隻能消費一個Topic的消息，不能同時消費多個Topic消息
2）一個消費者組中的消費者必須訂閱完全相同的Topic
3、 Name Server
-
功能介紹
NameServer是一個Broker與Topic路由的注冊中心，支援Broker的動态注冊與發現。RocketMQ的思想來自于Kafka，而Kafka是依賴了Zookeeper的。
是以，在RocketMQ的早期版本，即在MetaQ v1.0與v2.0版本中，也是依賴于Zookeeper的。
從MetaQ v3.0，即RocketMQ開始去掉了Zookeeper依賴，使用了自己的NameServer。
主要包括兩個功能：
- Broker管理：
-
接受Broker叢集的注冊資訊并且儲存下來作為路由資訊的基本資料；提供心跳檢測
機制，檢查Broker是否還存活。
-
- 路由資訊管理：
-
每個NameServer中都儲存着Broker叢集的整個路由資訊和用于用戶端查詢的隊列
資訊。Producer和Conumser通過NameServer可以擷取整個Broker叢集的路由資訊，進而進行消息的投遞和消費。
-
-
路由注冊
NameServer通常也是以叢集的方式部署，不過，NameServer是無狀态的，即NameServer叢集中的各
個節點間是無差異的，各節點間互相不進行資訊通訊。那各節點中的資料是如何進行資料同步的呢？
在Broker節點啟動時，輪詢NameServer清單，與每個NameServer節點建立長連接配接，發起注冊請求。在
NameServer内部維護着⼀個Broker清單，用來動态存儲Broker的資訊。NameServer叢集之間沒有資料通訊
注意，這是與其它像zk、Eureka、Nacos等注冊中心不同的地方。
這種NameServer的無狀态方式，有什麼優缺點：
優點：NameServer叢集
，搭建簡單
擴容簡單
。
缺點：對于Broker，
。否則未指出的将不會去注冊。也正因為如此，NameServer并不能随便擴容。因為，若Broker不重新配置，新增的NameServer對于Broker來說是不可見的，其不會向這個NameServer進行注冊。必須明确指出所有NameServer位址
Broker節點為了證明自己是活着的，為了維護與NameServer間的
長連接配接
，會将最新的資訊以心跳包的方式上報給NameServer，每30秒發送一次心跳。心跳包中包含 BrokerId、Broker位址(IP+Port)、Broker名稱、Broker所屬叢集名稱等等 。NameServer在接收到心跳包後，會更新心跳時間戳，記錄這個Broker的最新存活時間。
NameServer,10s掃描一次Broker表；
Broker,30s發送一次心跳
Broker,120s沒收到一個Broker心跳就直接幹掉這個Broker
-
路由剔除
由于Broker關機、當機或網絡抖動等原因，NameServer沒有收到Broker的心跳，NameServer可能會将其從Broker清單中剔除。NameServer中有⼀個定時任務，每隔10秒就會掃描⼀次Broker表，檢視每一個Broker的最新心跳時間戳距離目前時間是否超過120秒，如果超過，則會判定Broker失效，然後将其從Broker清單中剔除。
擴充：
對于RocketMQ日常運維工作，例如Broker更新，需要停掉Broker的工作。OP需要怎麼做？
OP需要将Broker的讀寫權限禁掉。一旦client(Consumer或Producer)向broker發送請求，都會收到broker的NO_PERMISSION響應，然後client會進行對其它Broker的重試。當OP觀察到這個Broker沒有流量後，再關閉它，實作Broker從NameServer的移除。
OP：運維工程師
SRE: Site Reliability Engineer，現場可靠性工程師
- 路由發現
RocketMQ的路由發現采用的是Pull模型
擴充：
1）Push模型：
推送模型。其實時性較好，是一個“釋出-訂閱”模型，需要
。而長連接配接的維護是維護一個長連接配接
需要資源成本
。該模型适合于的場景：實時性要求較高Client數量不多，Server資料變化較頻繁
2）Pull模型：
拉取模型。存在的問題是，
實時性較差
。
3）Long Polling模型：
長輪詢模型。其是對Push與Pull模型的整合，充分利用了這兩種模型的優勢，屏蔽了它們的劣勢。（用戶端請求服務端消息，如果沒有，儲存30s的長連接配接，期間有消息就傳回；30s後就關閉長連接配接，不斷重複該過程）
- 用戶端NameServer選擇政策
這裡的用戶端指的是Producer與Consumer
用戶端在配置時必須要寫上NameServer叢集的位址，那麼用戶端到底連接配接的是哪個NameServer節點呢？
用戶端首先會生産一個随機數，然後再與NameServer節點數量取模，此時得到的就是所要連接配接的節點索引，然後就會進行連接配接。（随機擷取，建立連接配接）
如果連接配接失敗，則會采用round-robin政策，逐個嘗試着去連接配接其它節點。
首先采用的是
随機政策
進行的選擇，失敗後采用的是
輪詢政策
。
擴充：Zookeeper Client是如何選擇Zookeeper Server的？
簡單來說就是，經過兩次shuffle（打散zkserver清單），然後選擇第一台Zookeeper Server。
詳細說就是，将配置檔案中的zk server位址進行第一次shuffle，然後随機選擇一個。這個選擇出的一般都是一個hostname。然後擷取到該hostname對應的所有ip，再對這些ip進行第二次shuffle，從shuffle過的結果中取第一個server位址進行連接配接。
4、Broker
-
功能介紹
Broker充當着 消息中轉角色，負責存儲消息、轉發消息。Broker在RocketMQ系統中負責接收并存儲從生産者發送來的消息，同時為消費者的拉取請求作準備。Broker同時也存儲着消息相關的中繼資料，包括消費者組消費進度偏移offset、主題、隊列等。
Kafka 0.8版本之後，offset是存放在Broker中的，之前版本是存放在Zookeeper中的。
-
子產品構成
下圖為Broker Server的功能子產品示意圖。
Remoting Module：整個Broker的實體，負責處理來自clients端的請求。而這個Broker實體則由以下子產品構成。
Client Manager：用戶端管理器。負責接收、解析用戶端(Producer/Consumer)請求，管理用戶端。例如，維護Consumer的Topic訂閱資訊
Store Service：存儲服務。提供友善簡單的API接口，處理
消息存儲到實體硬碟和消息查詢
功能。
HA Service：高可用服務，提供Master Broker 和 Slave Broker之間的資料同步功能。
Index Service：索引服務。根據特定的Message key，對投遞到Broker的消息進行索引服務，同時也提供根據Message Key對消息進行快速查詢的功能。
- 叢集部署
為了增強Broker性能與吞吐量，Broker一般都是以叢集形式出現的。各叢集節點中可能存放着相同Topic的不同Queue。不過，這裡有個問題，如果某Broker節點當機，如何保證資料不丢失呢？其解決方案是，将每個Broker叢集節點進行橫向擴充，即将Broker節點再建為一個HA叢集，解決單點問題。
Broker節點叢集是一個主從叢集，即叢集中具有Master與Slave兩種角色。
Master負責處理讀寫操作請求，Slave負責對Master中的資料進行備份
(平常操作都是操作Master)。當Master挂掉了，Slave則會自動切換為Master去工作。是以這個Broker叢集是
主備叢集
。一個Master可以包含多個Slave，但一個Slave隻能隸屬于一個Master。Master與Slave 的對應關系是通過指定相同的BrokerName、不同的BrokerId 來确定的。BrokerId為0表示Master，非0表示Slave。每個Broker與NameServer叢集中的所有節點建立長連接配接，定時注冊Topic資訊到所有NameServer。
5、工作流程
-
具體流程
1）啟動NameServer，NameServer啟動後開始監聽端口，等待Broker、Producer、Consumer連接配接。
2）啟動Broker時，Broker會與所有的NameServer建立并保持長連接配接，然後每30秒向NameServer定時發送心跳包。(注冊)
3）發送消息前，可以先建立Topic，建立Topic時需要指定該Topic要存儲在哪些Broker上，當然，在建立Topic時也會将Topic與Broker的關系寫入到NameServer中。不過，這步是可選的，也可以在發送消息時自動建立Topic。
4）Producer發送消息，啟動時先跟NameServer叢集中的其中一台建立長連接配接，并從NameServer中擷取路由資訊，即目前發送的Topic消息的Queue與Broker的位址（IP+Port）的映射關系。然後根據算法政策從隊選擇一個Queue，與隊列所在的Broker建立長連接配接進而向Broker發消息。當然，在擷取到路由資訊後，Producer會首先将路由資訊緩存到本地，再每30秒從NameServer更新一次路由資訊。
5）Consumer跟Producer類似，跟其中一台NameServer建立長連接配接，擷取其所訂閱Topic的路由資訊，然後根據算法政策從路由資訊中擷取到其所要消費的Queue，然後直接跟Broker建立長連接配接，開始消費其中的消息。Consumer在擷取到路由資訊後，同樣也會每30秒從NameServer更新一次路由資訊。不過不同于Producer的是，Consumer還會向Broker發送心跳，以確定Broker的存活狀态。
-
Topic的建立模式
手動建立Topic時，有兩種模式：
-
叢集模式
(全局定義)
-
Broker模式
預設采用的是Broker模式
-
- 讀/寫隊列
從實體上來講，讀/寫隊列是同一個隊列
一般情況下，讀/寫隊列數量是相同的
例如，建立Topic時設定的寫隊列數量為8，讀隊列數量為4，此時系統會建立8個Queue，分别是0 1 2 3 4 5 6 7。Producer會将消息寫入到這8個隊列，但Consumer隻會消費0 1 2 3這4個隊列中的消息，4 5 6 7中的消息是不會被消費到的。
再如，建立Topic時設定的寫隊列數量為4，讀隊列數量為8，此時系統會建立8個Queue，分别是0 1 2 3 4 5 6 7。Producer會将消息寫入到0 1 2 3 這4個隊列，但Consumer隻會消費0 1 2 3 4 5 6 7這8個隊列中的消息，但是4 5 6 7中是沒有消息的。此時假設Consumer Group中包含兩個Consumer，Consumer1消費0 1 2 3，而Consumer2消費4 5 6 7。但實際情況是，Consumer2是沒有消息可消費的。也就是說，當讀/寫隊列數量設定不同時，總是有問題的。
那麼，為什麼要這樣設計呢？其這樣設計的目的是為了，
友善Topic的Queue的縮容
。
例如，原來建立的Topic中包含16個Queue，如何能夠使其Queue縮容為8個，還不會丢失消息？可以動态修改寫隊列數量為8，讀隊列數量不變。此時新的消息隻能寫入到前8個隊列，而消費都消費的卻是16個隊列中的資料。當發現後8個Queue中的消息消費完畢後，就可以再将讀隊列數量動态設定為8。整個縮容過程，沒有丢失任何消息。
縮容過程：先設定小寫queue，16到8，那就隻寫入0-7；此時消費者消費之前的0-15，當後面8個的queue沒有消息了，就關閉掉，再将讀queue從16設定為8，就完成了縮容
perm用于設定對目前建立Topic的操作權限：2表示隻寫，4表示隻讀，6表示讀寫。
三、單機安裝與啟動
1、準備工作
-
軟硬體需求
系統要求是64位的，JDK要求是1.8及其以上版本的。
Day363&364&365.RocketMQ的安裝&啟動 -RocketMQRocketMQ的安裝與啟動
- 下載下傳RocketMQ安裝包
将下載下傳的安裝包上傳到Linux
2、修改初始記憶體
設定測試jvm堆空間記憶體
vim runserver.sh
vim runbroker.sh
# 設定測試環境jvm堆空間記憶體
3、啟動
- 啟動NameServer
nohuop sh bin/mqnamesrv & #背景運作 nameserver
tail -f ~/logs/rocketmqlogs/namesrv.log #監聽nameserver日志檔案
- 啟動broker
nohup sh mqbroker -n localhost:9876 &
tail -f ~/logs/rocketmqlogs/broker.log
4、發送/接收消息測試
- 發送消息
export NAMESRV_ADDR=localhost:9876 #設定環境變量
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
- 接收消息
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
5、關閉Server
無論是關閉name server還是broker，都是使用
bin/mqshutdown
指令。
[[email protected] rocketmq4.9.0]# sh bin/mqshutdown broker
The mqbroker(1298) is running...
Send shutdown request to mqbroker(1298) OK
[[email protected] rocketmq4.9.0]# sh bin/mqshutdown namesrv
The mqnamesrv(1258) is running...
Send shutdown request to mqnamesrv(1258) OK
[1]+ 退出 143 nohup sh mqbroker -n localhost:9876(工作目錄：/opt/module/rocketmq/rocketmq4.9.0/bin)
(目前工作目錄：/opt/module/rocketmq/rocketmq4.9.0)
四、 控制台的安裝與啟動
RocketMQ有一個可視化的dashboard，通過該控制台可以直覺的檢視到很多資料
1、下載下傳
下載下傳位址：https://github.com/apache/rocketmq-externals/releases
2、修改配置
修改其src/main/resources中的application.properties配置檔案。
- 原來的端口号為8080，修改為一個不常用的
- 指定RocketMQ的name server位址
3、添加依賴
在解壓目錄rocketmq-console的pom.xml中添加如下JAXB依賴。
JAXB
，Java Architechture for Xml Binding，用于XML綁定的Java技術，是一個業界标準，是一
項可以根據XML Schema生成Java類的技術。
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-core</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
4、打包
在rocketmq-console目錄下運作
maven
的打包指令。
保證自己電腦裡面運作環境裝有maven
mvn clean package -Dmaven.test.skip=true
他會在
rocketmq-console/target/
下生成編譯後的jar檔案
5、啟動
java -jar rocketmq-console-ng-1.0.0-sources.jar
6、通路
通路我們在上面配置檔案制定的位址：
localhost:3636
五、叢集搭建理論
針對broker叢集
1、資料複制與刷盤政策
刷盤：記憶體到磁盤
-
複制政策
複制政策是Broker的Master與Slave間的資料同步方式。分為同步複制與異步複制：
-
同步複制
-
異步複制
異步複制政策會降低系統的寫入延遲，RT變小，提高了系統的吞吐量
-
-
刷盤政策
刷盤政策指的是broker中消息的
落盤方式
消息發送到broker記憶體後消息持久化到磁盤的方式
-
同步刷盤
磁盤後
-
異步刷盤
記憶體後
1）異步刷盤政策會降低系統的寫入延遲，RT變小，提高了系統的吞吐量
2）消息寫入到Broker的記憶體，一般是寫入到了PageCache
3）對于異步 刷盤政策，消息會寫入到PageCache後立即傳回成功ACK。但并不會立即做落盤操作，而是當PageCache到達一定量時會自動進行落盤。
-
2、Broker叢集模式
根據Broker叢集中各個節點間關系的不同，Broker叢集可以分為以下幾類：
-
單Master
隻有一個broker（其本質上就不能稱為叢集）。這種方式也隻能是在測試時使用，生産環境下不能使用，因為存在單點問題。
-
多Master
broker叢集僅由多個master構成，不存在Slave。同一Topic的各個Queue會平均分布在各個master節點上。
-
優點
磁盤配置為RAID10
時，即使機器
當機不可恢複情況下，由于RAID10磁盤非常可靠，消息也不會丢（異步刷盤丢失少量消息，同步
刷盤一條不丢），性能最高；
-
缺點
以上優點的前提是，這些Master都配置了RAID磁盤陣列。如果沒有配置，一旦出現某Master當機，則會發生大量消息丢失的情況。
-
- 多Master多Slave模式-異步複制
- broker叢集由多個master構成，每個master又配置了多個slave（在配置了RAID磁盤陣列的情況下，一個master一般配置一個slave即可）。master與slave的關系是主備關系，即master負責處理消息的讀寫請求，而slave僅負責消息的備份與master當機後的角色切換。
- 異步複制即前面所講的複制政策中的異步複制政策，即消息寫入master成功後，master立即向producer傳回成功ACK，無需等待slave同步資料成功。
- 該模式的最大特點之一是，當master當機後slave能夠
自動切換
Slave從Master同步的延遲越短，其可能丢失的消息就越少，對于Master的RAID磁盤陣列；
若使用的也是異步複制政策，同樣也存在延遲問題，同樣也可能會丢失消息。
但RAID陣列的秘訣是微秒級的（因為是由硬碟支援的），是以其丢失的資料量會更少。
- 多Master多Slave模式-同步雙寫
- 該模式是
多Master多Slave模式
同步複制
同步雙寫
雙寫
- 該模式與異步複制模式相比，優點是消息的
安全性更高
- 該模式存在一個大的問題：對于目前的版本，Master當機後，Slave不會自動切換到Master（緻命問題）。
- 該模式是
- 最佳實踐
-
一般會為Master配置RAID10磁盤陣列，然後再為其配置一個Slave。即利用了RAID10磁盤陣列的高
效、安全性，又解決了可能會影響訂閱的問題。-------多M多S+RAID10陣列
1）RAID磁盤陣列的效率要高于Master-Slave叢集。因為RAID是硬體支援的。也正因為如此，是以RAID陣列
的搭建成本較高。
2）多Master+RAID陣列，與多Master多Slave叢集的差別是什麼？
-
多Master+RAID陣列，其僅僅可以保證資料不丢失，即不影響消息寫入，但其可能會影響到
消息的訂閱。但其執行效率要遠高于
多Master多Slave叢集
-
多Master多Slave叢集，其不僅可以保證資料不丢失，也不會影響消息寫入。其運作效率要低
于
多Master+RAID陣列
-
六、磁盤陣列RAID
1、RAID曆史
1988 年美國加州大學伯克利分校的 D. A. Patterson 教授等首次在論文 “A Case of Redundant Array ofInexpensive Disks” 中提出了 RAID 概念 ，即
廉價備援磁盤陣列
（ Redundant Array of InexpensiveDisks ）。
由于當時大容量磁盤比較昂貴， RAID 的基本思想是将多個容量較小、相對廉價的磁盤進行有機組合，進而以較低的成本獲得與昂貴大容量磁盤相當的容量、性能、可靠性。随着磁盤成本和價格的不斷降低， “廉價” 已經毫無意義。是以， RAID 咨詢委員會（ RAID Advisory Board, RAB ）決定用“ 獨立 ” 替代 “ 廉價 ” ，于時 RAID 變成了
獨立磁盤備援陣列
（ Redundant Array of IndependentDisks ）。但這僅僅是名稱的變化，實質内容沒有改變。
記憶體：32m/6.4G（IBM 10.1G）
2、RAID等級
RAID 這種設計思想很快被業界接納， RAID 技術作為
高性能、高可靠的存儲技術
，得到了非常廣泛的應用。 RAID 主要利用
鏡像、資料條帶和資料校驗
三種技術來擷取高性能、可靠性、容錯能力和擴充性，根據對這三種技術的使用政策群組合架構，可以把 RAID 分為不同的等級，以滿足不同資料應用的需求。
D. A. Patterson 等的論文中定義了 RAID0 ~ RAID6 原始 RAID 等級。随後存儲廠商又不斷推出 RAID7、 RAID10、RAID01 、 RAID50 、 RAID53 、 RAID100 等 RAID 等級，但這些并無統一的标準。目前業界與學術界公認的标準是 RAID0 ~ RAID6 ，而在實際應用領域中使用最多的 RAID 等級是 RAID0 、RAID1 、 RAID3 、 RAID5 、 RAID6 和 RAID10。
RAID 每一個等級代表一種實作方法和技術，等級之間并無高低之分。在實際應用中，應當根據使用者的資料應用特點，綜合考慮可用性、性能和成本來選擇合适的 RAID 等級，以及具體的實作方式。
3、關鍵技術
-
鏡像技術
鏡像技術是一種備援技術，為磁盤提供資料
備份功能
同時在磁盤陣列中産生兩個完全相同的資料副本，并且分布在兩個不同的磁盤上
并發讀取
不能并行寫
資料，寫多個副本通常會導緻一定的 I/O 性能下降。
鏡像技術提供了非常高的資料安全性，其代價也是非常昂貴的，需要至少雙倍的存儲空間。高成本限制了鏡像的廣泛應用，主要應用于至關重要的資料保護，這種場合下的資料丢失可能會造成非常巨大的損失。
-
資料條帶技術
将一個資料拆開，并行寫給多個磁盤中；資料條帶化技術是一種自動将 I/O操作負載均衡到多個實體磁盤上的技術。更具體地說就是，将一塊連續的資料分成很多小部分并把它們分别存儲到不同磁盤上。這就能使多個程序可以并發通路資料的多個不同部分，進而獲得最大程度上的 I/O 并行能力，極大地提升性能。
-
資料校驗技術
資料校驗技術是指， RAID 要在寫入資料的同時進行校驗計算，并将得到的校驗資料存儲在 RAID 成員磁盤中。校驗資料可以集中儲存在某個磁盤或分散存儲在多個不同磁盤中。當其中一部分資料出錯時，就可以對剩餘資料和校驗資料進行反校驗計算重建丢失的資料。
資料校驗技術相對于鏡像技術的優勢在于節省大量開銷，但由于每次資料讀寫都要進行大量的校驗運算，對計算機的運算速度要求很高，且必須使用硬體 RAID 控制器。在資料重建恢複方面，檢驗技術比鏡像技術複雜得多且慢得多。
4、RAID分類
從實作角度看， RAID 主要分為軟 RAID、硬 RAID 以及混合 RAID 三種。
-
軟 RAID
所有功能均有作業系統和 CPU 來完成，沒有獨立的 RAID 控制處理晶片和 I/O 處理晶片，效率自然最低。軟體完成
-
硬 RAID
配備了專門的 RAID 控制處理晶片和 I/O 處理晶片以及陣列緩沖，不占用 CPU 資源。效率很高，但成本也很高。硬體完成
-
混合 RAID
具備 RAID 控制處理晶片，但沒有專門的I/O 處理晶片，需要 CPU 和驅動程式來完成。性能和成本在軟RAID 和硬 RAID 之間。軟硬完成
5、常見RAID等級詳解
- JBOD
JBOD
，Just a Bunch of Disks，磁盤簇。表示一個沒有控制軟體提供協調控制的磁盤集合，這是 RAID差別與 JBOD 的主要因素。 JBOD 将
多個實體磁盤串聯起來
，提供一個巨大的
邏輯磁盤
·。
JBOD 的資料存放機制是由第一塊磁盤開始按順序往後存儲，目前磁盤存儲空間用完後，再依次往後面的磁盤存儲資料。 JBOD 存儲性能
完全等同于單塊磁盤
，而且也不提供資料安全保護。
多塊磁盤組成的邏輯磁盤；
其隻是簡單提供一種擴充存儲空間的機制，JBOD可用存儲容量等于所有成員磁盤的存儲空間之和
JBOD 常指磁盤櫃，而不論其是否提供 RAID 功能。不過，JBOD并非官方術語，官方稱為Spanning。
- RAID0
RAID0 是 一種簡單的、無資料校驗的
資料條帶化技術
。實際上不是一種真正的 RAID ，因為它并不提供任何形式的備援政策 。 RAID0 将所在磁盤條帶化後組成大容量的存儲空間，将資料分散存儲在所有磁盤中，以獨立通路方式實作多塊磁盤的
并讀通路
。
理論上講，一個由 n 塊磁盤組成的 RAID0 ，它的
讀寫性能是單個磁盤性能的 n 倍
，但由于總線帶寬等多種因素的限制，實際的性能提升低于理論值。由于可以并發執行 I/O 操作，總線帶寬得到充分利用。再加上不需要進行資料校驗，RAID0 的性能在所有 RAID 等級中是最高的。
RAID0 具有低成本、高讀寫性能、 100% 的高存儲空間使用率等優點，但是它不提供資料備援保護，一旦資料損壞，将無法恢複。
應用場景：對資料的順序讀寫要求不高，對資料的安全性和可靠性要求不高，但對系統性能要求很高的
場景。
RAID0與JBOD相同點：
1）存儲容量：都是成員磁盤容量總和
2）磁盤使用率，都是100%，即都沒有做任何的資料備援備份
RAID0與JBOD不同點：
JBOD：資料是順序存放的，一個磁盤存滿後才會開始存放到下一個磁盤
RAID：各個磁盤中的資料寫入是并行的，是通過資料條帶技術寫入的。其讀寫性能是JBOD的n倍
- RAID1
RAID1 就是一種
鏡像技術
，它将資料完全一緻地分别寫到工作磁盤和鏡像磁盤，它的磁盤空間使用率為 50% 。 RAID1 在資料寫入時，響應時間會有所影響，但是讀資料的時候沒有影響。 RAID1 提供了最佳的資料保護，一旦工作磁盤發生故障，系統将自動切換到鏡像磁盤，不會影響使用。
RAID1是為了增強資料安全性使兩塊磁盤資料呈現完全鏡像，進而達到安全性好、技術簡單、管理友善。 RAID1 擁有完全容錯的能力，但實作成本高。
應用場景：對順序讀寫性能要求較高，或對資料安全性要求較高的場景。
- RAID10
RAID10是一個RAID1與RAID0的組合體，是以
它繼承了RAID0的快速和RAID1的安全
。
簡單來說就是，
先做條帶，再做鏡像
。發即将進來的資料先分散到不同的磁盤，再将磁盤中的資料做鏡像。
- RAID01
RAID01是一個RAID0與RAID1的組合體，是以
它繼承了RAID0的快速和RAID1的安全
。
簡單來說就是，
先做鏡像,再做條帶
。即将進來的資料先做鏡像，再将鏡像資料寫入到與之前資料不同的磁盤，即再做條帶。
RAID10要比RAID01的容錯率再高，是以生産環境下一般是不使用RAID01的。
七、叢集搭建實踐
1、叢集架構
這裡要搭建一個雙主雙從異步複制的Broker叢集。為了友善，這裡使用了兩台主機來完成叢集的搭建。這兩台主機的功能與broker角色配置設定如下表。
| 序号 | 主機名/IP | IP | 功能 | BROKER角色 |
|---|---|---|---|---|
| 1 | s4 | 192.168.109.104 | NameServer + Broker | Master1 + Slave2 |
| 2 | s5 | 192.168.109.105 | NameServer + Broker | Master2 + Slave1 |
2、克隆生成s4
克隆主機，并修改配置。指定主機名為s4
↓
/etc/sysconfig/network-scripts/ifcfg-ens33
設定主機名：↓
hostnamectl set-hostname 你要設定的主機名
設定映射：↓
vim /etc/hosts
cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 s4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
reboot #重新開機linux伺服器
3、修改s4配置檔案
- 配置檔案位置
- 要修改的配置檔案在rocketMQ解壓目錄的
conf/2m-2s-async
- 要修改的配置檔案在rocketMQ解壓目錄的
- 修改broker-a.properties----------Master機
- 将該配置檔案内容修改為如下：
# 指定整個broker叢集的名稱，或者說是RocketMQ叢集的名稱 brokerClusterName=DefaultCluster # 指定master-slave叢集的名稱。一個RocketMQ叢集可以包含多個master-slave叢集 brokerName=broker-a # master的brokerId為0 brokerId=0 # 指定删除消息存儲過期檔案的時間為淩晨4點 deleteWhen=04 # 指定未發生更新的消息存儲檔案的保留時長為48小時，48小時後過期，将會被删除 fileReservedTime=48 # 指定目前broker為異步複制master brokerRole=ASYNC_MASTER # 指定刷盤政策為異步刷盤 flushDiskType=ASYNC_FLUSH # 指定Name Server的位址 namesrvAddr=192.168.109.104:9876;192.168.109.105:9876 Day363&364&365.RocketMQ的安裝&啟動 -RocketMQRocketMQ的安裝與啟動 - 修改broker-b-s.properties-------Salve機
- 将該配置檔案内容修改為如下：
brokerClusterName=DefaultCluster # 指定這是另外一個master-slave叢集 brokerName=broker-b # slave的brokerId為非0 brokerId=1 deleteWhen=04 fileReservedTime=48 # 指定目前broker為slave brokerRole=SLAVE flushDiskType=ASYNC_FLUSH namesrvAddr=192.168.109.104:9876;192.168.109.105:9876 # 指定Broker對外提供服務的端口，即Broker與producer與consumer通信的端口。預設10911。由于目前主機同時充當着master1與slave2，而前面的master1使用的是預設端口。這裡需要将這兩個端口加以區分，以區分出master1與slave2 listenPort=11911 # 指定消息存儲相關的路徑。預設路徑為~/store目錄。由于目前主機同時充當着master1與slave2，master1使用的是預設路徑，這裡就需要再指定一個不同路徑 storePathRootDir=~/store-s storePathCommitLog=~/store-s/commitlog storePathConsumeQueue=~/store-s/consumequeue storePathIndex=~/store-s/index storeCheckpoint=~/store-s/checkpoint abortFile=~/store-s/abort - 其它配置
- 除了以上配置外，這些配置檔案中還可以設定其它屬性。
#指定整個broker叢集的名稱，或者說是RocketMQ叢集的名稱 brokerClusterName=rocket-MS #指定master-slave叢集的名稱。一個RocketMQ叢集可以包含多個master-slave叢集 brokerName=broker-a #0 表示 Master，>0 表示 Slave brokerId=0 #多個nameServer位址，分号分割 namesrvAddr=nameserver1:9876;nameserver2:9876 #預設為建立Topic所建立的隊列數 defaultTopicQueueNums=4 #是否允許 Broker 自動建立Topic，建議生産環境中關閉 autoCreateTopicEnable=true #是否允許 Broker 自動建立訂閱組，建議生産環境中關閉 autoCreateSubscriptionGroup=true #Broker對外提供服務的端口，即Broker與producer與consumer通信的端口 listenPort=10911 #HA高可用監聽端口，即Master與Slave間通信的端口，預設值為listenPort+1 haListenPort=10912 #指定删除消息存儲過期檔案的時間為淩晨4點 deleteWhen=04 #指定未發生更新的消息存儲檔案的保留時長為48小時，48小時後過期，将會被删除 fileReservedTime=48 #指定commitLog目錄中每個檔案的大小，預設1G mapedFileSizeCommitLog=1073741824 #指定ConsumeQueue的每個Topic的每個Queue檔案中可以存放的消息數量，預設30w條 mapedFileSizeConsumeQueue=300000 #在清除過期檔案時，如果該檔案被其他線程所占用（引用數大于0，比如讀取消息），此時會阻止此次删除任務，同時在第一次試圖删除該檔案時記錄目前時間戳。該屬性則表示從第一次拒絕删除後開始計時，該檔案最多可以保留的時長。在此時間内若引用數仍不為0，則删除仍會被拒絕。不過時間到後，檔案将被強制删除 destroyMapedFileIntervalForcibly=120000 #指定commitlog、consumequeue所在磁盤分區的最大使用率，超過該值，則需立即清除過期文 件 diskMaxUsedSpaceRatio=88 #指定store目錄的路徑，預設在目前使用者主目錄中 storePathRootDir=/usr/local/rocketmq-all-4.5.0/store #commitLog目錄路徑 storePathCommitLog=/usr/local/rocketmq-all-4.5.0/store/commitlog #consumeueue目錄路徑 storePathConsumeQueue=/usr/local/rocketmq-all-4.5.0/store/consumequeue #index目錄路徑 storePathIndex=/usr/local/rocketmq-all-4.5.0/store/index #checkpoint檔案路徑 storeCheckpoint=/usr/local/rocketmq-all-4.5.0/store/checkpoint #abort檔案路徑 abortFile=/usr/local/rocketmq-all-4.5.0/store/abort #指定消息的最大大小 maxMessageSize=65536 #Broker的角色 # - ASYNC_MASTER 異步複制Master # - SYNC_MASTER 同步雙寫Master # - SLAVE brokerRole=SYNC_MASTER #刷盤政策 # - ASYNC_FLUSH 異步刷盤 # - SYNC_FLUSH 同步刷盤 flushDiskType=SYNC_FLUSH #發消息線程池數量 sendMessageThreadPoolNums=128 #拉消息線程池數量 pullMessageThreadPoolNums=128 #強制指定本機IP，需要根據每台機器進行修改。官方介紹可為空，系統預設自動識别，但多網卡時IP位址可能讀取錯誤 brokerIP1=192.168.3.105
4、克隆生成s5
重複上面的過程，克隆s4主機，并修改配置。指定主機名為s5。
5、修改s5配置檔案
對于s5主機，同樣需要修改rocketMQ解壓目錄的conf目錄的子目錄
2m-2s-async
中的兩個配置檔案。
- 修改broker-b.properties-----Master機
- 将該配置檔案内容修改為如下：
brokerClusterName=DefaultCluster brokerName=broker-b brokerId=0 deleteWhen=04 fileReservedTime=48 brokerRole=ASYNC_MASTER flushDiskType=ASYNC_FLUSH namesrvAddr=192.168.109.104:9876;192.168.109.105:9876 - 修改broker-a-s.properties---------Salve機
- 将該配置檔案内容修改為如下：
brokerClusterName=DefaultCluster brokerName=broker-a brokerId=1 deleteWhen=04 fileReservedTime=48 brokerRole=SLAVE flushDiskType=ASYNC_FLUSH namesrvAddr=192.168.109.104:9876;192.168.109.105:9876 listenPort=11911 storePathRootDir=~/store-s storePathCommitLog=~/store-s/commitlog storePathConsumeQueue=~/store-s/consumequeue storePathIndex=~/store-s/index storeCheckpoint=~/store-s/checkpoint abortFile=~/store-s/abort
6、啟動伺服器
- 啟動NameServer叢集
- 分别啟動s4與s5兩個主機中的NameServer。啟動指令完全相同。
nohup sh bin/mqnamesrv & tail -f ~/logs/rocketmqlogs/namesrv.log Day363&364&365.RocketMQ的安裝&啟動 -RocketMQRocketMQ的安裝與啟動 - 啟動兩個Master
-
分别啟動s4與s5兩個主機中的broker master。注意，它們指定所要加載的配置
檔案是不同的。
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties & tail -f ~/logs/rocketmqlogs/broker.log nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b.properties & tail -f ~/logs/rocketmqlogs/broker.log -
- 啟動兩個Slave
-
分别啟動s4與s5兩個主機中的broker slave。注意，它們指定所要加載的配置文
件是不同的。
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b-s.properties & tail -f ~/logs/rocketmqlogs/broker.log nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a-s.properties & tail -f ~/logs/rocketmqlogs/broker.log -
- 兩台機器s4/s5，兩個小叢集，s4中broker-a|broker-b-s，s5中broker-b|broker-a-s組成一個rocket叢集
八、mqadmin指令
在mq解壓目錄的bin目錄下有一個mqadmin指令，該指令是一個運維指令，用于對mq的主題，叢集，broker 等資訊進行管理。
1、修改bin/tools.sh
在運作mqadmin指令之前，先要修改mq解壓目錄下bin/tools.sh配置的JDK的ext目錄位置。本機的ext目錄在
/usr/local/java/jdk1.8.0_161/jre/lib/ext
。
使用vim指令打開tools.sh檔案，并在JAVA_OPT配置的-Djava.ext.dirs這一行的後面添加ext的路徑。
JAVA_OPT="${JAVA_OPT} -server -Xms1g -Xmx1g -Xmn256m -
XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m"
JAVA_OPT="${JAVA_OPT} -Djava.ext.dirs=${BASE_DIR}/lib:${JAVA_HOME}/jre/lib/ext:${JAVA_HOME}/lib/ext:/usr/local/java/jdk1.8.0_161/jre/lib/ext"
JAVA_OPT="${JAVA_OPT} -cp ${CLASSPATH}"
2、運作mqadmin
直接運作該指令，可以看到其可以添加的commands。通過這些commands可以完成很多的功能。
[[email protected] bin]# ./mqadmin
The most commonly used mqadmin commands are:
updateTopic Update or create topic
deleteTopic Delete topic from broker and NameServer.
updateSubGroup Update or create subscription group
deleteSubGroup Delete subscription group from broker.
updateBrokerConfig Update broker's config
updateTopicPerm Update topic perm
topicRoute Examine topic route info
topicStatus Examine topic Status info
topicClusterList get cluster info for topic
brokerStatus Fetch broker runtime status data
queryMsgById Query Message by Id
queryMsgByKey Query Message by Key
queryMsgByUniqueKey Query Message by Unique key
queryMsgByOffset Query Message by offset
QueryMsgTraceById query a message trace
printMsg Print Message Detail
printMsgByQueue Print Message Detail
sendMsgStatus send msg to broker.
brokerConsumeStats Fetch broker consume stats data
producerConnection Query producer's socket connection and client version
consumerConnection Query consumer's socket connection, client version and subscription
consumerProgress Query consumers's progress, speed
consumerStatus Query consumer's internal data structure
cloneGroupOffset clone offset from other group.
clusterList List all of clusters
topicList Fetch all topic list from name server
updateKvConfig Create or update KV config.
deleteKvConfig Delete KV config.
wipeWritePerm Wipe write perm of broker in all name server
resetOffsetByTime Reset consumer offset by timestamp(without client restart).
updateOrderConf Create or update or delete order conf
cleanExpiredCQ Clean expired ConsumeQueue on broker.
cleanUnusedTopic Clean unused topic on broker.
startMonitoring Start Monitoring
statsAll Topic and Consumer tps stats
allocateMQ Allocate MQ
checkMsgSendRT check message send response time
clusterRT List All clusters Message Send RT
getNamesrvConfig Get configs of name server.
updateNamesrvConfig Update configs of name server.
getBrokerConfig Get broker config by cluster or special broker!
queryCq Query cq command.
sendMessage Send a message
consumeMessage Consume message
updateAclConfig Update acl config yaml file in broker
deleteAccessConfig Delete Acl Config Account in broker
clusterAclConfigVersion List all of acl config version information in cluster
updateGlobalWhiteAddr Update global white address for acl Config File in broker
getAccessConfigSubCommand List all of acl config information in cluster
See 'mqadmin help <command>' for more information on a specific command.
3、該指令的官網詳解
該指令在官網中有詳細的用法解釋。
https://github.com/apache/rocketmq/blob/master/docs/cn/operation.md