分布式系统架构1:共识算法Paxos

简介: 本文介绍了分布式系统中实现数据一致性的重要算法——Paxos及其改进版Multi Paxos。Paxos算法由Leslie Lamport提出,旨在解决分布式环境下的共识问题,通过提案节点、决策节点和记录节点的协作,确保数据在多台机器间的一致性和可用性。Multi Paxos通过引入主节点选举机制,优化了基本Paxos的效率,减少了网络通信次数,提高了系统的性能和可靠性。文中还简要讨论了数据复制的安全性和一致性保障措施。

1.背景

今天开始更新分布式的文章,工作几年后还没系统的学习分布式的内容,趁着还有时间学习沉淀的时候多输出些文章

2.为什么需要分布式共识算法

思考:现在你有一份随时变动的数据,需要确保它正确存储在网络的几台不同机器上,并且要保证数据是随时可用的,应该怎么做?

在分布式环境下,可以不必去追求系统内所有节点在任何情况下的数据状态都一致,采用“少数服从多数”的原则,认为数据的变化被正确存储在系统中。因此,我们需要一种算法,能够让分布式系统内部暂时容忍节点存在不同的状态,但最终大多数节点的状态能够一致。

这种让系统能最终表现出整体一致性的过程,急救室各个节点的协商共识

3.Paxos算法的历史

简单写下Paxos算法的历史,最早是由Leslie Lamport(就是大名鼎鼎的LaTeX中的“La”)提出的一种基于消息传递的协商共识算法。

Lamport 在 1990 年首次发表了 Paxos 算法,选的论文题目就是“The Part-Time Parliament”。但是由于论文使用了希腊城邦的比喻,使得论文更为晦涩难懂,审稿人要求Lamport进行修改,Lamport 非常不爽,然后干脆就撤稿不发了。 2001 年,Lamport 在“SIGACT News”杂志上发表了这篇论文,并放弃了“希腊城邦”的比喻。

之后,2006 年,Google 的 Chubby、Megastore 和 Spanner 等分布式系统,都使用 Paxos 解决了分布式共识的问题,这才使得Paxos 算法一夜间成为计算机科学分布式这条分支中,最炙手可热网红概念。

4.Basic Paxos算法工作流程

Basic Paxos算法将分布式系统中的节点分为提案节点、决策节点和记录节点三类

  • 提案节点Proposer:提出对某个值进行设置操作的节点,设置值这个行为就像提案,值设置成功后,不可变也不会丢失
  • 决策节点Acceptor:应答提案的节点,需要对提案进行投票,同时需要记住自己的投票历史
  • 记录节点Learner:超过半数决策节点就某个提案达成了共识,那么记录节点就需要接受这个提案,并就该提议作出运算,然后将运算结果返回给客户端

1.png

4.1Paxos算法怎么解决并发操作带来的竞争?

分布式环境下,一个节点取得锁后,如果在释放锁之前发生崩溃,整个操作都会被无限期等待阻塞。

Paxos解决竞争分2个阶段:

准备Prepare:提案节点先广播一个Prepare请求,并附带一个全局数字n作为提案ID,决策节点收到请求后,“两个承诺,一个应答”。承诺不在接收提案ID小于等于n的Prepare请求,也承诺不再接收小于n的Accept请求。应答已经批准过的提案中ID最大的那个。

批准Accept:提案节点收到多数派的应答后,会有两种结果:

  • 所有响应的决策节点此前没有批准过这个值,即首次设值的情况,那就自己随意选定值与提案ID,广播给决策节点
  • 响应决策节点中,已有至少一个节点的应答中包含有值了,非首次设值的情况,那么需要从应答中找出提案ID最大的那个值,再广播。协商共识结束

2.png

Basic Paxos 只能对单个值形成决议,并且决议的形成至少需要两次网络请求和应答(准备和批准阶段各一次),高并发情况下可能形成活锁。现在只做理论学习就行了。下面讲Multi Paxos算法。

5.Multi Paxos共识算法

5.1核心改进

概念:Multi-Paxos 只是一种思想,这种思想的核心就是通过多个 Basic Paxos 实例就一系列值达成共识。

相比较Basic Paxos算法,Multi Paxos增加了选主的过程:

  • 提案节点发现没有主提案节点时,使用准备、批准两轮网络交互,向其他节点广播自己竞选主节点请求
  • 得到决策节点多数派的批准时,竞选主节点成功。

选主之后,所有客户端请求都会由主节点来完成提案,不再需要准备过程,只需要 执行批准交互即可:

3.png

5.2只有主从节点

有了主节点后,角色可以简化,不再区分提案、决策、记录节点。只区分主、从节点。

4.png

于是,分布式系统中如何对某个值达成一致 的问题可以分为3部分解决:

  • 如何选主
  • 如何把数据复制到各个节点上
  • 怎么保证过程是安全的

3个问题解决了,就达成共识了。

这里针对问题2和问题3写些内容,用于应对可能的面试:

问题2:数据复制的过程?

  • 主节点将 X 写入自己的变更日志,但先不提交,接着把变更 X 的信息在下一次心跳包中广播给所有的从节点,并要求从节点回复“确认收到”的消息;
  • 从节点收到信息后,将操作写入自己的变更日志,然后给主节点发送“确认签收”的消息;
  • 主节点收到过半数的签收消息后,提交自己的变更、应答客户端并且给从节点广播“可以提交”的消息;
  • 从节点收到提交消息后提交自己的变更,数据在节点间的复制宣告完成。

问题3:过程是安全的?

  • 协定性Safety:保证选主的结果一定有且只有唯一的主节点
  • 终止性Liveness:保证选主过程一定是在某一时刻能够结束的

从极客时间课程原文上没理解清楚这段的解释,先空着吧,后面理解了再修改这段

总结

Paxos 算法不直接应用于工业界,理解原理理论就行。它的变体算法,比如我们今天学习的 Multi Paxos、Raft 算法,以及没有提到的 ZAB 等算法,都是分布式领域中的基石。

相关文章
|
4月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
704 3
|
5月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
2月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
2月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
276 1
|
3月前
|
负载均衡 算法 调度
基于遗传算法的新的异构分布式系统任务调度算法研究(Matlab代码实现)
基于遗传算法的新的异构分布式系统任务调度算法研究(Matlab代码实现)
181 11
|
8月前
|
人工智能 安全 Java
智慧工地源码,Java语言开发,微服务架构,支持分布式和集群部署,多端覆盖
智慧工地是“互联网+建筑工地”的创新模式,基于物联网、移动互联网、BIM、大数据、人工智能等技术,实现对施工现场人员、设备、材料、安全等环节的智能化管理。其解决方案涵盖数据大屏、移动APP和PC管理端,采用高性能Java微服务架构,支持分布式与集群部署,结合Redis、消息队列等技术确保系统稳定高效。通过大数据驱动决策、物联网实时监测预警及AI智能视频监控,消除数据孤岛,提升项目可控性与安全性。智慧工地提供专家级远程管理服务,助力施工质量和安全管理升级,同时依托可扩展平台、多端应用和丰富设备接口,满足多样化需求,推动建筑行业数字化转型。
278 5
|
3月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
3月前
|
传感器 机器学习/深度学习 算法
【无人机编队】基于麻雀算法分布式无人机群自适应航迹规划和碰撞检测研究(Matlab代码实现)
【无人机编队】基于麻雀算法分布式无人机群自适应航迹规划和碰撞检测研究(Matlab代码实现)
|
6月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
335 61

热门文章

最新文章