【分布式共识算法】Basic Paxos 算法

basic paxos算法:描述的是多个节点就某个值达成共识。

muti-paxos 算法:描述的是执行多个basic paxos实例,就一系列值达成共识。

共识其实,比如当多个客户端请求服务器,修改同一个值X 多个阶段达成共识。

原理

角色:提议者、接受者、学习者。

提议者 :说白了就是提出一个值,用于投票表决。
接受者 :对提议者提出的值进行投票表决,并存储对应的值。比如A、B、C三个节点,参与协商,并接收和存储数据。

所以一个节点即可能是提议者,也可能是接收者,比如对于一个集群来说,客户端发送请求,当一个节点接收到请求,就是提议者。
学习者:被告知投票的结果,接收达成共识的值,存储保存,不参与投票的过程。 就是一个数据备份的作用。

提议者代表的是接入和协调功能,收到请求后发起二阶段提交,进行共识协商。
接受者代表投票协商和存储数据,对提议的值进行投票,并接受达成共识的值,存储保存
学习者只保存共识的值,不参与投票

提案编号:每个提议者需要的一个编号。

提案值:需要达成共识的数据。

准备阶段

假设客户端1发送一个1, 提案编号,请求先达到节点A、B,客户端2发送提案编号5, 先达到节点C。因为准备节点不需要提议值,写需要写到提案编号就可以了。

整个处理过程是这样的。

节点A、B先收到1的提案编号,并且查看之前没有提案编号,并承诺以后不响应小于等于1的提案编号,不会通过小于1的提案

节点c接受到请求后,因为是提案5到达,所以不响应小于等于5的提案编号,不会通过小于5的提案。

所以整个过程来说的话,其实就是针对节点A、B 提案编号1返回了响应。节点C对于提案编号5返回了响应。然后节点A、B 对于提案编号5返回响应,因为5>1。而节点C针对提案编号1 不发挥响应。

接受阶段

客户端 接着发起接受阶段,比如客户端1发起的提议值是3,那么就是1,3 而客户端2发起提议值是7,所以就是 5,7。由于有规则限定,接受者不会接受比自己小的提案编号的提议值,所以接受者 A、B、C三个节点否决了客户端1的提议值。而接受了客户端2的提议值。

所以最终三个节点就x=7达成了共识。

而basic paxos算法具备一定的容错能力,也就是集群中少于一半以上的节点出现故障的话,剩余节点依然可以就某个值达成共识。

小结

basic paxos是通过二阶段提交的方式进行达成共识的。
basic paxos可以实现容错能力,少于一半的节点故障,依然可以工作
提案编号其实就代表者优先级,
在请求阶段,如果接受者不会返回小于等于已经响应过的提案编号。比如请求 1、2,2如果先到达,1就不会响应
在接受阶段,如果接受请求的提案的提案编号,小于已经响应过的提案编号,接受者不会通过这个提案
如果接受者之前有通过提案,那么接受者将承诺,会在准备请求返回已经通过的最大编号的提案信息

三个说白了就是我不会响应小于提案编号。不会通过已经响应过的提案值。如果有结果,那么就不会在产生新的值。

相关推荐
samforce2 小时前
为什么微服务会退化成“分布式单体”?——软件架构里的嵌套率传导定律
人工智能·分布式·微服务·架构·软件架构·结构认知
每天一道题19 小时前
Kafka 是如何工作的?从 Broker、Partition、Offset 到 Consumer Group
分布式·kafka
用户14944848132021 小时前
为什么大厂很少直接用 2PC/TCC?聊聊分布式事务在真实业务里的落地套路
分布式·后端
code_slave(码畜)1 天前
微服务架构落地:分库分表实战(下) —— 分布式主键、跨分片查询与分页聚合防坑
数据库·spring boot·分布式·spring cloud·微服务·架构·分库分表
德迅云安全-上官1 天前
新一代智能分布式云接入:应用加速守护 TCP 业务安全与体验
分布式·tcp/ip·安全
凯凯姜1 天前
分布式定时任务重复执行与故障恢复
分布式
vortex51 天前
以太坊 Geth 私有链部署与原理
区块链
Sayai1 天前
Kafka 磁盘空间治理实战:retention 保留策略、log.dirs 在线扩容、分区跨盘迁移与不停机整体换盘
大数据·运维·分布式·kafka·消息队列
磐链科技1 天前
元链科技:随着区块链技术持续发展,Web3逐渐成为数字资产管理、去中心化应用和数字经济创新的重要技术方向
科技·web3·区块链
爱吃牛肉的大老虎1 天前
Redis之分布式 Session问题
数据库·redis·分布式