RocketMQ的基礎概念和架構-RocketMQ知識體系(一）
前面幾篇文章分享了kafka 相關的實現邏輯，kafka在大吞吐量方面有較好的表現，但是有時候我們需要實現比較復雜的業務邏輯從而對于吞吐量方面要求不是太高，這個時候我們就可以選擇RocketMQ.
有了Kafka 為什么還要RocketMQ?
我們知道kafka 的性能非常好，吞吐量也非常大。Kafka單機寫入 TPS 號稱在百萬條/秒;追求性能的話，Kafka單機性能更高。這也依靠基于他的順序寫入，Memory Mapped Files 技術 和消費者端的zero copy。(kafka基于sendfile實現Zero Copy，直接從內核空間(DMA的)到內核空間(Socket的)，然后發送網卡。)但是對平常工作中各種復雜的應用場景及對數據可靠性要求嚴格的業務就有點力不從心了。我們從以下幾個方面分析：
【數據可靠性方面】
RocketMQ所支持的同步方式提升了數據的可靠性，RocketMQ支持異步/同步刷盤;異步/同步Replication;Kafka使用異步刷盤方式，異步Replication。
【消息順序性】
Kafka 某些配置下，支持消息順序，但是一臺Broker宕機后，就會產生消息亂序;
RocketMQ支持嚴格的消息順序，在順序消息場景下，一臺Broker宕機后，
發送消息會失敗，但是不會亂序;
【關于定時/延時消息】
Kafka不支持定時消息;
RocketMQ支持定時消息;
【關于分布式事務消息】
Kafka不支持分布式事務消息;RocketMQ支持分布式事務消息
【關于消息查詢機制】
Kafka不支持消息查詢。
RocketMQ支持根據Message Id查詢消息，也支持根據消息內容查詢消息
【關于Broker 的設計上】
當broker里面的topic的partition數量過多時，kafka的性能卻不如rocketMQ。
kafka和rocketMq都使用文件存儲，但是kafka是一個分區一個文件，當topic過多，分區的總量也會增加，kafka中存在過多的文件，當對消息刷盤時，就會出現文件競爭磁盤，出現性能的下降。一個partition(分區)一個文件，順序讀寫。一個分區只能被一個消費組中的一個 消費線程進行消費，因此可以同時消費的消費端也比較少。
rocketMq所有的隊列都存儲在一個文件中，每個隊列的存儲的消息量也比較小，因此topic的增加對rocketMq的性能的影響較小。rocketMq可以存在的topic比較多，可以適應比較復雜的業務。
RocketMQ架構設計
RocketMq技術架構
RocketMQ架構上主要分為四部分，如上圖所示:
- Producer：消息發布的角色，支持分布式集群方式部署。Producer通過MQ的負載均衡模塊選擇相應的Broker集群隊列進行消息投遞，投遞的過程支持快速失敗并且低延遲。
- Consumer：消息消費的角色，支持分布式集群方式部署。支持以push推，pull拉兩種模式對消息進行消費。同時也支持集群方式和廣播方式的消費，它提供實時消息訂閱機制，可以滿足大多數用戶的需求。
- NameServer：NameServer是一個非常簡單的Topic路由注冊中心，其角色類似Dubbo中的zookeeper，支持Broker的動態注冊與發現。主要包括兩個功能：Broker管理，NameServer接受Broker集群的注冊信息并且保存下來作為路由信息的基本數據。然后提供心跳檢測機制，檢查Broker是否還存活;路由信息管理，每個NameServer將保存關于Broker集群的整個路由信息和用于客戶端查詢的隊列信息。然后Producer和Conumser通過NameServer就可以知道整個Broker集群的路由信息，從而進行消息的投遞和消費。NameServer通常也是集群的方式部署，各實例間相互不進行信息通訊。Broker是向每一臺NameServer注冊自己的路由信息，所以每一個NameServer實例上面都保存一份完整的路由信息。當某個NameServer因某種原因下線了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以動態感知Broker的路由的信息。但是NameServer 并不會像ZK 一樣提供選舉功能
- BrokerServer：Broker主要負責消息的存儲、投遞和查詢以及服務高可用保證，為了實現這些功能，Broker包含了以下幾個重要子模塊。
- Remoting Module：整個Broker的實體，負責處理來自clients端的請求。
- Client Manager：負責管理客戶端(Producer/Consumer)和維護Consumer的Topic訂閱信息
- Store Service：提供方便簡單的API接口處理消息存儲到物理硬盤和查詢功能。
- HA Service：高可用服務，提供Master Broker 和 Slave Broker之間的數據同步功能。
- Index Service：根據特定的Message key對投遞到Broker的消息進行索引服務，以提供消息的快速查詢。
RocketMq架構部署
RocketMQ 網絡部署特點
NameServer是一個幾乎無狀態節點，可集群部署，節點之間無任何信息同步。
- Broker部署相對復雜，Broker分為Master與Slave，一個Master可以對應多個Slave，但是一個Slave只能對應一個Master，Master與Slave 的對應關系通過指定相同的BrokerName，不同的BrokerId 來定義，BrokerId為0表示Master，非0表示Slave。Master也可以部署多個。每個Broker與NameServer集群中的所有節點建立長連接，定時注冊Topic信息到所有NameServer。注意：當前RocketMQ版本在部署架構上支持一Master多Slave，但只有BrokerId=1的從服務器才會參與消息的讀負載。
- Producer與NameServer集群中的其中一個節點(隨機選擇)建立長連接，定期從NameServer獲取Topic路由信息，并向提供Topic 服務的Master建立長連接，且定時向Master發送心跳。Producer完全無狀態，可集群部署。
- Consumer與NameServer集群中的其中一個節點(隨機選擇)建立長連接，定期從NameServer獲取Topic路由信息，并向提供Topic服務的Master、Slave建立長連接，且定時向Master、Slave發送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，消費者在向Master拉取消息時，Master服務器會根據拉取偏移量與最大偏移量的距離(判斷是否讀老消息，產生讀I/O)，以及從服務器是否可讀等因素建議下一次是從Master還是Slave拉取。
結合部署架構圖，描述集群工作流程：
- 啟動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建立連接通道，開始消費消息。
模塊間數據流轉
生產-消費模型
生產消費流程
