设为首页 加入收藏

TOP

一篇文章让你弄懂分布式一致性协议Paxos(三)
2023-09-23 15:44:33 】 浏览:157
Tags:一篇 文章让 Paxos
点达成共识,当前三个节点的事务日志表均为:{'Op1','Put(a,'1')'},数据表均为空。
4、达成共识后,Server1执行写入操作并更新当前节点的OperateIndex,此时Server1的OperateIndex为1,其他节点仍为0,Server1的数据表为:a = 1,另外两个节点为空,三个节点的事务日志表相同,当前写入流程结束。

假设,此时Server2节点接收到Put(b,'1')的请求,处理流程如下:
1、Server2接收到Put(b,'1')请求,由于当前Server2的OperateIndex仍为0,则首先发起Prepare(1)的请求,
2、由于当前三个节点的Acceptor的提案编号均为1,所以会拒绝Server2的Prepare(1)请求.
3、Server2未能得到超过半数的prepare响应,则会查看当前事务日志表发现已存在Op1操作,则从当前节点的事务日志表中取出相应操作并执行,然后将当前节点OperateIndex修改为1;
4、Server2随即再次发起Prepare(OperateIndex+1),即Prepare(2)的请求。
5、此时三个节点达成共识,并更新各自的事务日志表。
6、Server2执行写入操作,此时Server1节点状态为OperateIndex:1,数据表:a=1;Server2节点状态为OperateIndex:2, 数据表:a=1和b=1;Server3的节点状态为OperateIndex:0,数据表为空;三个节点的事务日志表相同,均为:
{'Op1','Put(a,'1')'};{'Op2','Put(b,'1')'}。当前流程执行结束。

假设,此时Server3接收到Get(a)请求,处理流程如下:
1、Server3接收到Get(a)请求,并不是直接查询数据表然后返回,而是要将当前节点的OperateIndex和事务日志表中的记录进行比对,如果发现有遗漏操作,则按照事务日志表的顺序执行遗漏操作后再返回。
由于Get请求并不涉及对数据的写入和修改,所以理论上不需要再次发起Paxos协商。
2、此时Server1节点的状态为OperateIndex:1,数据表:a=1;Server2的节点状态为OperateIndex:2, 数据表:a=1和b=1;Server3的节点状态为OperateIndex:2,数据表为a=1和b=1;三个节点的事务日志表相同,均为:
{'Op1','Put(a,'1')'};{'Op2','Put(b,'1')'}。当前流程执行结束。

执行流程示意图如下:

随着数据的不断写入,事务日志表的数据量不断增加,可以通过快照的方式,将某个时间点之前的数据备份到磁盘(注意此处备份的是数据表数据,不是事务日志数据,这样宕机恢复时直接从快照点开始恢复,可以提高恢复效率,如果备份事务日志数据,宕机恢复时需要从第一条日志开始恢复,导致恢复时间会比较长),然后将事务日志表快照前的数据清除即可。

六、对一些问题的解释

1、投票过程为什么要遵循选择最大提案号的原则?

Paxos投票虽然叫作“投票”,但其实与我们现实中的“投票”有很大的区别,因为它的运算过程中并不关心提案内容本身,而完全依据哪个提案号大就选择哪个的原则,因为只有这样才能达成共识。

2、为什么Proposer每次发起prepare都要变更提案号?

这个问题其实很容易理解,也是为了达成共识。假设ProposerA、ProposerB、ProposerC分别同时发起了prepare(1)、prepare(2)、prepare(3)的提案,而此时ProposerC出现故障宕机,如果ProposerA、ProposerB在后续的每一轮投票中都不变更提案号,那永远都不可能达成共识。

3、为什么Paxos算法可以避免脑裂问题?

Paxos算法可以避免分布式集群出现脑裂问题,首先我们需要知道什么是分布式集群的脑裂问题。
脑裂是指集群出现了多个Master主节点,由于分布式集群的节点可能归属于不同的网络分区,如果网络分区之间出现网络故障,则会造成不同分区之间的节点不能互相通信。而此时采用传统的方案很容易在不同分区分别选出相应的主节点。这就造成了一个集群中出现了多个Master节点即为脑裂。
而Paxos算法是必须达到半数同意才能达成共识,这就意味着如果分区内的节点数量少于一半,则不可能选出主节点,从而避免了脑裂状况的发生。

七、开发、运维超实用工具推荐

接下来向大家推荐一款对日常开发和运维,极具有实用价值的好帮手XL-LightHouse。

一键部署,一行代码接入,无需大数据相关研发运维经验就可以轻松实现海量数据实时统计,使用XL-LightHouse后:

  • 再也不需要用Flink、Spark、ClickHouse或者基于Redis这种臃肿笨重的方案跑数了;
  • 再也不需要疲于应付对个人价值提升没有多大益处的数据统计需求了,能够帮助您从琐碎反复的数据统计需求中抽身出来,从而专注于对个人提升、对企业发展更有价值的事情;
  • 轻松帮您实现任意细粒度的监控指标,是您监控服务运行状况,排查各类业务数据波动、指标异常类问题的好帮手;
  • 培养数据思维,辅助您将所从事的工作建立数据指标体系,量化工作产出,做专业严谨的职场人,创造更大的个人价值;

XL-LightHouse简介

  • XL-LightHouse是针对互联网领域繁杂的流式数据统计需求而开发的一套集成了数据写入、数据运算、数据存储和数据可视化等一系列功能,支持超大数据量,支持超高并发的【通用型流式大数据统计平台】。
  • XL-LightHouse目前已涵盖了常见的流式数据统计场景,包括count、sum、max、min、avg、distinct、topN/lastN等多种运算,支持多维度计算,支持分钟级、小时级、天级多个时间粒度的统计,支持自定义统计周期的配置。
  • XL-LightHouse内置丰富的转化类函数、支持表达式解析,可以满足各种复杂的条件筛选和逻辑判断。
  • XL-LightHouse是一套功能完备的流式大数据统计领域的数据治理解决方案,它提供了比较友好和完善的可视化查询功能,并对外提供API查询接口,此外还包括数据指标管理、权限管理、统计限流等多种功能。
  • XL-LightHouse支持时序性数据的存储和查询。

** Git地址 **
https://github.com/xl-xueling/xl-lighthouse.git

https://gitee.com/xl-xueling/xl-lighthouse.git

如本文有所疏漏或您有任何疑问,欢迎访问dtstep.com与我本人沟通交流!

首页 上一页 1 2 3 下一页 尾页 3/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇8K Star,一款开源仿Notion且AI强.. 下一篇15.3K Star,超好用的开源协作式..

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目