鲸品堂｜WhaleDI消息队列稳定性提升实践

2022-07-18 29

互联网电商企业中，其业务功能可能包含注册、订单、库存、物流......同时在这些业务过程中会涉及许多峰值时刻，如秒杀活动、周年庆、定期特惠等。这些活动都对分布性系统中的各项微服务应用的稳定性和处理性能带来很大的挑战，以最基础的注册流程为例：

传统处理方法

用户注册后，一般系统需要发送注册邮件和短信通知，以告知用户注册成功。通常的做法为：

只有以上三个任务(注册+邮件通知+短信通知)全部完成后，才返回注册结果到客户端，用户才能使用账号登录。假设每个任务耗时分别为50ms，则用户需要在注册页面等待总共150ms才能登录。

同时由于注册系统强依赖于邮件和短信发送系统，一旦发送系统异常，注册系统将受到连锁影响，降低了系统的可用性。

使用了消息队列的异步解耦的处理方法

对于用户来说，注册功能实际只需要注册系统存储用户的账户信息后，该用户便可以登录，后续的注册短信和邮件不是即时需要关注的步骤。

对于注册系统而言，发送注册成功的短信和邮件通知并不一定要绑定在一起同步完成，所以实际当数据写入注册系统后，注册系统就可以把其他的操作放入对应的消息队列中然后马上返回用户结果，由消息队列MQ异步地进行这些操作。

由此，用户只需在注册页面等待注册数据写入注册系统和消息队列的时间，等待55ms即可登录。同时注册流程也不会受邮件系统和短信系统的可用性影响，从而提升了整体的稳定性。

稳定性提升实践

消息队列的应用场景非常丰富，在支持顺序消息、事务消息、延时消息，在削峰填谷、海量消息存储等方面都能起到重要的作用。但是往往越底层的应用，其稳定性要求也越高，作为应用之间连接的桥梁，一旦消息队列发生故障，整个业务系统都可能会瘫痪。

首先看下WhaleDI-MQ的高可用部署架构，其包含服务端组件和客户端组件两大部分，其中服务端组件包含Namesrv、Broker和Zookeeper，客户端组件包含生产组producer和消费者Consumer，架构如下图所示：

Namesrv为无状态服务，是WhaleDI-MQ的注册中心，用于收集和更新路由信息；WhaleDI-MQ通过部署多个Namesrv节点保障高可用，当一个Namesrv异常退出后，客户端能够自动重连到其他的Namesrv节点。

Broker为实际对外提供消息发送和消费服务的节点，消息会轮询发送到各个主节点Broker中，主备之间通过同步双写保障数据的可靠性；单个Broker master节点异常时，备节点会自动切换为master节点，继续提供服务；当一组Broker的master、slave节点全部异常时，其他的Broker节点仍然可以提供服务，保证了服务的可用性。

WhaleDI-MQ利用ZK特性监控Broker的主备状态，实现了Broker的自动切换功能。Zookeeper自身采用多节点（奇数个）部署的方式，利用ZAB协议特性保证自身组件的高可用。

Producer为生产者客户端，采用多节点集群部署模式，具备极强的扩展能力，某个Producer异常，不影响其它Producer节点发送消息。

Consumer为消费者客户端，和Producer一样采用多节点集群部署模式，当某个Consumer节点异常时，WhaleDI-MQ根据负载策略动态再平衡，重新调整队列路由。

下面，我们将从Namesrv、Broker、异地容灾等几个方面给大家讲解稳定性提升实践。

Namesrv稳定性提升

Namesrv是Rocketmq的无状态注册服务，主要作用为：

作为Broker的注册中心，维护Broker的服务地址和路由信息
客户端通过Namesrv获取以及更新路由信息

Rocketmq是通过部署多个Namesrv节点来保证高可用，每个Namesrv的节点维护的数据都是相同的，客户端初始化时仅会选择其中的一个Namesrv节点建立网络链接，若建链失败，则根据异常条件重新选择其他的Namesrv节点。

