原文：https://blog.csdn.net/lyly4413/article/details/80838716 1.消息中間件的發展： 第一代以ActiveMQ為代表，遵循JMS（java消息服務）規範 第二代以RabbitMQ為代表是一個有Erlang語言開發的AMQP(高級消息隊列協議)的 ...
原文：https://blog.csdn.net/lyly4413/article/details/80838716
1.消息中間件的發展：
第一代以ActiveMQ為代表，遵循JMS（java消息服務）規範 第二代以RabbitMQ為代表是一個有Erlang語言開發的AMQP(高級消息隊列協議)的開源實現 第三代以kafka為代表，是一代高吞吐、高可用的消息中間件，以及RocketMQ
RocketMQ的特點：
1.RocketMQ 是一款分散式、隊列模型的消息中間件，具有以下特點：
2.能夠保證嚴格的消息順序
3.提供豐富的消息拉取模式
4.高效的訂閱者水平擴展能力
5.實時的消息訂閱機制
6.億級消息堆積能力
7.分散式高可用的部署架構,滿足至少一次消息傳遞語義
8.提供 docker 鏡像用於隔離測試和雲集群部署
9.提供配置、指標和監控等功能豐富的 Dashboard
選用理由：
a.強調集群無單點，可擴展，任意一點高可用，水平可擴展。
b.海量消息堆積能力，消息堆積後，寫入低延遲。
c.支持上萬個隊列
d.消息失敗重試機制
e.消息可查詢
f.開源社區活躍
g.成熟度（經過雙十一考驗）
RocketMQ物理部署結構：
rocketMQ幾個概念：
producer：消息生產者，生產者的作用就是將消息發送到 MQ，生產者本身既可以產生消息，如讀取文本信息等。也可以對外提供介面，由外部應用來調用介面，再由生產者將收到的消息發送到 MQ
producer group: 生產者組，簡單來說就是多個發送同一類消息的生產者稱之為一個生產者組。在這裡可以不用關心，只要知道有這麼一個概念即可,Producer實例可以是多機器、單機器多進程、單進程中的多對象。Producer可以發送多個Topic。處理分散式事務時，也需要Producer集群提高可靠性
consumer : 消息消費者，簡單來說，消費 MQ 上的消息的應用程式就是消費者，至於消息是否進行邏輯處理，還是直接存儲到資料庫等取決於業務需要
consumer group : 消費者組，和生產者類似，消費同一類消息的多個 consumer 實例組成一個消費者組.Consumer實例 的集合。Consumer 實例可以是多機器、但機器多進程、單進程中的多對象。同一個Group中的實例，在集群模式下，以均攤的方式消費；在廣播模式下，每個實例都全部消費。
Topic : Topic 是一種消息的邏輯分類，比如說你有訂單類的消息，也有庫存類的消息，那麼就需要進行分類，一個是訂單 Topic 存放訂單相關的消息，一個是庫存 Topic 存儲庫存相關的消息
Message : Message 是消息的載體。一個 Message 必須指定 topic，相當於寄信的地址。Message 還有一個可選的 tag 設置，以便消費端可以基於 tag 進行過濾消息。也可以添加額外的鍵值對，例如你需要一個業務 key 來查找 broker 上的消息，方便在開發過程中診斷問題
Tag : 標簽可以被認為是對 Topic 進一步細化。一般在相同業務模塊中通過引入標簽來標記不同用途的消息
Broker : Broker 是 RocketMQ 系統的主要角色，其實就是前面一直說的 MQ。Broker 接收來自生產者的消息，儲存以及為消費者拉取消息的請求做好準備
Name Server : Name Server 為 producer 和 consumer 提供路由信息
Push Consumer : 應用通常向Consumer對象註冊一個Listener介面，一旦收到消息，Consumer對象立刻回調Listener介面方法。所以，所謂Push指的是客戶端內部的回調機制，並不是與服務端之間的機制
Pull Consumer : 應用通常主動調用Consumer從服務端拉消息，然後處理。這用的就是短輪詢方式了，在不同情況下，與長輪詢各有優點
Broker 的搭建方式：
1.單個Master模式 : 這種方式風險較大，一旦 Broker 重啟或者宕機時，會導致整個服務不可用，不建議線上環境使用
2.多個Master模式： 一個集群無 Slave，全是 Master，例如 2 個 Master 戒者 3 個 Master
優點：配置簡單，單個 Master 宕機或重啟維護對應用無影響，在磁碟配置為 RAID10 時，即使機器宕機不可恢復情況下，由於 RAID10 磁碟非常可靠，消息也不會丟（非同步刷盤丟失少量消息，同步刷盤一條會丟）。性能最高。
缺點：單台機器宕機期間，這台機器上未被消費的消息在機器恢復之前不可訂閱，消息實時性會受到影響。
3.多Msater多slave模式，非同步複製 ： 每個 Master 配置一個 Slave，有多對 Master-Slave，HA 採用非同步複製方式，主備有短暫消息延遲，毫秒級。
優點：即使磁碟損壞，消息丟失的非常少，且消息實時性不會受影響，因為 Master 宕機後，消費者仍然可以從 Slave 消費，此過程對應用透明。不需要人工干預。性能同多 Master 模式幾乎一樣。
缺點：Master 宕機，磁碟損壞情況，會丟失少量消息
4.多Master多slave模式，同步雙寫 ： 每個 Master 配置一個 Slave，有多對 Master-Slave，HA 採用同步雙寫方式，主備都寫成功，嚮應用返回成功。
優點：數據不服務都無單點，Master 宕機情況下，消息無延遲，服務可用性與數據可用性都非常高
缺點：性能比非同步複製模式略低，大約低 10%左右，發送單個消息的 RT 會略高。目前主宕機後，備機不能能自動切換為主機，後續會支持自動切換功能。
RocketMQ架構：
rocketmq-broker：整個mq的核心，他能夠接受producer和consumer的請求，並調用store層服務對消息進行處理。HA服務的基本單元，支持同步雙寫，非同步雙寫等模式。
rocketmq-client：：mq客戶端實現，目前官方僅僅開源了java版本的mq客戶端，c++，go客戶端有社區開源貢獻。
rocketmq-common：一些模塊間通用的功能類，比如一些配置文件、常量。
rocketmq-example：官方提供的例子，對典型的功能比如order message，push consumer，pull consumer的用法進行了示範。
rocketmq-filtersrv：消息過濾服務，相當於在broker和consumer中間加入了一個filter代理。
rocketmq-remoting：基於netty的底層通信實現，所有服務間的交互都基於此模塊。
rocketmq-srvut：解析命令行的工具類。
rocketmq-store：存儲層實現，同時包括了索引服務，高可用HA服務實現。
rocketmq-tools：mq集群管理工具，提供了消息查詢等功能。
RocketMQ存儲方式：
如上圖所示：
（1）所有數據單獨儲存到commit Log ，完全順序寫，隨機讀（2）對最終用戶展現的隊列實際只儲存消息在Commit Log 的位置信息，並且串列方式刷盤
這樣做的好處：
（1）隊列輕量化，單個隊列數據量非常少
（2）對磁碟的訪問串列話，避免磁碟競爭，不會因為隊列增加導致IOWait增高
每個方案都有優缺點，他的缺點是：
（1）寫雖然是順序寫，但是讀卻變成了隨機讀
（2）讀一條消息，會先讀Consume Queue，再讀Commit Log，增加了開銷
（3）要保證Commit Log 與 Consume Queue完全的一致，增加了編程的複雜度
以上缺點如何剋服：
（1）隨機讀，儘可能讓讀命中pagecache，減少IO操作，所以記憶體越大越好。如果系統中堆積的消息過多，讀數據要訪問硬碟會不會由於隨機讀導致系統性能急劇下降，答案是否定的。
a）訪問pagecache時，即使只訪問1K的消息，系統也會提前預讀出更多的數據，在下次讀時就可能命中pagecache
b）隨機訪問Commit Log 磁碟數據，系統IO調度演算法設置為NOOP方式，會在一定程度上將完全的隨機讀變成順序跳躍方式，而順序跳躍方式讀較完全的隨機讀性能高5倍
（2）由於Consume Queue存儲數量極少，而且順序讀，在pagecache的與讀取情況下，Consume Queue的讀性能與記憶體幾乎一直，即使堆積情況下。所以可以認為Consume Queue完全不會阻礙讀性能
（3）Commit Log中存儲了所有的元信息，包含消息體，類似於MySQl、Oracle的redolog，所以只要有Commit Log存在， Consume Queue即使丟失數據，仍可以恢復出來
