消息中間件的應用場景
- 異步解耦
- 削峯填谷
- 順序收發
- 分佈式事務一致性
騰訊應用案例：
主流 MQ 框架及對比
說明
- Kafka：整個行業應用廣泛
- RocketMQ：阿里，從 apache 孵化
- Pulsar：雅虎開源，符合雲原生架構的消息隊列，社區活躍
- RabbitMQ 架構比較老，AMQP並沒有在主流的 MQ 得到支持
- NSQ：內存型，不是最優選擇
- ActiveMQ、ZeroMQ 可忽略
Kafka 優點
- 非常成熟，生態豐富，與 Hadoop 連接緊密
- 吞吐非常高，可用性高
- sharding
- 提升 replication 速度
- 主要功能：pub-sub，壓縮支持良好
- 可按照 at least once, at most once 進行配置使用，exactly once 需要 Consumer 配合
- 集羣部署簡單，但 controller 邏輯很複雜，實現partition 的多副本、數據一致性
- controller 依賴 ZooKeeper
- 異步刷磁盤（除了錢的業務，很少有同步 flush 的需求）
Kafka 缺點
- 寫入延時穩定性問題，partition 很多時
- Kafka 通常用機械盤，隨機寫造成吞吐下降和延時上升
- 100ms ~ 500ms
- 運維的複雜性
- 單機故障後補充副本
- 數據遷移
- 快手的優化：遷移 partition 時舊數據不動，新數據寫入新 partition 一定時間後直接切換
RocketMQ
- 阿里根據 Kafka 改造適應電商等在線業務場景
- 以犧牲性能爲代價增強功能
- 按 key 對消息查詢，維護 hash 表，影響 io
- 爲了在多 shard 場景下保證寫入延遲穩定，在 broker 級別將所有 shard 當前寫入的數據放入一個文件，形成 commitlog list，放若干個 index 文件維護邏輯 topic 信息，造成更多的隨機讀
- 沒有中心管理節點，現在看起來並沒有什麼用，元數據並不多
- 高精度的延遲消息（快手已支持秒級精度的延遲消息）
Pulsar
- 存儲、計算分離，方便擴容
- 存儲：bookkeeper
- MQ邏輯：無狀態的 broker 處理
發展趨勢
- 雲原生
- 批流一體：跑任務時，需要先把 Kafka 數據→HDFS，資源消耗大。如果本來就存在 HDFS，能節省很大資源
- Serverless
各公司發展
- 快手：Kafka
- 所有場景均在使用
- 特殊形態的讀寫分離
- 數據實時消費到 HDFS
- 在有明顯 lag 的 consumer 讀取時，broker 把請求從本地磁盤轉發的 HDFS
- 不會因爲有 lag 的 consumer 對日常讀寫造成明顯的磁盤隨機讀寫
- 由於自己改造，社區新功能引入困難
- 阿里巴巴：開源 RocketMQ
- 字節跳動
- 在線場景：NSQ→RocketMQ
- 離線場景：Kafka→自研的存儲計算分類的 BMQ（協議層直接兼容Kafka，用戶可以不換 client）
- 百度：自研的 BigPipe，不怎麼樣
- 美團：Kafka 架構基礎上用 Java 進行重構，內部叫 Mafka
- 騰訊：部分使用了自研的 PhxQueue，底層是 KV 系統
- 滴滴：DDMQ
- 對 RocketMQ 和 Kafka 進行封裝
- 多機房數據一致性可能有問題
- 小米：自研 Talos
- 架構類似 pulsar，存儲是 HDFS，讀場景有優化
Kafka
- Kafka官網：https://kafka.apache.org/documentation/#uses
- 最新版本：2.7
Kafka 是什麼？
- 開源的消息引擎系統（消息隊列/消息中間件）
- 分佈式流處理平臺
- 發佈/訂閱模型
- 削峯填谷
Kafka 術語
- Topic：發佈訂閱的主題
- Producer：向Topic發佈消息的客戶端
- Consumer：消費者
- Consumer Group：消費者組，多個消費者共同組成一個組
- Broker：Kafka的服務進程
- Replication：備份，相同數據拷貝到多臺機器
- Leader Replica
- Follower Replica，不與外界交互
- Partition：分區，解決伸縮性問題，多個Partition組成一個Topic
- Segment：partition 由多個 segment 組成
Kafka 如何持久化？
- 消息日誌（Log）保存數據，磁盤追加寫（Append-only）
- 避免緩慢的隨機I/O操作
- 高吞吐
- 定期刪除消息（日誌段）
Kafka 文件存儲機制
https://www.open-open.com/lib/view/open1421150566328.html
- 每個 partition 相當於一個巨型文件→多個大小相等 segment 數據文件中
- 每個 partition 只需要順序讀寫就行了，segment 文件生命週期由配置決定
- segment file 組成：
- index file：索引文件
- data file：數據文件
- segment file 文件命名規則：
- 全局第一個 segment 是 0
- 後序每個加上全局 partition 的最大 offset
一對 segment file
message 物理結構
分區
爲什麼分區？
- Kafka的消息組織方式：主題-分區-消息
- 一條消息，僅存在某一個分區中
- 提高伸縮性，不同分區可以放到不同機器，讀寫操作也是以分區粒度
分區策略？
- 輪詢
- 隨機
- 按 key 保序，單分區有序
Kafka 是否會消息丟失？
- 只對“已提交”的消息做有限度的持久化保證
- 已提交的消息：消息寫入日誌文件
- 有限度的持久化保證：N個 broker 至少一個存活
- 生產者丟失數據
- producer.send(msg) 異步發送消息，不保證數據到達Kafka
- producer.send(msg, callback) 判斷回調
- 消費者程序丟失數據
- 應該「先消費消息，後更新位移的順序」
- 新問題：消息的重複處理
- 多線程異步處理消息，Consumer不要開啓自動提交位移，應用程序手動提交位移
控制器
- 在 ZooKeeper幫助下管理和協調整個 Kafka 集羣
- 運行過程中，只能有一個 Broker 成爲控制器
控制器如何選舉？
在 ZooKeeper 創建 /controller 節點，第一個創建成功的 Broker 被指定爲控制器。
控制器有什麼用？
- 主題管理（創建、刪除、增加分區）
- 分區重分配
- 領導者選舉
- 集羣成員管理（新增 Broker、Broker 主動關閉、Broker 宕機）（ZooKeeper 臨時節點）
- 數據服務：最全的集羣元數據信息
控制器故障轉移
- 只有一個 Broker 當控制器，單點失效，立即啓用備用控制器
Kafka 的 ZooKeeper 存儲結構
分佈式事務的應用場景
- 團隊內部，某些操作要同時更新多個數據源
- 業務團隊 A 完成某個操作後，B 業務的某個操作也必須完成，A 業務並不能直接訪問 B 的數據庫
- 公司之間，用戶付款後，支付系統（支付寶/微信）必須通知商家的系統更新訂單狀態
兩階段最終一致
- 先完成數據源 A 的事務（一階段）
- 成功後通過某種機制，保證數據源 B 的事務（二階段）也一定最終完成
- 不成功，會不斷重試直到成功爲止
- 或達到一定重試次數後停止（配合對賬、人工處理）
如何保證最終一致？
爲了保證最終一致，消息系統和業務程序需要保證：
- 消息發送的一致性：消息發送時，一階段事務和消息發送必須同時成功或失敗
- 消息存儲不丟失：消息發送成功後，到消息被成功消費前，消息服務器（broker）必須存儲好消息，保證發生故障時，消息不丟失
- 消費者不丟失消息：處理失敗不丟棄，重試直到成功爲止
消息發送的一致性如何保證？
目標：本地事務、消息發送必須同時成功/失敗
問題
- 先執行本地事務，再發送消息，消息可能發送失敗
- 可把失敗的消息放入內存，稍後重試，但成功率也無法達到 100%
解決方案`* 先發送半消息（Half Msg，類似 Prepare 操作），不會投遞給消費者
- 半消息發送成功，再執行 DB 操作
- DB 操作執行成功後，提交半消息
發送異常會如何？
- 1 異常，半消息發送失敗，本地 DB 沒有執行，整個操作失敗，DB/消息的狀態一致（都沒有提交）
- 2 異常/超時
- 生產者以爲失敗了，不執行 DB
- broker 存儲半消息成功，等不到後序操作，會詢問生產者是提交還是回滾（第6步）
- 3 DB操作失敗：生產者在第 4 步告知 broker 回滾半消息
- 4 提交/回滾半消息失敗：broker 等不到這個操作，觸發回查（第 6 步）
- 5、6、7回查失敗：RocketMQ 最多回查 15 次
代碼、思維導圖筆記鏈接
代碼和思維導圖在 GitHub 項目中，歡迎大家 star！
coding 筆記、點滴記錄，以後的文章也會同步到公衆號（Coding Insight）中，希望大家關注_
