网站分站原理,php做门户网站,seo优化技术招聘,生成手机版网站引入
最早研究一致性的场景既不是大数据领域#xff0c;也不是分布式系统#xff0c;而是多路处理器。
可以将多路处理器理解为单机计算机系统内部的分布式场景#xff0c;它有多个执行单元#xff0c;每一个执行单元都有自己的存储(缓存)#xff0c;一个执行单元修改了…引入
最早研究一致性的场景既不是大数据领域也不是分布式系统而是多路处理器。
可以将多路处理器理解为单机计算机系统内部的分布式场景它有多个执行单元每一个执行单元都有自己的存储(缓存)一个执行单元修改了自己存储中的一个数据后这个数据在其他执行单元里面的副本就面临数据一致的问题。
随着时代发展互联网公司的快速发展单机系统在计算和存储方面都开始面临瓶颈分布式是一个必然的选择但是这也进一步放大了数据一致性面临的问题。对于数据的一致性最理想的模型当然是表现得和一份数据完全一样修改没有延迟即所有的数据修改后立即被同步。但在现实世界中数据的传播是需要时间的所以理想的一致性模型是不存在的。
不过从应用层的角度来看我们并不需要理想的一致性模型只需要一致性模型能满足业务场景的需求就足够了比如在统计分析类的场景中是能容忍一定的误差的而评论之类的场景中可能只要有因果关系的操作顺序一致就可以了。
同时由于一致性要求越高实现的难度和性能消耗就越大所以我们可以通过评估业务场景来降低数据一致性的要求这样人们就定义了不同的一致性模型来满足不同的需求。这种思路其实和我们在深入HDFS提到基于环境去衡权是类似的。
一致性模型
下面我们先看看四个经典且常见的一致性模型线性一致性、顺序一致性、因果一致性和最终一致性。
线性一致性Linearizability
线性一致性是 Herlihy 和 Wing 等于 1987 年在论文 “Axioms for Concurrent Objects” 中提出的线性一致性也被称为原子一致性(Atomic Consistency)、强一致性(Strong Consistency)、立即一致性(Immediate Consistency)和外部一致性 (External Consistency)。
线性一致性是非常重要的一个一致性模型在分布性锁、Leader 选举、唯一性约束等很多场景都可以看到它的身影。
这是最强的一致性模型。在这种模型下系统表现得就好像只有一个数据副本一旦新的值被写入或读取所有后续的读都会看到写入的值直到它被再次覆盖。在线性一致性模型中不论是数据的覆盖顺序还是读取顺序都是按时间线从旧值向新值移动而不会出现旧值反转的情况。
实现原理要求所有的操作看起来是瞬时完成的并且按照全局的时间顺序排列。
适用场景对数据一致性要求极高的场景如分布式事务处理。
优点提供了最强的一致性保证易于理解和推理。
缺点实现代价高性能开销大。
顺序一致性Sequential Consistency
顺序一致性是 Leslie Lamport 在 1979 年发表的论文 “How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Program” 中提出的在论文中具体的定义如下 A multiprocessor is said to be sequentially consistent if the result of any execution is the same as if the operations of all the processors were executed in some sequential order,and the operations of each individual processor appear in this sequence in the order specified by its program. 如果任何执行的结果与所有处理器的操作都以某种顺序执行的结果相同并且每个单独的处理器的操作按照其程序顺序出现在该序列中则称多处理器是顺序一致的 相对于线性一致性来说顺序一致性在一致性方面有两点放松
对于写操作对没有因果关系的非并发写入操作不要求严格按时间排序;对于读操作只要求所有的客户端观察到的顺序一致性不要求写入后所有的客户端都必须读取新值。
顺序一致性要求所有进程的操作都按照某种全局顺序执行每个进程的操作在这个全局顺序中保持其原有的顺序。但并不要求操作的结果立即对所有进程可见只需要保证所有进程看到的操作顺序是一致的。
实现原理只要所有进程看到的操作顺序符合某种合法的全局顺序即可。
适用场景多处理器系统中的共享内存模型。
优点比线性一致性的限制稍弱实现相对容易一些。
缺点仍然对系统性能有一定影响。
因果一致性Causal Consistency
因果一致性是 Mustaque Ahamad, Gil Neiger, James E. Burns, Prince Kohli, Phillip W. Hutto 在 1991 年发表的论文 “Causal memory: definitions, implementation, and programming” 中提出的一种一致性强度低于顺序一致性的模型。
相对于顺序一致性来说因果一致性在一致性方面有两点放松
对于写操作对没有因果关系的非并发写入操作不仅不要求按时间排序还不再要求节点 之间的写入顺序一致了;对于读操作由于对非并发写入顺序不再要求一致性所以自然也无法要求多个客户端必须 观察到一样的顺序。
因果一致性模型保证如果一个操作 A 的执行结果会影响到另一个操作 B 的执行那么所有进程都必须以 A 在 B 之前的顺序看到这两个操作。也就是说存在因果关系的操作在所有节点上都以相同的因果顺序执行但没有因果关系的操作可以以不同的顺序执行。
实现原理通过识别和跟踪操作之间的因果关系来实现。
适用场景对部分操作有顺序要求但又希望提高系统性能和扩展性的场景如分布式社交网络。
优点在保证一定因果顺序的前提下提高了系统的灵活性和性能。
缺点因果关系的判断和处理较为复杂。
最终一致性Eventual Consistency
最终一致性是 Amazon 的 CTO Werner Vogels 在 2009 年发表的一篇论文 “Eventual Consistency” 里提出的它是 Amazon 基于 Dynamo 等系统的实战经验所总结的一种很务实的实现它不同于前面几种由大学计算机科学的教授提出的一致性模型所以也没有非常学院派清晰的定义。
最终一致性是指在经过一段时间的延迟后系统中的所有数据副本最终会达到一致的状态。在数据更新后的一段时间内不同节点上的数据可能存在不一致但随着时间的推移数据会逐渐趋于一致。
“最终”是一个模糊的、不确定的概念它是没有明确上限的Vogels 提出这个不一致的时间窗口可能是由通信延迟、负载和复制次数造成的但是最终所有进程的观点都一致这个不一致的时间窗口可能是几秒也可能是几天。所以最终一致性是一个一致性非常低的模型但是它能非常高性能地实现在一些业务量非常大但是对一致性要求不高的场景是非常推荐使用的。
实现原理通常通过数据的异步复制和传播来实现。
适用场景对数据一致性要求不那么严格对可用性和性能要求较高的场景如缓存系统。
优点具有高可用性和良好的性能扩展性。
缺点可能会在一段时间内存在数据不一致的情况。
经典一致性算法
2PCTwo-Phase Commit两阶段提交
2PC协议解决阻塞、数据不一致问题和单点问题。
原理
准备阶段协调者向所有参与者发送事务请求参与者执行事务操作但不提交记录日志并向协调者反馈执行结果。提交阶段若所有参与者都反馈成功协调者发送提交指令参与者正式提交事务否则协调者发送回滚指令参与者回滚事务。应用场景对一致性要求较高且能容忍一定性能开销的事务处理场景。
优点原理简单、实现方便。能够保证事务的原子性在大多数情况下可以有效地保证数据一致性。
缺点单点故障问题协调者故障可能导致整个事务阻塞没有容错机制参与者故障可能导致数据不一致同步阻塞问题会影响系统性能和并发度。
3PCThree-Phase Commit三阶段提交
3PC协议解决2PC的阻塞但还是可能造成数据不一致。
原理
询问阶段协调者询问参与者是否可以执行事务参与者根据自身情况回复是否可以。准备阶段若询问阶段所有参与者都回复可以协调者发送预提交请求参与者执行事务操作并记录日志向协调者反馈结果。提交阶段根据准备阶段的反馈协调者决定提交或回滚事务并通知参与者执行。
应用场景类似 2PC但对系统可用性要求更高的场景。
优点能够减小参与者阻塞范围并能够在出现单点故障后继续达成一致。
缺点实现相对复杂性能开销较大引入预提交阶段在这个阶段如果出现网络分区协调者将无法与参与者正常通信参与者依然会进行事务提交造成数据不一致。
Paxos算法
Paxos是基于消息传递的一致性算法。 其实2PC和3PC都是分布式一致性算法的“残次”版本。Google Chubby的作者迈克·伯罗斯Mike Burrows说过这个世界上只有一种一致性算法那就是Paxos其他算法都是残次品。 原理通过多个节点之间的消息交互选举出一个主节点来决定提案的通过与否保证在多个节点中就某个值达成一致。主要角色有提议者、接受者、学习者提议者提出提案接受者决定是否接受提案学习者学习被选定的提案。
应用场景常用于分布式系统中的配置管理、分布式数据库的一致性维护等如ZooKeeper中就使用了Paxos的变种算法。
优点理论上能够保证在任何分布式环境下的一致性具有很强的容错性和可靠性。
缺点算法复杂理解和实现难度大性能方面在大规模集群中可能存在较多的消息交互影响效率。
Raft算法
Raft协议解决Paxos的实现难度。在Raft实现上其将角色简化为Follower、Candidate、Leader这3种角色本身代表状态角色之间进行状态转移是一件非常自由的事情。Raft虽然有角色之分但是采用的是全民参与选举的模式。在Paxos里更像是议员参政模式。
原理将节点分为领导者、跟随者和候选人三种角色。通过选举产生领导者领导者负责接收客户端请求并向跟随者同步数据保证数据的一致性。选举过程中节点通过投票来选出任期内的领导者。
应用场景广泛应用于分布式存储系统、分布式数据库等如etcd就采用了Raft算法来保证数据一致性。
优点相比Paxos算法更易于理解和实现在性能和可用性方面表现较好能够快速进行领导者选举和数据同步。
缺点在极端网络环境下如网络分区时间过长时可能会出现数据不一致的情况。
ISRIn-Sync Replicas同步副本
ISR机制解决了容错的2N1成本问题。
原理Kafka中的每个分区都有一个领导者副本和多个跟随者副本ISR 是与领导者副本保持同步的跟随者副本集合。生产者发送消息到领导者副本领导者副本将消息写入本地日志后会等待ISR中的所有副本都复制完消息后才向生产者确认消息发送成功保证消息的一致性。
应用场景适用于分布式消息队列系统如Kafka在处理大规模消息的生产和消费时并没有使用Zab或Paxos协议的多数投票机制来保证主备数据的一致性而是通过ISR机制来保证数据一致性并确保消息的可靠传递。
优点能够在保证数据一致性的同时提供较高的吞吐量和性能支持大规模的消息处理。
缺点ISR的管理和维护相对复杂当ISR中的副本数量较少时可能会影响数据的可靠性和一致性。
实用拜占庭容错Practical Byzantine Fault TolerancePBFT
实用拜占庭容错协议解决节点不可信问题拜占庭将军问题。Lamport证明在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的。因此在研究拜占庭将军问题的时候要先假定信道是没有问题的然后去做一致性和容错性的相关研究。
原理在分布式系统中节点之间通过消息传递进行通信PBFT通过节点之间的消息交互和验证在存在恶意节点拜占庭节点的情况下仍然能够保证系统的一致性和正确性。算法通过视图切换、预准备、准备、提交等多个阶段来达成共识。
应用场景对安全性要求极高的分布式系统尤其是存在恶意攻击风险的环境。如区块链、金融交易系统等。
优点能够容忍一定数量的拜占庭故障节点保证系统的安全性和一致性在联盟链等场景中有较好的应用。
缺点通信复杂度高性能开销大随着节点数量增加消息数量呈指数级增长会影响系统的性能和扩展性。
总结
本文梳理了一致性问题来源和解决模型以及经典常用的一致性算法感兴趣的小伙伴可以深入了解不同算法的具体落地应用。后续在深入大数据相关技术技术框架时遇到相关算法我们再深入看看。
