RocketMQ
主流的MQ有很多，比如ActiveMQ、RabbitMQ、RocketMQ、Kafka、ZeroMQ等。
之前阿里巴巴也是使用ActiveMQ，隨着業務發展，ActiveMQ IO 模塊出現瓶頸，後來阿里巴巴 通過一系列優化但是還是不能很好的解決，之後阿里巴巴把注意力放到了主流消息中間件kafka上面，但是kafka並不能滿足他們的要求，尤其是低延遲和高可靠性。
所以RocketMQ是站在巨人的肩膀上（kafka）MetaQ的內核，又對其進行了優化讓其更滿足互聯網公司的特點。它是純Java開發，具有高吞吐量、高可用性、適合大規模分佈式系統應用的特點。 RocketMQ目前在阿里集團被廣泛應用於交易、充值、流計算、消息推送、日誌流式處理、binglog分發等場景。
RocketMQ 功能 大綱
RocketMQ介紹
- 消息隊列應用場景
- rocketmq中的角色
- nameserver
- 官網解讀
消息發送
-
同步發送
-
異步發送
-
單向發送
-
消息批量發送
-
消息結構
-
消息發送流程
消息存儲
- 存儲方式
- 發送消息時存儲流程
- 存儲文件與內存映射
- 刷盤機制
- 文件恢復與過期刪除機制
- 索引
消息消費
- 消息訂閱
- 消息拉取和推送
- 消息處理隊列
- 順序消費
- 定時消息機制
- 消息過濾TAG與sql92
- FilterServer過濾機制
- 併發消息消費
- 消費負載與算法
- 消費者動態添加
- 消息消費過程
- ACK
- 消費進度與offset
Rocketmq集羣 HA
- 集羣搭建
- 主從同步複製原理
- 讀寫分離機制
整合
- 使用spring
- SpringCloud整合
監控與運維
- rocketmq-console監控平臺
- 命令行運維 MQAdmin
- 自定義日誌
消息隊列介紹
消息隊列是《數據結構》中先進先出的一種數據結構，在當前的架構中，作爲中間件提供服務。
消息中間件功能
應用解耦
AB應用不在互相依賴
流量削峯
流量達到高峯的時候，通常使用限流算法來控制流量湧入系統，避免系統被擊癱，但是這種方式損失了一部分請求
此時可以使用消息中間件來緩衝大量的請求，勻速消費，當消息隊列中堆積消息過多時，我們可以動態上線增加消費端，來保證不丟失重要請求。
大數據處理
消息中間件可以把各個模塊中產生的管理員操作日誌、用戶行爲、系統狀態等數據文件作爲消息收集到主題中
數據使用方可以訂閱自己感興趣的數據內容互不影響，進行消費
異構系統
跨語言
RocketMQ 角色
broker
- Broker面向producer和consumer接受和發送消息
- 向nameserver提交自己的信息
- 是消息中間件的消息存儲、轉發服務器。
- 每個Broker節點，在啓動時，都會遍歷NameServer列表，與每個NameServer建立長連接，註冊自己的信息，之後定時上報。
broker集羣
- Broker高可用，可以配成Master/Slave結構，Master可寫可讀，Slave只可以讀，Master將寫入的數據同步給Slave。
- 一個Master可以對應多個Slave，但是一個Slave只能對應一個Master
- Master與Slave的對應關係通過指定相同的BrokerName，不同的BrokerId來定義BrokerId爲0表示Master，非0表示Slave
- Master多機負載，可以部署多個broker
- 每個Broker與nameserver集羣中的所有節點建立長連接，定時註冊Topic信息到所有nameserver。
producer
- 消息的生產者
- 通過集羣中的其中一個節點（隨機選擇）建立長連接，獲得Topic的路由信息，包括Topic下面有哪些Queue，這些Queue分佈在哪些Broker上等
- 接下來向提供Topic服務的Master建立長連接，且定時向Master發送心跳
consumer
消息的消費者，通過NameServer集羣獲得Topic的路由信息，連接到對應的Broker上消費消息。
注意，由於Master和Slave都可以讀取消息，因此Consumer會與Master和Slave都建立連接。
nameserver
底層由netty實現，提供了路由管理、服務註冊、服務發現的功能，是一個無狀態節點
nameserver是服務發現者，集羣中各個角色（producer、broker、consumer等）都需要定時想nameserver上報自己的狀態，以便互相發現彼此，超時不上報的話，nameserver會把它從列表中剔除
nameserver可以部署多個，當多個nameserver存在的時候，其他角色同時向他們上報信息，以保證高可用，
NameServer集羣間互不通信，沒有主備的概念
nameserver內存式存儲，nameserver中的broker、topic等信息默認不會持久化
爲什麼不用zookeeper？：rocketmq希望爲了提高性能，CAP定理，客戶端負載均衡
對比JSM中的Topic和Queue
Topic是一個邏輯上的概念，實際上Message是在每個Broker上以Queue的形式記錄。
對應到JMS中的topic實現是由客戶端來完成的
consumer.setMessageModel(MessageModel.BROADCASTING);