分布式一致性协议算法

角色

提案

准备请求

接收请求

这个是解决BAsic paxos 算法 很多缺点的算法思想,不是具体某个算法.

领导者Leader

跟随者Follower

候选人Candidate

请求投票（RequestVote）RPC，是由候选人在选举期间发起，通知各节点进行投票

日志复制（AppendEntries）RPC，是由领导者发起，用来复制日志和提供心跳消息

每个任期由单调递增的数字（任期编号）标识，比如节点 A 的任期编号是 1。任期编号是随着选举的举行而变化的

1.跟随者在等待领导者心跳信息超时后，推举自己为候选人时，会增加自己的任期号，比如节点 A 的当前任期编号为 0，那么在推举自己为候选人时，会将自己的任期编号增加为 1。

2.如果一个服务器节点，发现自己的任期编号比其他节点小，那么它会更新自己的编号到较大的编号值。比如节点 B 的任期编号是 0，当收到来自节点 A 的请求投票 RPC 消息时，因为消息中包含了节点 A 的任期编号，且编号为 1，那么节点 B 将把自己的任期编号更新为 1。

1.领导者周期性地向所有跟随者发送心跳消息.确保他们不会选举

2.如果在指定时间内，跟随者没有接收到来自领导者的消息，那么它就认为当前没有领导者，推举自己为候选人，发起领导者选举

3.在一次选举中，赢得大多数选票的候选人，将晋升为领导者

4.在一个任期内，领导者一直都会是领导者，直到它自身出现问题（比如宕机），或者因为网络延迟，其他节点发起一轮新的选举

5.在一次选举中，每一个服务器节点最多会对一个任期编号投出一张选票，并且按照“先来先服务”的原则进行投票。比如节点 C 的任期编号为 3，先收到了 1 个包含任期编号为 4 的投票请求（来自节点 A），然后又收到了 1 个包含任期编号为 4 的投票请求（来自节点 B）。那么节点 C 将会把唯一一张选票投给节点 A，当再收到节点 B 的投票请求 RPC 消息时，对于编号为 4 的任期，已没有选票可投了

随机超时时间:Raft 算法巧妙地使用随机选举超时时间的方法，把超时时间都分散开来，在大多数情况下只有一个服务器节点先发起选举，而不是同时发起选举，这样就能减少因选票瓜分导致选举失败的情况。

http://thesecretlivesofdata.com/raft/

实现基本可用的四板斧,当分布式系统遇到不可预知的外界压力时。允许损失部分功能不可用，保障核心系统可用性

流量削峰

延迟响应

体验降级

过载保护

经过一段时间的同步后（MQ.定时任务补偿等机制）使数据达到最终一致性

读时修复：在读取数据时检测数据是否一致，不一致则修复

写时修复：在写入数据时检测数据是否一致，不一致则修复

异步修复：定时任务定时去检测数据是否一致，不一致则修复

软状态是实现服务可用性的一种过渡状态，不同节点数据短暂的不一致。就是一种过渡状态/中间状态

• 提交请求阶段(投票阶段) 需要预留资源

• 提交执行阶段(完成阶段) 返回结果

MySQL中innodb两阶段提交的应用案例

更新语句将更新值保存到内中之后

prepare阶段 写入redolog

写入binlog

commit阶段提交事务

三阶段提交协议，虽然针对二阶段提交协议的“协调者故障，参与者长期锁定资源”的痛点，通过引入了询问阶段和超时机制，来减少资源被长时间锁定的情况，不过这会导致集群各节点在正常运行的情况下，使用更多的消息进行协商，增加系统负载和响应延迟。也正是因为这些问题，三阶段提交协议很少被使用

• 提交请求阶段(投票阶段) 需要预留资源

• 提交执行阶段(完成阶段) 返回结果

MySQL中innodb两阶段提交的应用案例

更新语句将更新值保存到内中之后

prepare阶段 写入redolog

写入binlog

commit阶段提交事务

三阶段提交协议，虽然针对二阶段提交协议的“协调者故障，参与者长期锁定资源”的痛点，通过引入了询问阶段和超时机制，来减少资源被长时间锁定的情况，不过这会导致集群各节点在正常运行的情况下，使用更多的消息进行协商，增加系统负载和响应延迟。也正是因为这些问题，三阶段提交协议很少被使用

Try预留、Confirm确认、Cancel取消

业务层面的协议，需要在业务中去实现一个操作对应的 确认操作和取消操作。业务入侵性太强