强一致性算法Raft解析

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,接收方在处理时按照两种流程

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值