>>>>

故障场景：

若连接的Namesrv节点cpu hang死，由于客户端已经和故障的Namesrv节点建立连接，因而不会再选择其他的Namesrv节点连接，由于当前的Namesrv故障，导致后续的路由更新、状态通知等全部超时失败，进而无法进行正常发送和消费消息，导致业务应用异常。

>>>>

解决方案：

WhaleDI-MQ增加了Namesrv链接自我检测机制，对于netty异常链接定期检测，若发现链接不可用则进行异常断链，重新选择其他的Namesrv进行连接。

>>>>

应用成果：

即便客户端已经和故障的Namesrv节点建立了连接，但是若后续的路由获取、心跳上报等服务在一定时间内异常次数超过阈值，客户端依然会和当前的故障节点主动断链，重新选择其他正常的Namesrv节点。

Broker支持主备模式自动切换

Rocketmq4.5之前的版本Broker采用的是M-S的部署模式，主节点异常后，程序缺乏状态调度手段，必须人工介入才能进行主备切换，无法满足电信行业的高可用要求。

传统M-S部署方式消息写入模式如下：

Producer客户端发送消息到Broker master节点
Master节点同步写入到Slave从节点
Slave通知Maser节点消息写入成功
Master节点返回成功写入状态至消息客户端

Rocketmq自4.5版本起引入了Dledger多副本框架，基于raft共识算法（分布式数据一致性协议paxos），是一种强一致性、去中心化、高可用的分布式协议，确保集群中的每个节点都同意一系列相同的状态转换。

Leader选举：Leader异常或者服务初期启动，通过多数派共识算法，决策出主节点；数据同步：领导者确认后，由Leader接受客户端的请求，写入node log（此时数据没有提交，因而不会更新节点数据），并同步到从节点，当收到多数的从节点应答后，更新本地数据，响应客户端数据写入成功，并通知其他的节点更新数据。

>>>>

痛点描述：

利用raft的特性，Dledger天然支持自动选主和切换，但是也正是由于多数派原则，防止脑裂风险，Broker节点至少需要3副本，相较于原来的主备模式，至少需要额外增加一个Broker节点，增大了部署硬件资源的成本。

>>>>

解决方案：

浩鲸科技WhaleDI-MQ引入Zookeeper协同主备状态控制，仍采用一主一备模式实现主从自动切换的能力，减少了部署的节点数，又满足了电信行业的高可用的要求。

由于ZK的作用仅仅为Broker主备状态控制，其资源占用非常少，可以和Dubbo或者其他的业务应用共用zk，甚至可以将zk部署到WhaleDI-MQ的服务器上，从而节省了硬件部署资源。

>>>>

应用成果：

WhaleDI-MQ部署时仍采用一主一备的模式，利用zk做状态控制，就可以实现主备自动切换的功能，降低了消息组件部署的主机数量，给客户节省了成本。

异地容灾

>>>>

痛点描述：

一般的消息队列只支持主备部署模式，即便采用异地部署，主备节点仍在一个大集群中，若异地距离比较远网络时延较大时，将极大的影响消息发送的性能，不满足浩鲸科技电信级商用项目的要求。若MQ部署在同一个机房中，一旦遭遇火灾、地震等不可抗力的灾难时，难以快速恢复消息服务，导致业务长时间中断，并可能丢失大量的业务消息。

>>>>

解决方案：

WhaleDI-MQ通过异地构建一套消息容灾集群，不间断地从主站点同步消息数据，当主节点遭受意外情况且系统无法恢复时，可以在两分钟之内将容灾集群切换为主站点集群，快速恢复业务，减少中断时长，从而降低客户的损失。

异地消息容灾集群能够自动感知主站点的Broker节点状态，并建立数据复制通道，即便主站点发生主备切换或者同步链路断开，容灾节点也能够根据名服务重新获取路由信息，建链续传。

容灾消息复制支持同步和异步两种数据复制模式，业务可以根据实际需要配置复制模式：

