RocketMQ 在同程旅行的落地实践-六虎

本文作者：刘树东 – 同程艺龙技术专家

01 运用概况

同程游览挑选RocketMQ首要依据以下几个方面的考虑：

技术栈：公司首要以 Java 开发为主，因此咱们倾向于挑选一款用 Java 完成的MQ，且没有任何第三方依赖为最佳；
久经考验：Rocket MQ 阅历了阿里双11考验，功用、稳定性得到了充沛验证；
功用实用：RocketMQ 的发送端供给改了同步、异步、单边、延时发送的功用；消费端有重试行列、死信行列以及音讯重置功用，十分便利实用。

归纳以上三点，咱们挑选了 Rocket MQ。

Rocket MQ 在同程游览的运用场景有削峰、解耦、异步处理以及数据同步等。现在现已在公司各大事务线的核心体系里得到广泛运用，承受了来自微信进口的巨大流量，每天有1000+ 亿条音讯周转。

同程游览RocketMQ 框架图如上。机票、交通和酒店三大事务线经过 Java SDK 以及Http Proxy 的方法接入到 MQ 集群。其间Http Proxy 首要为了便利其他言语客户端运用；一起为了更好地完成资源阻隔，咱们将后端服务端节点依照事务线做了物理阻隔，能够最大程度地确保事务线之间不会相互影响。整个 MQ 集群经过 MQ 服务平台进行管理。

02 同城双中心

同城双中心首要为完成以下三个目标：

单机放毛病时确保事务可用
确保数据牢靠
横向扩容

外部用户恳求经过 LVS 以及 Nginx 调用服务与运用，运用底层首要调用了 MySQL、Redis 以及 MQ，双中心可分为同城冷备和同城双活两个计划。

同城冷备有两个 MQ 集群，分别是 source 集群和target 集群。出产者会将音讯出产到 source 集群，之后经过音讯同步集群将 source 集群里的元数据比方 topic、消费组、音讯等同步给 target 集群。source 集群和 target 集群中的顾客都能够进行消费。

同城双活咱们建立了跨中心的全局 MQ 集群。用户流量分散到两个中心，每个事务会将出产的音讯往自己中心的 MQ 写。一起，其他服务与运用会从本中心消费所需音讯。

当呈现单机房 broker 节点毛病时，每组 broker 的两 slave 位于不同机房，至少有一台 slave 具有近乎全量的数据；音讯出产会跨机房到另一个机房，另一个机房的顾客继续消费。

简略对比下，同城冷备计划需求 source 和target 两个集群，因此资源运用率不高，还需求同步 topic 、消费组、消费进展等元数据；同城双活计划资源运用比较合理，事务流量在何处，就在该处进行出产与消费音讯。

同城双活有以下三点诉求：

①就近出产：出产端在A机房，则出产的音讯也存于A机房的 broker。

②就近顾客：顾客在A机房，则顾客音讯也来自A机房的 broker。

③broker 主节点毛病，能够完成主动的选主。

就近出产与就近消费的核心问题是如何识别客户端与服务端是否在同一机房。识别客户端地点机房能够经过两个途径：

榜首，获取客户端地点IP，然后经过第三方组件解析出 IP 所属机房；

第二，与运维人员合作，在每一台容器或物理机里设置环境变量，经过读取环境变量来感知客户端地点机房。比方从环境变量里读取到逻辑机房的 ID或逻辑机房的名称。

识别服务端机房有三种途径：

榜首，经过 IP 查询，解析IP 段归于哪个机房；

第二，服务端节点向元数据节点注册时，在协议层增加机房标识；

第三，在 broker 名字上增加机房标识。

就近出产的准则：优先就近出产，就近出产无法满意时则跨机房出产。

假如机房后端的服务节点可用，则出产端会将音讯出产到各自的机房里。假如机房的一切 broker节点都不可用，则出产端会将音讯投递到另一个中心的 broker。

两个机房消费端都正常的状况下，每个机房的消费端只会消费本机房的音讯。

如上图，假如idc 2 的消费端悉数毛病，则一切音讯会被另一个机房idc1的消费端消费。

为了完成就近消费，咱们完成了按机房分配行列算法：

每个机房的音讯会平均分给此机房的消费端；

假如机房没有消费端，则音讯会平均分配给其他机房的消费端。

毛病切主的完成步骤如下：

榜首步：Nameserver 依据 raft 协议选主；

第二步：一切 broker 向 Nameserver leader 节点注册，leader 节点将 broker 的注册信息同步给其他 Nameserver 节点；

第三步：broker主节点呈现异常时，由Nameserver 担任从剩下的 broker节点里重新选主节点；

第四步：此时出产端无法向旧broker leader发送音讯。假如旧 broker的主节点复生，则会主动切换成从节点。

Nameserver 元数据体系有一主多从，broker 有一台 master 与两台 slave。假如 master 毛病，则 Nameserver 元数据体系会从 slave1 与 slave2 中依据必定的条件，比方依据同步进展或版别号选出新主，上图为将 slave2 选为主。之后新主会向 nameserver 元数据体系注册，并将版别号+1。假如旧主复生，因会其版别号小于新主版别号被切为 slave。

在出产环境中实践操作了双中心演练，详细流程如下：

1）14:30开端切域名，将流量切到一个机房（二中心）。三四分钟后，二中心的流量已超越一中心，一中心的流量趋近于零；

2）15:00左右，将流量回归双中心；

3）15:30左右，又将流量切回一中心。能够清晰地看到，在流量切到一中心时，二中心的音讯出产趋近于0。

整体来看，双中心的演练较成功，完成了音讯的出产跟着流量走。

简略总结下，双中心计划为跨机房建立了全局MQ集群，出产与消费都恪守优先就近准则，装备一主二从，一主一从音讯写成功即认为音讯写入成功。Nameserver 经过 Raft 协议选主，选完主后会监控每一组里 broker 的 leader 节点。假如 broker 的 leader 节点呈现毛病，则会从这一组剩下的 slave 里选新的主节点。

03 平台管理

平台管理至关重要，能够让环境变得愈加稳定牢靠，呈现异常时能够及时向运用方宣布告警，呈现毛病时能够快速定位。MQ 的平台管理分为主题消费组管理、客户端管理以及服务端管理。