同程艺龙MQ高可用架构实践

1.

2. 同程艺龙MQ高可用架构实践刘树东同程旅行-研发中心

3. CONTENTS n 使用概况 n 同城双中心 n 平台治理 n 未来展望

4. CONTENTS Part1 使用概况

5. 选择RocketMQ Ø 纯Java开发，无依赖，使用简单，出现问题能hold； Ø 经过阿里双十一考验，性能、稳定性可以保障； Ø 功能实用，发送端：同步、异步、单边、延时发送；消费端：消息重置，重试队列，死信队列；

6. 使用场景 Ø 主要用于削峰、解耦、异步处理； Ø 已在火车票，机票，酒店广泛使用，扛住巨大的微信入口流量； Ø 每天 1000+ 亿条消息周转； Ø 深度定制开发

7. MQ使用框架图机票交通酒店 Java SDK & Http Proxy nameserver 交通机票元数据节点酒店 Broker Broker Broker Broker Broker Broker nameserver nameserver MQ服务平台

8. CONTENTS Part2 同城双中心

9. 目的 ü 单机房故障业务可用 ü 保证数据可靠若所有数据都在一个机房，一旦机房故障，数据有丢失风险 ü 横向扩容单机房容量有限，多机房可分担流量

10. 业务架构图

11. MQ同城冷备 RocketMQ Replicator

12. 同城MQ双活用户请求 idc2 idc1 应用A Produce MQ Consume 应用B 应用A Produce MQ Consume 应用B

13. 冷备vs双活 Ø 同城冷备资源利用不高同步topic, consumer, 消费进度等元数据 Ø 同城双活资源使用合理跟着业务走，业务流量在哪里，哪里生产消息

14. 几点诉求 1、就近生产---生产者在A机房，生产的消息存于A机房 broker 2、就近消费---消费者在A机房，消费的消息来自A机房 broker 3、单机房故障---生产正常，消息不丢 4、broker主节点故障---自动选主

15. 识别客户端机房 Ø 获取IP Ø 获取所在机房信息 Ø

16. 识别服务端机房 1、 IP 查询通过第三方组件查询每个机房IP段，需定时更新 2、协议层增加机房标识服务端节点向元数据系统注册时添加机房标识 3、 broker 名字增加机房标识

17. 就近生产 idc2 idc1 生产端_idc1 broker1_idc1 broker2_idc1 生产端_idc2 broker3_idc2 broker4_idc2

18. 就近消费按机房分配队列算法 Ø Ø 每个机房消息平均分给此机房消费端；此机房没消费端，平分给其他机房消费端 Map<String, Set> mqs = classifyMQByIdc(mqAll); Map<String, Set> cids = classifyCidByIdc(cidAll); Set<> result = new HashSet<>; for(element in mqs){ result.add(allocateMQAveragely(element, cids, cid)); }

19. 就近双边消费 idc2 idc1 broker1_idc1 broker2_idc1 消费端_idc1 broker3_idc2 broker4_idc2 消费端_idc2

20. 就近单边消费

21. 单机房故障 Ø 每组broker配置一主两从，一主一从在一机房，一从在另一机房；某一从同步完消息，消息即发送成功； Ø 单机房故障消息生产跨机房；未消费消息在另一机房继续被消费

22. 故障切主 Ø nameserver 基于raft协议选主; Ø broker向nameserver leader注册; Ø broker 主节点异常, 在broker 从节点中重新选主; Ø 生产端无法向旧broker leader发送消息

23. Nameserver元数据系统第三方idc 选主 nameserver3 idc2 idc1 nameserver1

24. 故障切主 Nameserver 元数据系统询问同步进度 broker-master 切从数据压缩同步 new broker slave broker-slave1 broker-slave2 询问同步进度切主数据压缩同步 new broker master

25. 切二中心

26. 回归后切一中心

27. 回顾 Ø 全局 Global集群 Ø 就近原则 Ø 一主二从，写过半消息即及写入成功 Ø 元数据系统raft选主 Ø broker主节点故障，自动选主

28. 总体架构图 Nameserver 元数据系统 idc1 producer idc2 producer broker1- slave1 broker1- slave2 broker1- master producer consumer 数据压缩同步 consumer consumer broker2- slave2 producer broker2- master broker2- slave1 consumer

29. CONTENTS Part3 平台治理

30. 目的 ü 让环境更稳定 ü 及时告警 ü 快速定位、止损

31. 主题/消费组治理 ü 申请使用 ü 生产速度 ü 消息积压 ü 消费节点掉线

32. 客户端治理 ü 发送、消费耗时检测 ü 消息统计 ü 消息链路追踪 ü过低版本检测

33. 服务端治理 ü 集群自我保护 ü 集群健康巡检 ü 集群性能巡检 ü 集群高可用

34. 主题与消费组申请

35. 数据统计

36. 集群监控

37. 踩过的坑 ü 新老消费端并存时，队列分配算法不兼容 ü 主题、消费组数量多，注册耗时过长，内存oom ü topic长度判断不一致，导致重启丢消息 ü broker进程假死，升级os版本

38. CONTENTS Part4 未来展望

39. 未来展望 Ø 历史数据归档 Ø 底层存储剥离，计算与存储分离 Ø 基于历史数据，完成更多数据预测

40.