背景介绍
为何选择 RocketMQ
纯 Java 开发，无依赖，使用简单，出现问题能 hold ；
经过阿里双十一考验，性能、稳定性可以保障；
功能实用，发送端：同步、异步、单边、延时发送；消费端：消息重置，重试队列，死信队列；
社区活跃，出问题能及时沟通解决。
使用情况
主要用于削峰、解耦、异步处理；
已在火车票、机票、酒店等核心业务广泛使用，扛住巨大的微信入口流量；
在支付、订单、出票、数据同步等核心流程广泛使用；
每天 1000+ 亿条消息周转。
MQ 双中心改造
为何做双中心
单机房故障业务可用；
保证数据可靠：若所有数据都在一个机房，一旦机房故障，数据有丢失风险；
横向扩容：单机房容量有限，多机房可分担流量。
双中心方案
做双中心之前，对同城双中心方案作了些调研，主要有冷（热）备份、双活两种。（当时社区 Dledger 版本还没出现，Dledger 版本完全可做为双中心的一种可选方案。）
双中心诉求
-
就近原则：生产者在 A 机房，生产的消息存于 A 机房 broker ； 消费者在 A 机房，消费的消息来自 A 机房 broker 。 -
单机房故障：生产正常，消息不丢。 -
broker 主节点故障：自动选主。
就近原则
简单说，就是确定两件事：
-
节点（客户端节点，服务端节点）如何判断自己在哪个 idc； -
客户端节点如何判断服务端节点在哪个 idc。
ip 查询：通过公司内部组件查询 ip 所在机房信息；
broker 名称增加机房信息：在配置文件中，将机房信息添加到 broker 名称上；
协议层增加机房标识：服务端节点向元数据系统注册时，将自身的机房信息一起注册。
相对于前两者，实现起来略复杂，改动了协议层， 我们采用了第二种与第三种结合的方式。
就近生产
就近消费
每个机房消息平均分给此机房消费端；
此机房没消费端，平分给其他机房消费端。
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)); //cid为当前客户端}
单机房故障
每组 broker 配置
单机房故障
消息生产跨机房；未消费消息在另一机房继续被消费。
故障切主
若 nameserver leader 监控到 broker 主节点异常, 并要求其他 follower 确认；半数 follower 认为 broker 节点异常，则 leader 通知在 broker 从节点中选主，同步进度大的从节点选为主;
新选举的 broker 主节点执行切换动作并注册到元数据系统；
生产端无法向旧 broker 主节点发送消息。
全局 Global 集群
就近原则
一主二从，写过半消息即及写入成功
元数据系统 raft 选主
broker 主节点故障，自动选主
MQ 平台治理
目的
让系统更稳定
及时告警
快速定位、止损
治理哪些方面
申请使用
生产速度
消息积压
消费节点掉线
发送、消费耗时检测
消息链路追踪
过低或有隐患版本检测
集群健康巡检
集群性能巡检
集群高可用
部分后台操作展示
新老消费端并存时，我们实现的队列分配算法不兼容，做到兼容即可；
主题、消费组数量多，注册耗时过长，内存 oom ，通过压缩缩短注册时间，社区已修复；
topic 长度判断不一致，导致重启丢消息，社区已修复；
centos 6.6 版本中，broker 进程假死，升级 os 版本即可。
MQ 未来展望
历史数据归档
底层存储剥离，计算与存储分离
基于历史数据，完成更多数据预测
服务端升级到 Dledger ，确保消息的严格一致
了解更多 RocketMQ 信息，可加入社区交流群，下面是钉钉群，欢迎大家加群留言。
本文分享自微信公众号 - RocketMQ官微（ApacheRocketMQ）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
