Raft算法
背景
分布式是一组独立的计算机,利用网络协同来工作的系统。客户看来就如同一台机器在进行工作。在信息爆照时代,传统的单机以无法应对需求了,分布式具有可扩展性强,可用性高,廉价高效的特点称为了服务发展的趋势。
问题
解决了高需求的问题,但同时也引入了新的问题,需求与服务之间的矛盾并没有彻底解决只是转换成可以分解的问题。CAP理论是分布式理论的基础,它提出三个要素:
Consistency(强一致性):任何客户端都可以读取到其他客户端最近的更新;
Availability(可用性): 系统一直处于可服务状态。
Partition-tolenrance(分区可容忍性):单机故障或网络分区,系统仍然可以保证强一致性和可用性。
很明显这三个是存在需求的矛盾区,一个分布式系统最多只能满足两个,P是必不可少的,AP保证服务的高可用性,但是对于数据的一致性问题,如金融系统中显现出数据丢失的风险。CP保证了数据的一致性,但是损失了性能。传统的主备强同步模式虽然可以保证保证数据一致性,但是对于网络分区或者网络故障就无法使用。paxos和raft等一致性算法的提出,弥补了这部分缺陷,它们在保证CP的前提下,只要大部分机器可以使用,就认为整个系统是可以使用的。
在消息中间件领域,金融支付场景是非常需要强一致性和高可靠性,目前主流的消息中间件存在或多或少的问题:
RabbitMQ:一个请求需要在所有节点上处理2次才能保证一致性,性能不高。
Kafka:kafka主要应用在日志、大数据等方向,少量丢失数据业务可以忍受,但不适合要求数据高可靠性的系统。
RocketMQ:未采用一致性算法,如果配置成异步模式可能丢失数据,同步模式下节点故障或网络分区都会影响可用性。
SQS:只提供最终一致性,不保证强一致性。
针对这些问题我们研究一下基于Raft的一致性算法。
Raft算法基本原理
概述:
Raft算法主要包括选举和日志同步。
第一阶段:选举
从集群中选择一台机器作为Leader。
第二阶段:日志同步:
选举出的Leader接收客户端的请求,将其转换为Raft日志;
Leader将日志同步到其他的节点,当大多数节点写入成功后,标志为committed,已经committed的日志不再发生更改;
Leader发生故障时跳到第一阶段进行选举。
Raft算法的术语解释:
Term : 当前的节点所处的周期,可以当作某一个帝王统治时期;
votedFor:当前Term的投票信息,每个节点在一个Term上只能投一次票;
Entry:raft日志的基本单元,包括index,user_dara,term,其中index在日志文件中顺序分配,term是创建该entry所处的term,user_data是业务数据;
State:节点状态(角色)(Leader、Candidate、Follower之一)
CommittedIndex:已提交日志的索引;
State Machine:状态机,业务模块;
ApplyIndex: 已应用的日志索引;
ElectionTime:选举超时时间。
节点之间通过rpc来进行通信,发送方在发送时会携带自身的term,接收方在处理时按照两种流程