高朋李样兵，现就职于美菜网根本做事平台组，卖力 MQ ，配置中央和任务调度等根本组件开拓事情。
今天主要从三个方面进行分享：
美菜网历史上是多套 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 ，配置中央和任务调度等根本组件开拓事情。
本文为云栖社区原创内容，未经许可不得转载。
