基于 RocketMQ 的同城双活架构在美菜网的挑战与实践

本文整理自李样兵在北京站 RocketMQ meetup分享美菜网使用 RocketMQ 过程当中的一些心得和经验，偏重于实践。

嘉宾李样兵，现就任于美菜网基础服务平台组，负责 MQ ，配置中心和任务调度等基础组件开发工做。

今天主要从三个方面进行分享：

• 美菜网消息队列的历史
• 基于 RocketMQ 咱们作了那些事情
• 同城双活的选型和思考

美菜网消息队列的历史

美菜网历史上是多套 MQ 并存，Kafka 用于大数据团队；NSQ 和 RocketMQ 用于线上业务。

多套集群存在的问题：

一、维护和资源成本高昂：Kafka 用 Scala 语言， NSQ 用 GO 语言， RocketMQ 用 Java 语言，维护成本较高，每套 MQ 不论消息量多少，至少部署一套，资源成本较高。

二、易用性较差：三套 MQ 基本上都是开箱直接使用，二次开发比较少，业务接入不方便，使用混乱。消费者接入时，须要知道 topic 在那套集群上，使用哪一种客户端接入。

三、可靠性：比较了一下 RocketMQ 和 NSQ 内置的复制机制。NSQ 多通道之间是复制的，可是其自己是单副本的，存在消息丢失的风险。

统一集群的选型比较：

一、功能性，核心的功能每一个 MQ 都有，考虑更多的是附加功能，好比延迟消息、顺序消息、事务消息，还有就是消息的回溯、基于 key 的检索。

二、可靠性， RocketMQ 就像前面几位老师说的，有多种刷盘和同步机制，能够结合本身的需求灵活配置，美菜网用了 2 年多时间，表现一直比较稳定。

三、技术栈的匹配，公司是以 java 语言为主，php 为辅。

四、社区完备性来讲， RocketMQ 社区是比较活跃的，并且支持也是比较到位。

能够经过微信、钉钉、邮件，还有像今天这样的线下沙龙，这也是咱们考虑的一个很是重要的点。

统一集群的迁移方案：

一、协议的兼容， RocketMQ TCP 协议，对 java 原生支持，仅需依赖一个 jar 就能够进行使用了， NSQ 使 http 协议。

二、业务的无感，迁移过程当中，解耦生产者和消费者迁移，实现平滑的迁移。

三、消息不丢失，迁移过程当中消息必然是不能丢失消息的，很容易理解。咱们来看下图，这个是咱们当时迁移时的解决方案。

 

左边是 Producer ，业务经过 Http 链接 NSQ ，对于生产者，实现一个 http 网关，来接收业务生产消息转发到 RocketMQ 。对于消费者，实现一个 transfer 的工具，将消息透传到 NSQ ，这样对消费端是无感的，生产端完成迁移了，消费者能够逐步的往 RocketMQ 上迁移了，因此整个迁移过程仍是比较顺利的。

基于RocketMQ咱们作了那些事情

诉求：

一、多语言支持，前面已经提到了美菜网的技术栈以 Java 语言为主，还有 php ， go , python 语言等。

二、易用性，业务接入快捷，方便。

三、稳定性，保证整个平台的稳定可靠。

多语言的支持：

 

生产处理器，提供 HTTP 协议消息生产支持；消费处理器，消费端的网关，不断从 RocketMQ 拉取消息，经过 http 发送到消费端client；流量调度器，根据 topic 的 SLA 作路由、流量调度。

易用性：

主要是从业务使用角度，下降业务的接入成本，提升业务接入的效率。

一、自定义 SDK ，同时定义了一个 spring 标签库，使用起来简单。

二、加入了一些 trace ，指标采集功能，对消息积压和失败的报警。

三、消息轨迹，消息从生产到 broker ，再到消费有一个完整的能够追踪的功能，这样出现了问题就能够很容易的排查，防止出现生产者说发了消息，消费者说没有收到消息的相互扯皮的问题。

四、失败消息补发， RocketMQ 是有失败重试机制的，失败消息会进行 16 的失败重试，最终到死信队列中，再也不投递。可能业务系统出现了故障，通过较长一段时间的解决，解决以后但愿消息能够从新发送。

 

 

稳定性：

一、集群隔离，咱们会按照 SLA 隔离出业务集群、日志集群、计算集群。业务集群采用的主从同步，同步落盘，计算集群采用主从异步，异步落盘，日志集群就是单主结构

 

二、完善故障预案

节点故障，快速下线，一键扩容。

主节点挂掉，从节点提高为主节点，主节点改成只读。

三、完善监控报警机制

生产延迟， TPS ， TP99 多维度指标数据

 

同城双活的选型和思考

背景：

一、保证数据可靠性，若是全部数据都在一个机房，一旦这个机房出了问题，数据有丢失的风险。

二、机房的扩容，单机房毕竟容量有限，多个机房能够分担流量。

方案选型：

一、同城冷备，备用一套服务存在但不对外提供服务，当另外一套服务有问题时进行切换，可是真的出了问题，咱们是否敢切流量呢？

二、同城双活，平时就是双机房对外提供服务，出问题的时候切掉故障机房，真正实现容灾的目的。

几点诉求：

一、机房就近，生产者在a机房，生产后的数据也在 a 机房的 broker ；消费者在b机房，消费的消息也来自 b 机房 broker 。

二、应用平滑迁移，支持按 topic ，应用逐步迁移。

三、故障的快速切换。

几个关键点：

 

就近识别算法：

一、 IP 段的方式，不一样的 IP 段表示不一样的机房，该方案对公司网络要求较高，公司网络调整，也须要修改修改算法，升级客户端。

二、协议层增长机房标识，在生产和消费的 client 通讯的时候都添加上所在机房标识，改动成本较高。

三、 broker 名字增长机房标识，客户端 clientID 增长机房标识，该方案改动成本较低，对 MQ 核心功能无入侵。

数据复制：

实现主-从-从结构，基于 slave 异步复制，减轻 master 节点的压力。

故障预案：

机房或链路出现问题时。须要关闭一层机房的写权限。

机房接入层故障，无影响。

咱们接下来要作的事情

一、大规模集群化的运维。目前的状况下，当大规模集群须要运维的时候是很棘手的，若是实现真正的无人值守的就会好不少。

二、按 SLA 进行自动 topic 路由调整。目前这个须要咱们和业务方去提早沟通确认好，人工来调整，将来指望能够自动调整。

本文做者：李样兵， 2012 年研究生毕业， 2016 年加入美菜，现就任于美菜网基础服务平台组，负责 MQ ，配置中心和任务调度等基础组件开发工做。

原文连接

本文为云栖社区原创内容，未经容许不得转载。