基于Raft深度优化，腾讯云金融级消息队列CMQ高可靠算法详解

背景介绍

分布式系统是指一组独立的计算机，通过网络协同工作的系统，客户端看来就如同单台机器在工作。随着互联网时代数据规模的爆发式增长，传统的单机系统在性能和可用性上已经无法胜任，分布式系统具有扩展性强、可用性高、廉价高效等优点得以广泛应用。

但与单机系统相比，分布式系统在实现上要复杂很多。CAP理论是分布式系统的理论基石，它提出以下3个要素：

Consistency（强一致性）：任何客户端都可以访问到同一份最新的数据副本。

Availability（可用性）： 系统一直处于可服务状态，每次请求都能获得非错的响应。

Partition-tolenrance（分区可容忍性）：单机故障或网络分区，系统仍然可以保证强一致性和可用性。

一个分布式系统最多只能满足其中2个要素。对于分布式系统而言，P显然是必不可少的，那么只能在AP和CP之间权衡。AP系统牺牲强一致性，这在某些业务场景下（如金融类）是不可接受的，CP系统可以满足这类需求，问题的关键在于会牺牲多少可用性。传统的主备强同步模式虽然可以保证一致性，但一旦机器故障或网络分区系统将变得不可用。paxos和raft等一致性算法的提出，弥补了这一缺陷。它们在保证CP的前提下，只要求大多数节点可以正常互联，系统便可以一直处于可用状态，可用性上显著提高。paxos的理论性偏强，开发者需要自己处理很多细节，这也是它有很多变种的原因，相对而言raft更易理解和工程化，一经提出便广受欢迎。

在我们关注的消息中间件领域，金融支付类业务往往对数据的强一致性和高可靠性有严格要求。

在对主流的消息中间件进行调研后，发现它们在应对这种场景时都存在一定的不足：

RabbitMQ：一个请求需要在所有节点上处理2次才能保证一致性，性能不高。

Kafka：主要应用在日志、大数据等方向，少量丢失数据业务可以忍受，但不适合要求数据高可靠性的系统。

RocketMQ：未采用一致性算法，如果配置成异步模式可能丢失数据，同步模式下节点故障或网络分区都会影响可用性。

SQS：只提供最终一致性，不保证强一致性。

鉴于以上分析，我们设计开发了基于Raft的强一致高可靠消息中间件CMQ。接下来会介绍raft算法原理细节、如何应用在CMQ中在保证消息可靠不丢失，以及实现过程中在性能方面所作的优化。

二 Raft算法介绍

2.1 概述

Raft算法是Diego Ongaro博士在论文《In Search of an Understandable Consensus Algorithm》,2014 USENIX中首次提出，算法主要包括选举和日志同步两部分:

以下是贯穿Raft算法的重要术语：

节点之间通过RPC通信来完成选举和日志同步，发送方在发送RPC时会携带自身的Term，接收方在处理RPC时有以下两条通用规则：

RPC中的RTerm大于自身当前Term，更新自身Term = RTerm、votedFor = null，转为Follower。 RPC中的RTerm小于自身当前Term，拒绝请求，响应包中携带自身的Term。

2.2 选举算法

Raft算法属于强Leader模式，只有Leader可以处理客户端的请求，Leader通过心跳维持自身地位，除非Leader故障或网络异常，否则Leader保持不变。选举阶段的目的就是为了从集群中选出合适的Leader节点。