同步复制：保证数据零丢失；异步复制：容灾复制对主站点自身的消息写入服务影响比较小，数据复制会有稍许的延时（秒级）。
应用成果：WhaleDI-MQ容灾站点可以在主站点异常不可用时，进行一键容灾切换，将容灾站点切换为主站点，快速地恢复服务。

消息发送稳定性提升

Producer发送消息的时候，默认会轮询所有的message queue发送，以达到让消息平均落在不同的queue上。由于queue散落在不同的Broker，所以消息就发送到不同的Broker上，如下图：

>>>>

故障场景：

当BrokerA出现以下情况时：

BrokerA磁盘阻塞或写入超时
生产者和BrokerA之间网络超时、丢包等
BrokerA cpu、内存等使用率超过100%

由于发生上述故障时，BrokerA的进程正常，并不会使namesrv剔除BrokerA的路由数据，导致每当消息发送轮询到故障BrokerA节点时便会发生超时(默认5秒)，超时后客户端轮询到BrokerB节点则又正常发送消息，等下次再轮询到BrokerA节点时，又会触发5秒的超时，导致tps骤降，引起业务异常。

>>>>

解决方案：

发送客户端引入故障熔断机制

资源隔离：单个Broker的异常不会影响其他Broker的消息发送
超时熔断：当前的Broker在一定的时间内超时达到了一定的次数，并执行服务降级，并使用异步的机制探测恢复的情况
失败熔断：当发送失败的调用次数达到一定阈值，如system busy、io满载等则自动降级，并使用进行异步机制探测恢复的情况

>>>>

应用成果：

BrokerA故障期间，消息不再往故障节点发送消息，而是转而路由到其他正常的Broker节点，保证了消息发送的成功率。同时异步的检测故障节点的恢复情况，若节点恢复，则消息会重新往此节点发送。

服务节点自愈

>>>>

痛点描述：

一般的消息服务组件不具备应用自愈的能力，当MQ部署主机异常重启时，需要人工介入，手动重启服务组件。从异常发生，到告警系统捕获到集群异常信息通知到运维人员，再到运维人员上线分析告警原因，逐个登录到MQ的各个主机上重启Namesrv和Broker，往往至少需要耗费一个小时修复周期，导致在分秒必争的电信级生产环境中，给客户造成极大的损失。

>>>>

方案描述：

WhaleDI-MQ提供统一的健康状态监控+调度的功能，定时检查各个服务节点的运行情况，当检测到节点异常时，统一调度将会自动拉起故障节点。

>>>>

应用成果：

利用统一调度功能，WhaleDI-MQ的Namesrv、Broker和ZK皆具备了服务自愈的能力，进程异常退出后，无需人工介入，自动恢复消息服务组件，修复的时间由原来的至少1小时降低到2分钟；同时程序自愈的能力也降低了人工介入误操作的概率，保障了生产系统的安全。

实践总结

浩鲸科技具有数百个行业稳定落地的实践经验，同时基于HATT混沌工程，我们从网络、内存、IO、磁盘、cpu等多个维度，编写了上百个测试用例，充分验证了WhaleDI-MQ稳定性能力，并对相关的不足点进行了优化提升，使得SLA可用性达到了99.99%。

WhaleDI分布式消息产品已经有效支撑了浩鲸科技众多电信级的项目平稳运行，全面助力客户应用数字化转型。随着业务应用云原生化的不断深入，需要MQ进一步加强产品的稳定性，如故障数据检查同步算法、磁盘坏道数据mock、主容站点数据同步压缩加速、主备切换时长、客户端缩短感知等方面，针对这些场景，我们会继续深入技术研究，力争在未来企业应用的各种复杂场景下，更好地保障系统应用高效平稳运行。

九州(中国)科技有限公司官网

九州(中国)科技有限公司官网

鲸品堂｜WhaleDI消息队列稳定性提升实践

关于我们

产品与解决方案

成功故事

九州(中国)科技有限公司官网