同程旅行基于 RocketMQ 高可用架构实践 冷不防 2022-10-11 14:54 246阅读 0赞 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center] # 背景介绍 # ## 为何选择 RocketMQ ## 我们在几年前决定引入 MQ 时,市场上已经有不少成熟的解决方案,比如 RabbitMQ , ActiveMQ,NSQ,Kafka 等。考虑到稳定性、维护成本、公司技术栈等因素,我们选择了 RocketMQ : * 纯 Java 开发,无依赖,使用简单,出现问题能 hold ; * 经过阿里双十一考验,性能、稳定性可以保障; * 功能实用,发送端:同步、异步、单边、延时发送;消费端:消息重置,重试队列,死信队列; * 社区活跃,出问题能及时沟通解决。 ## 使用情况 ## * 主要用于削峰、解耦、异步处理; * 已在火车票、机票、酒店等核心业务广泛使用,扛住巨大的微信入口流量; * 在支付、订单、出票、数据同步等核心流程广泛使用; * 每天 1000+ 亿条消息周转。 下图是 MQ 接入框架图 由于公司技术栈原因,client sdk 我们提供了 java sdk ;对于其他语言,收敛到 http proxy ,屏蔽语言细节,节约维护成本。按照各大业务线,对后端存储节点进行了隔离,相互不影响。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 1] # MQ 双中心改造 # 之前单机房出现过网络故障,对业务影响较大。为保障业务高可用,同城双中心改造提上了日程。 ## 为何做双中心 ## * 单机房故障业务可用; * 保证数据可靠:若所有数据都在一个机房,一旦机房故障,数据有丢失风险; * 横向扩容:单机房容量有限,多机房可分担流量。 ## 双中心方案 ## 做双中心之前,对同城双中心方案作了些调研,主要有冷(热)备份、双活两种。(当时社区 Dledger 版本还没出现,Dledger 版本完全可做为双中心的一种可选方案。) 1)同城冷(热)备份 两个独立的 MQ 集群, 用户流量写到一个主集群,数据实时同步到备用集群,社区有成熟的 RocketMQ Replicator 方案,需要定期同步元数据,比如主题,消费组,消费进度等。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 2] 2)同城双活 两个独立 MQ 集群,用户流量写到各自机房的 MQ 集群,数据相互不同步。 平时业务写入各自机房的 MQ 集群,若一个机房挂了,可以将用户请求流量全部切到另一个机房,消息也会生产到另一个机房。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 3] 对于双活方案,需要解决 MQ 集群域名。 1)若两个集群用一个域名,域名可以动态解析到各自机房。此方式要求生产、消费必须在同一个机房。假如生产在 idc1 ,消费在 idc2 ,这样生产、消费各自连接一个集群,没法消费数据。 2)若一个集群一个域名,业务方改动较大,我们之前对外服务的集群是单中心部署的,业务方已经大量接入,此方案推广较困难。 为尽可能减少业务方改动,域名只能继续使用之前的域名,最终我们采用一个 Global MQ 集群,跨双机房,无论业务是单中心部署还是双中心部署都不影响;而且只要升级客户端即可,无需改动任何代码。 ## 双中心诉求 ## * 就近原则:生产者在 A 机房,生产的消息存于 A 机房 broker ; 消费者在 A 机房,消费的消息来自 A 机房 broker 。 * 单机房故障:生产正常,消息不丢。 * broker 主节点故障:自动选主。 ## 就近原则 ## 简单说,就是确定两件事: * 节点(客户端节点,服务端节点)如何判断自己在哪个 idc; * 客户端节点如何判断服务端节点在哪个 idc。 **如何判断自己在哪个 idc?** **** 1. ip 查询 节点启动时可以获取自身 ip ,通过公司内部的组件查询所在的机房。 2)环境感知 需要与运维同学一起配合,在节点装机时,将自身的一些元数据,比如机房信息等写入本地配置文件,启动时直接读写配置文件即可。 我们采用了第二个方案,无组件依赖,配置文件中 logicIdcUK 的值为机房标志。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 4] **客户端节点如何识别在同一个机房的服务端节点?** **** 客户端节点可以拿到服务端节点的 ip 以及 broker 名称的,因此: * ip 查询:通过公司内部组件查询 ip 所在机房信息; * broker 名称增加机房信息:在配置文件中,将机房信息添加到 broker 名称上; * 协议层增加机房标识:服务端节点向元数据系统注册时,将自身的机房信息一起注册。 相对于前两者,实现起来略复杂,改动了协议层, 我们采用了第二种与第三种结合的方式。 ## 就近生产 ## 基于上述分析,就近生产思路很清晰,默认优先本机房就近生产; 若本机房的服务节点不可用,可以尝试扩机房生产,业务可以根据实际需要具体配置。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 5] ## 就近消费 ## 优先本机房消费,默认情况下又要保证所有消息能被消费。 队列分配算法采用按机房分配队列 * 每个机房消息平均分给此机房消费端; * 此机房没消费端,平分给其他机房消费端。 伪代码如下: 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为当前客户端 } 消费场景主要是消费端单边部署与双边部署。 单边部署时,消费端默认会拉取每个机房的所有消息。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 6] 双边部署时,消费端只会消费自己所在机房的消息,要注意每个机房的实际生产量与消费端的数量,防止出现某一个机房消费端过少。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 7] ## 单机房故障 ## * 每组 broker 配置 一主两从,一主一从在一机房,一从在另一机房;某一从同步完消息,消息即发送成功。 * 单机房故障 消息生产跨机房;未消费消息在另一机房继续被消费。 ## 故障切主 ## 在某一组 broker 主节点出现故障时,为保障整个集群的可用性,需要在 slave 中选主并切换。要做到这一点,首先得有个broker 主故障的仲裁系统,即 nameserver(以下简称 ns )元数据系统(类似于 redis 中的哨兵)。 ns 元数据系统中的节点位于三个机房(有一个第三方的云机房,在云上部署 ns 节点,元数据量不大,延时可以接受),三个机房的 ns 节点通过 raft 协议选一个leader,broker 节点会将元数据同步给 leader, leader 在将元数据同步给 follower 。 客户端节点获取元数据时, 从 leader,follower 中均可读取数据。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 8] ### 切主流程 ### **** * 若 nameserver leader 监控到 broker 主节点异常, 并要求其他 follower 确认;半数 follower 认为 broker 节点异常,则 leader 通知在 broker 从节点中选主,同步进度大的从节点选为主; * 新选举的 broker 主节点执行切换动作并注册到元数据系统; * 生产端无法向旧 broker 主节点发送消息。 流程图如下 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 9] **切中心演练** **** 用户请求负载到双中心,下面的操作先将流量切到二中心—回归双中心—切到一中心。确保每个中心均可承担全量用户请求。 先将用户流量全部切到二中心 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 10] 流量回归双中心,并切到一中心 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 11] **回顾** * 全局 Global 集群 * 就近原则 * 一主二从,写过半消息即及写入成功 * 元数据系统 raft 选主 * broker 主节点故障,自动选主 # MQ 平台治理 # 即使系统高性能、高可用,倘若随便使用或使用不规范,也会带来各种各样的问题,增加了不必要的维护成本,因此必要的治理手段不可或缺。 ## 目的 ## 让系统更稳定 * 及时告警 * 快速定位、止损 ## 治理哪些方面 ## **主题/消费组治理** **** * 申请使用 生产环境 MQ 集群,我们关闭了自动创建主题与消费组,使用前需要先申请并记录主题与消费组的项目标识与使用人。一旦出现问题,我们能够立即找到主题与消费组的负责人,了解相关情况。若存在测试,灰度,生产等多套环境,可以一次申请多个集群同时生效的方式,避免逐个集群申请的麻烦。 * 生产速度 为避免业务疏忽发送大量无用的消息,有必要在服务端对主题生产速度进行流控,避免这个主题挤占其他主题的处理资源。 * 消息积压 对消息堆积敏感的消费组,使用方可设置消息堆积数量的阈值以及报警方式,超过这个阈值,立即通知使用方;亦可设置消息堆积时间的阈值,超过一段时间没被消费,立即通知使用方。 * 消费节点掉线 消费节点下线或一段时间无响应,需要通知给使用方。 **客户端治理** **** * 发送、消费耗时检测 监控发送/消费一条消息的耗时,检测出性能过低的应用,通知使用方着手改造以提升性能;同时监控消息体大小,对消息体大小平均超过 10 KB 的项目,推动项目启用压缩或消息重构,将消息体控制在 10 KB 以内。 * 消息链路追踪 一条消息由哪个 ip 、在哪个时间点发送,又由哪些 ip 、在哪个时间点消费,再加上服务端统计的消息接收、消息推送的信息,构成了一条简单的消息链路追踪,将消息的生命周期串联起来,使用方可通过查询msgId或事先设置的 key 查看消息、排查问题。 * 过低或有隐患版本检测 随着功能的不断迭代,sdk 版本也会升级并可能引入风险。定时上报 sdk 版本,推动使用方升级有问题或过低的版本。 **服务端治理** **** * 集群健康巡检 如何判断一个集群是健康的?定时检测集群中节点数量、集群写入 tps 、消费 tps ,并模拟用户生产、消费消息。 * 集群性能巡检 性能指标最终反映在处理消息生产与消费的时间上。服务端统计处理每个生产、消费请求的时间,一个统计周期内,若存在一定比例的消息处理时间过长,则认为这个节点性能有问题;引起性能问题的原因主要是系统物理瓶颈,比如磁盘 io util 使用率过高,cpu load 高等,这些硬件指标通过夜鹰监控系统自动报警。 * 集群高可用 高可用主要针对 broker 中 master 节点由于软硬件故障无法正常工作,slave 节点自动被切换为 master ,适合消息顺序、集群完整性有要求的场景。 **部分后台操作展示** 主题与消费组申请 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 12] 生产,消费,堆积实时统计 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 13] 集群监控![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 14] **踩过的坑** **** 社区对 MQ 系统经历了长时间的改进与沉淀,我们在使用过程中也到过一些问题,要求我们能从深入了解源码,做到出现问题心不慌,快速止损。 * 新老消费端并存时,我们实现的队列分配算法不兼容,做到兼容即可; * 主题、消费组数量多,注册耗时过长,内存 oom ,通过压缩缩短注册时间,社区已修复; * topic 长度判断不一致,导致重启丢消息,社区已修复; * centos 6.6 版本中,broker 进程假死,升级 os 版本即可。 ### **MQ 未来展望** ### 目前消息保留时间较短,不方便对问题排查以及数据预测,我们接下来将对历史消息进行归档以及基于此的数据预测。 * 历史数据归档 * 底层存储剥离,计算与存储分离 * 基于历史数据,完成更多数据预测 * 服务端升级到 Dledger ,确保消息的严格一致 了解更多 RocketMQ 信息,可加入社区交流群,下面是钉钉群,欢迎大家加群留言。 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 15] [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center]: /images/20221005/d8a4be5fc42248f48d98d8b0ce3e571b.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221005/661852c0f0114d10a6229443d8b3c10c.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221005/70c66f0a4a10471fa21be503df808e66.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221005/5d40acfa7a174644967786fb81faf4cf.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221005/cd3a4d59cbb24373a5cc9356e3613379.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221005/26546c6daf554a688ce17d286e75df3d.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221005/3899b479770d433a832102eadbafcd5e.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221005/8b6f6ecd3127418e936870b2b5a388ec.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221005/3333b27b7d4946d394e27cc57bafaffb.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221005/33b8b8264337460d8ce7d02513165c82.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221005/e3361854756c41cfa0dc0e4089a01730.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20221005/965b634093b94aa48793d39b2decc82d.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 12]: /images/20221005/4cddac9d22114e2bb031f13c08a14185.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 13]: /images/20221005/4372fabbf4b3426484e411378a5aabe6.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 14]: /images/20221005/f8b28282906644aaaeba4e9e2549e661.png [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsaXN5c3RlbXNvZnR3YXJl_size_16_color_FFFFFF_t_70_pic_center 15]: /images/20221005/46c66c61a66e41c0a79b3716afd4bf24.png
还没有评论,来说两句吧...