本文作者：刘树东 – 同程艺龙技术专家
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。
每个机房的音讯会平均分给此机房的消费端；
假如机房没有消费端，则音讯会平均分配给其他机房的消费端。
毛病切主的完成步骤如下：
榜首步：Nameserver 依据 raft 协议选主；
第二步：一切 broker 向 Nameserver leader 节点注册，leader 节点将 broker 的注册信息同步给其他 Nameserver 节点；
第三步：broker主节点呈现异常时，由Nameserver 担任从剩下的 broker节点里重新选主节点；
第四步：此时出产端无法向旧broker leader发送音讯。假如旧 broker的主节点复生，则会主动切换成从节点。
1）14:30开端切域名，将流量切到一个机房（二中心）。三四分钟后，二中心的流量已超越一中心，一中心的流量趋近于零；
3）15:30左右，又将流量切回一中心。能够清晰地看到，在流量切到一中心时，二中心的音讯出产趋近于0。
整体来看，双中心的演练较成功，完成了音讯的出产跟着流量走。
03 平台管理
平台管理至关重要，能够让环境变得愈加稳定牢靠，呈现异常时能够及时向运用方宣布告警，呈现毛病时能够快速定位。MQ 的平台管理分为主题消费组管理、客户端管理以及服务端管理。
音讯堆积到必定阈值时，能够向事务方宣布告警，告诉其处理；长期不处理能够撤销消费组的消费权限或重置消费进展，避免因音讯大量堆积而影响出产与消费。若消费端节点掉线必定时刻之后没有重新上线，可向事务方快速发布告警，告诉其及时处理。
这一系列的计算和检测终究需求为音讯的全链路追踪服务。计算和检测会记录音讯相关信息，包含每一条音讯在哪个时刻点、从哪个事务IP与端口号发送到服务端的哪个节点、于什么时刻被哪些服务的消费端在什么时刻点消费，以及消费耗时、消费的重复次数等信息，能够很便利地排查所需信息。
经过几张图展现下实践的管理，在 MQ 服务平台上，能够请求 topic 和消费组的上线、下线以及权限。
1）做双中心版别升级时，没有考虑到版别的向下兼容，行列的分配算法有问题，导致部分音讯被重复消费多次，部分音讯没有被消费；
2）某一台 broker上主题消费组数量过多时，会导致 Nameserver 注册耗时过长。假如很多 broker 上的主题消费组都很多，就会导致broker的内存 OOM；
3）由于 topic 长度判别不一致导致服务端重启时会丢失少数音讯；
4）broker 进程会假死，后证实为os版别问题，升级os版别即可解决。
04 未来展望
同程游览针对 RocketMQ 的未来规划分为以下三个方面：
榜首，前史数据归档。很多事务方对数据的反查要求周期较长，而线上出产环境的音讯实践的存储时刻可能只要2-3天，咱们将考虑从前史归档数据里查询；
第二，底层存储剥离，计算与存储别离。现在社区新版别现已支持该能力；
第三，期望利用沉积的前史数据协助事务完成更多数据猜测，比方订单量、退改量等数据的猜测能够更好地协助事务解决问题，一起也能够为事务机器做扩缩容供给支持。
参加 Apache RocketMQ 社区
十年铸剑，Apache RocketMQ 的成长离不开全球接近 500 位开发者的积极参与奉献，相信在下个版别你就是 Apache RocketMQ 的奉献者，在社区不仅能够结识社区大牛，提升技术水平，也能够提升个人影响力，促进自身成长。
社区 5.0 版别正在进行着如火如荼的开发，另外还有接近 30 个 SIG（兴趣小组）等你参加，欢迎立志打造世界级分布式体系的同学参加社区，增加社区开发者微信：rocketmq666 即可进群，参与奉献，打造下一代音讯、事情、流交融处理平台。
微信扫码增加小火箭进群
另外还能够参加钉钉群与 RocketMQ 爱好者一起广泛讨论：
钉钉扫码加群
