分布式系统架构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天前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
52 8
|
23天前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
81 41
|
23小时前
|
存储 人工智能 算法
解锁分布式文件分享的 Java 一致性哈希算法密码
在数字化时代,文件分享成为信息传播与协同办公的关键环节。本文深入探讨基于Java的一致性哈希算法,该算法通过引入虚拟节点和环形哈希空间,解决了传统哈希算法在分布式存储中的“哈希雪崩”问题,确保文件分配稳定高效。文章还展示了Java实现代码,并展望了其在未来文件分享技术中的应用前景,如结合AI优化节点布局和区块链增强数据安全。
|
7天前
|
存储 缓存 安全
分布式系统架构7:本地缓存
这是小卷关于分布式系统架构学习的第10篇文章,主要介绍本地缓存的基础理论。文章分析了引入缓存的利弊,解释了缓存对CPU和I/O压力的缓解作用,并讨论了缓存的吞吐量、命中率、淘汰策略等属性。同时,对比了几种常见的本地缓存工具(如ConcurrentHashMap、Ehcache、Guava Cache和Caffeine),详细介绍了它们的访问控制、淘汰策略及扩展功能。
31 6
|
10天前
|
存储 关系型数据库 分布式数据库
[PolarDB实操课] 01.PolarDB分布式版架构介绍
《PolarDB实操课》之“PolarDB分布式版架构介绍”由阿里云架构师王江颖主讲。课程涵盖PolarDB-X的分布式架构、典型业务场景(如实时交易、海量数据存储等)、分布式焦点问题(如业务连续性、一致性保障等)及技术架构详解。PolarDB-X基于Share-Nothing架构,支持HTAP能力,具备高可用性和容错性,适用于多种分布式改造和迁移场景。课程链接:[https://developer.aliyun.com/live/253957](https://developer.aliyun.com/live/253957)。更多内容可访问阿里云培训中心。
[PolarDB实操课] 01.PolarDB分布式版架构介绍
|
1月前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
80 11
|
1月前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
55 11
|
1月前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
68 11
|
1月前
|
自然语言处理 负载均衡 Kubernetes
分布式系统架构2:服务发现
服务发现是分布式系统中服务实例动态注册和发现机制,确保服务间通信。主要由注册中心和服务消费者组成,支持客户端和服务端两种发现模式。注册中心需具备高可用性,常用框架有Eureka、Zookeeper、Consul等。服务注册方式包括主动注册和被动注册,核心流程涵盖服务注册、心跳检测、服务发现、服务调用和注销。
103 12
|
3月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?