共计 1793 个字符，预计需要花费 5 分钟才能阅读完成。
简介：本文通过喜马拉雅的 RocketMQ 治理实际分享，让大家理解应用消息中间件过程中可能遇到的问题，防止实战中踩坑。
作者：曹融，来自喜马拉雅，从事微服务和音讯相干中间件开发。
本文通过喜马拉雅的 RocketMQ 治理实际分享，让大家理解应用消息中间件过程中可能遇到的问题，防止实战中踩坑。
业务背景现状以及遇到的问题
1、音讯队列详情
（1）在线场景：RabbitMQ，实例数 9 个；
（2）离线场景：Kafka，8 个集群；
2、遇到的问题
在线场景不足治理：
• 业务混用，互相烦扰，非核心对接积压过多触发集群限流；
• 节点负载不平衡，资源节约重大；
• 资源和利用无关联，音讯积压；
• 业务混用，互相烦扰，非核心对接积压过多触发集群限流；
在线 MQ 集群革新计划
1、选型
（1）业务便捷性：易于开发、应用、保护，提高效率，如自带重试、自带死信、自带事务保障；
（2）性能：容纳业务的不确定性，如抗短时突发流量、抗积压等；
（3）简略：架构实用于拆分小集群；Java 语言易于排查问题和二次开发；社区沉闷，应用的人多，不便排查问题；
2、治理计划
（1）集群划分方针：划分小集群，缩小互相烦扰，缩小影响面；
（2）拆分计划：
如上图所示，对于公司和“钱”相干的业务及外围业务，不仅要给足资源，同时要保障较高的数据安全，在这里就应用了 SYNC_MASTER；
对于非核心业务，咱们心愿它的性价比高，应用尽量少的资源去撑持足够多的数据量，此处就应用了 ASYNC_MASTER，伸缩性会更好；
对于其它数据安全要求不高的业务，包含音讯轨迹，咱们应用单 MASTER 集群，保障了性能须要，资源应用也少；
对于延时集群，专一于积压音讯，pagecache 利用率低，目前还没用做，将来思考在云上采纳按需购买的形式来应用；另外对于长期集群目前也没有波及。
3、管制面治理
（1）对立音讯治理后盾；
对所有消息中间件的后盾做了一个对立的治理后盾，如上图。
（2）对 RabbitMQ，仅保护，主动保护关联关系；
（3）对于 RocketMQ，用于晋升用户体验，比方发送 / 查问音讯、一键接入 demo、死信重发等；
音讯治理界面
配置 demo
死信重发
（4）PaaS 化审批
咱们对音讯化的资源管理做了一个 PaaS 化的治理，对性能做了一些限度，开发和运维只能在测试环境下做申请和审批，审批通过后再同步到其它环境，而后创立资源、告诉用户。
4、对立接入 SDK
（1）用户只关怀用什么资源，不须要理解 namesrv 地址，缩小出错概率；
（2）动静配置热失效，节约用户工夫；
（3）收 / 发消息，失败重试，为中间件做兜底；
（4）熔断限流，为业务做兜底；
（5）灰度收音讯（音讯开关），满足业务非凡场景；
（6）集成公司其余性能，如调用链、全链路压测等；
5、多维度监控
运维：整体状况，cluster 内 top 状况，所属物理机状况；
资源：Topic 上下游 qps，lag 等；
用户：实例音讯收发平均，提早。
老集群迁徙计划
1、人工迁徙
场景：音讯上下游均为本人的服务；
迁徙流程：双收（RocketMQ&RabbitMQ）-> 双发 -> 单发（RocketMQ）-> 单收；
须要留神的问题：业务重构，topic 合并可能导致上游多 tag 音讯歪斜，导致 lag 异样问题；
2、主动迁徙
RabbitMQ <–> RocketMQ 互相镜像迁徙；
粒度: exchange < — > topic；
留神: 雷同组的工作互斥；
（1）RabbitMQ -> RocketMQ 的迁徙计划：
把 RabbitMQ 的 exchange 整体同步到 topic，在 abc.exchange 加一个 topic 前缀为 topic_abc.excange；
把 RabbitMQ 的 Routing key 预设为 RocketMQ 的 tag；
通过 migrator 工作程序收集 RabbitMQ 的音讯队列，依照不同的类型传递到 RocketMQ；
（2）RocketMQ -> RabbitMQ 的迁徙计划：
办法相似，见下图：
（3）主动迁徙的几种状况：
- 消费者迁徙，生产者不动：
配置 RabbitMQ -> RocketMQ 工作；
- 生产者迁徙，消费者不动：
配置 RocketMQ -> RabbitMQ 工作；
- 生产者先不迁徙，而后迁徙了：
先配置 RabbitMQ -> RocketMQ 工作；
迁徙结束后，敞开 RabbitMQ -> RocketMQ 工作；
配置 RocketMQ -> RabbitMQ 工作。
原文链接
本文为阿里云原创内容，未经容许不得转载。
