待詢問的問題：

1. 安全
2. 外掛
3. CHAS
4. 備機接管

暖場

1. 目前正在考慮多語言的支援，後續新增C++, PYTHON, NODE.JS等客戶端.
2. OpenMessaging v1.0 Pre-Review版本即將釋出

PS：主持人真的是技術出身，暖場略尷尬。

1. Apache RocketMQ 101 ——劉振東

問題場景

1. 非同步、解耦
2. 削峰填谷
3. 排隊引擎

Comment：我自己總結的大約是4種能力：非同步解耦；削峰填谷；壓力轉移；任務分配。

基本概念

概念模型 Producer----Topic----Consumer

• Pub-Sub / Producer / Consumer
• Topic / MessageQueue
• CommitLog / ConsumerQueue/Offset
• Broker / Nameserver

mqadmin工具，可遠端訪問NameServer，查詢叢集狀態等豐富的功能。

NameServer儲存的是所有的資訊，那是否有一定上限？
回答：NameServer只儲存broker的路由資訊，不儲存consumer offset。

最常用的功能：

1. 傳送訊息，檢視訊息在不在
2. Broker狀態
3. 消費訊息，檢視還有多少訊息

使用訊息系統時容易碰到的問題

1. 冪等
   通過業務ID解決
2. 順序
   分割槽有序，非嚴格有序
   順序訊息的擴容：
   停寫：保證訊息消費完成後再擴Queue
   不停寫：成倍擴容可以保證雜湊不會到錯位的queue
3. 消費位點重置
   可以消費者線上實現位點重置
4. 補數
   黑科技：%RETRY%CLIENT可以指定消費者補數

特性

1. Schedule
   分級定時機制，時間輪特性，未釋出

   
   
   

   時間輪

2. Batch
   通過Batch實現原子一致性

3. Filtered by Tag
   通過Tag進行訊息過濾
   支援SQL語法

4. 事務

2. Sentinel

負責流量的控制，限流，熔斷降級
通過令牌機制來進行流量控制

Hystrix VS Sentinel

• 設計理念不同
• 熔斷概念不同
• 目標集不同

可整合到RocketMQ的客戶端中

1. 引入Jar包

2. 增加程式碼
   客戶端級別的削峰填谷

   
   
   

   RocketMQ的客戶端監控
   
   
   

   客戶端的流控

3. 通過RMQ構建企業級別的訊息平臺

STAGE 0. 各個應用使用各自的訊息佇列
STAGE 1. TOPIC數量增加導致Kafka無法承載，設定Producer-Proxy來解決Kafka 0.8的bug
STAGE 2. 調研選擇一個MQ引擎

STAGE 3. 資料遷移、功能迭代優化、服務化

訊息平臺架構很完整

當時使用RocketMQ面臨的挑戰

• 多語言支援
• 研發人員少
• 無原始碼閱讀
• 時間緊張
• 99.995%的可用性要求

策略：

1. 先跑起來
   使用THRIFT實現簡單的功能
   客戶端最簡化
   最小化使用者功能
2. 遷移
   將應用逐步遷移到RocketMQ上
   Producer Proxy和Consumer Proxy支援資料的雙寫雙讀，同時從Kafka和RocketMQ上寫資料讀資料。

自己實現的功能：

1. 主備自動切換
2. BATCH的擴充套件，支援不同TOPIC不同QUEUE的寫入
3. 百萬TOPIC的支援：後設資料管理的優化
4. 整合內部監控和部署工具
5. BUG-FIX

踩過的坑：

1. 讀老資料：random IO導致。通過在備機做操作來實現。同步主備會有影響。
2. 刪除過期資料導致IO飈高：預設儲存72小時，預設凌晨4點刪除。FILERESERVEDTIME, DELETEWHEN, DELETECOMMITLOGFILESINTERVAL, DELETECONSUMERQUEUEFILESINTERVAL.
   可通過設定多個刪除時間點來緩解
3. 訊息索引的建立可以放在備機上實現。

4. 事務訊息

XA事務（兩階段提交）帶來的問題：資源的阻塞
三階段提交增加pre-commit和pre-rollback可以達到最終一致性。

XA、SAGA、TCC

關鍵點：

1. Half Topic。由Broker攔截，並儲存事務訊息到Half Topic
2. Op Topic：狀態訊息的偏移量，服務端啟動掃描half和op topic的差異，判斷half topic裡的訊息是否需要投遞到真實的user topic中。

5. MQTT Bridge for Apache RocketMQ

核心問題：可用性、實時性、可靠性

可用性
服務發現問題：使用DNS server進行bridge的註冊
快速故障恢復：通過無狀態+共享儲存實現

實時性
通過解耦消費者的ack實現

高可靠
訊息儲存實現。

6. 流處理

• RMQ + STORM
• RMQ + SPARK
• RMQ + FLINK

• RMQ + AVRO

  
  
  

  一個使用flink與rmq結合的案例

話說聽到這裡已經聽了3個小時，我的狀態已經有點懵逼了……

乾貨滿滿，感謝。