基于 RocketMQ 的同城双活架构在美菜网的挑战与实践
source link: https://www.tuicool.com/articles/neA3Ijq
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
美菜网消息队列的历史
美菜网历史上是多套 MQ 并存，Kafka 用于大数据团队；NSQ 和 RocketMQ 用于线上业务。
多套集群存在的问题：
1、维护和资源成本高昂：Kafka 用 Scala 语言， NSQ 用 GO 语言， RocketMQ 用 Java 语言，维护成本较高，每套 MQ 不论消息量多少，至少部署一套，资源成本较高。
2、易用性较差：三套 MQ 基本上都是开箱直接使用，二次开发比较少，业务接入不方便，使用混乱。消费者接入时，需要知道 topic 在那套集群上，使用哪种客户端接入。
3、可靠性：比较了一下 RocketMQ 和 NSQ 内置的复制机制。NSQ 多通道之间是复制的，但是其本身是单副本的，存在消息丢失的风险。
统一集群的选型比较：
1、功能性，核心的功能每个 MQ 都有，考虑更多的是附加功能，比如延迟消息、顺序消息、事务消息，还有就是消息的回溯、基于 key 的检索。
2、可靠性， RocketMQ 就像前面几位老师说的，有多种刷盘和同步机制，可以结合自己的需求灵活配置，美菜网用了 2 年多时间，表现一直比较稳定。
3、技术栈的匹配，公司是以 java 语言为主，php 为辅。
4、社区完备性来说， RocketMQ 社区是比较活跃的，而且支持也是比较到位。
可以通过微信、钉钉、邮件，还有像今天这样的线下沙龙，这也是我们考虑的一个非常重要的点。
统一集群的迁移方案：
1、协议的兼容， RocketMQ TCP 协议，对 java 原生支持，仅需依赖一个 jar 就可以进行使用了， NSQ 使 http 协议。
2、业务的无感，迁移过程中，解耦生产者和消费者迁移，实现平滑的迁移。
3、消息不丢失，迁移过程中消息必然是不能丢失消息的，很容易理解。我们来看下图，这个是我们当时迁移时的解决方案。
左边是 Producer ，业务通过 Http 连接 NSQ ，对于生产者，实现一个 http 网关，来接收业务生产消息转发到 RocketMQ 。对于消费者，实现一个 transfer 的工具，将消息透传到 NSQ ，这样对消费端是无感的，生产端完成迁移了，消费者可以逐步的往 RocketMQ 上迁移了，所以整个迁移过程还是比较顺利的。
基于 RocketMQ 我们做了那些事情
诉求：
1、多语言支持，前面已经提到了美菜网的技术栈以 Java 语言为主，还有 php ， go , python 语言等。
2、易用性，业务接入快捷，方便。
3、稳定性，保证整个平台的稳定可靠。
多语言的支持：
生产处理器，提供 HTTP 协议消息生产支持；消费处理器，消费端的网关，不断从 RocketMQ 拉取消息，通过 http 发送到消费端 client；流量调度器，根据 topic 的 SLA 做路由、流量调度。
易用性：
主要是从业务使用角度，降低业务的接入成本，提高业务接入的效率。
1、自定义 SDK ，同时定义了一个 spring 标签库，使用起来简单。
2、加入了一些 trace ，指标采集功能，对消息积压和失败的报警。
3、消息轨迹，消息从生产到 broker ，再到消费有一个完整的可以追踪的功能，这样出现了问题就可以很容易的排查，防止出现生产者说发了消息，消费者说没有收到消息的相互扯皮的问题。
4、失败消息补发， RocketMQ 是有失败重试机制的，失败消息会进行 16 的失败重试，最终到死信队列中，不再投递。可能业务系统出现了故障，经过较长一段时间的解决，解决之后希望消息可以重新发送。
稳定性：
1、集群隔离，我们会按照 SLA 隔离出业务集群、日志集群、计算集群。业务集群采用的主从同步，同步落盘，计算集群采用主从异步，异步落盘，日志集群就是单主结构
2、完善故障预案
- 节点故障，快速下线，一键扩容。
- 主节点挂掉，从节点提升为主节点，主节点改为只读。
3、完善监控报警机制
- 生产延迟， TPS ， TP99 多维度指标数据
同城双活的选型和思考
背景：
1、保证数据可靠性，如果所有数据都在一个机房，一旦这个机房出了问题，数据有丢失的风险。
2、机房的扩容，单机房毕竟容量有限，多个机房可以分担流量。
方案选型：
1、同城冷备，备用一套服务存在但不对外提供服务，当另一套服务有问题时进行切换，但是真的出了问题，我们是否敢切流量呢？
2、同城双活，平时就是双机房对外提供服务，出问题的时候切掉故障机房，真正实现容灾的目的。
几点诉求：
1、机房就近，生产者在 a 机房，生产后的数据也在 a 机房的 broker ；消费者在 b 机房，消费的消息也来自 b 机房 broker 。
2、应用平滑迁移，支持按 topic ，应用逐步迁移。
3、故障的快速切换。
几个关键点：
就近识别算法：
1、 IP 段的方式，不同的 IP 段表示不同的机房，该方案对公司网络要求较高，公司网络调整，也需要修改修改算法，升级客户端。
2、协议层增加机房标识，在生产和消费的 client 通信的时候都添加上所在机房标识，改动成本较高。
3、 broker 名字增加机房标识，客户端 clientID 增加机房标识，该方案改动成本较低，对 MQ 核心功能无入侵。
数据复制：
实现主 - 从 - 从结构，基于 slave 异步复制，减轻 master 节点的压力。
故障预案：
机房或链路出现问题时。需要关闭一层机房的写权限。
机房接入层故障，无影响。
我们接下来要做的事情
1、大规模集群化的运维。目前的情况下，当大规模集群需要运维的时候是很棘手的，如果实现真正的无人值守的就会好很多。
2、按 SLA 进行自动 topic 路由调整。目前这个需要我们和业务方去提前沟通确认好，人工来调整，未来期望可以自动调整。
作者介绍：
李样兵， 2012 年研究生毕业， 2016 年加入美菜，现就职于美菜网基础服务平台组，负责 MQ ，配置中心和任务调度等基础组件开发工作。
本文转载自公众号阿里巴巴中间件（ID：Aliware_2018）。
原文链接：
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK