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

南楼画角 提交于 2019-11-29 19:11:41

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

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

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

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

美菜网消息队列的历史

美菜网历史上是多套 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 ,配置中心和任务调度等基础组件开发工作。

本文作者:中间件小哥

原文链接

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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!