分布式系统的一致性级别划分及Zookeeper一致性级别分析

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 分布式系统的一致性级别划分及Zookeeper一致性级别分析

正文

数据更新后,如果能容忍后续的访问只能访问到部分或者全部访问不到,则是弱一致性。

最终一致性就属于弱一致性。

最终一致性

不保证在任意时刻任意节点上的同一份数据都是相同的,但是随着时间的迁移,不同节点上的同一份数据总是在向趋同的方向变化。

简单说,就是在一段时间后,节点间的数据会最终达到一致状态。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同,又可以区分为:

因果一致性(Casual Consistency)。如果进程A通知进程B它已更新了一个数据项,那么进程B的后续访问将返回更新后的值,且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问,遵守一般的最终一致性规则。

**“读己之所写(read-your-writes)”一致性。**当进程A自己更新一个数据项之后,它总是访问到更新过的值,绝不会看到旧值。这是因果一致性模型的一个特例。

**会话(Session)一致性。**这是上一个模型的实用版本,它把访问存储系统的进程放到会话的上下文中。只要会话还存在,系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止,就要建立新的会话,而且系统的保证不会延续到新的会话。

**单调(Monotonic)读一致性。**如果进程已经看到过数据对象的某个值,那么任何后续访问都不会返回在那个值之前的值。

**单调写一致性。**系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性,就非常难以编程了。


另外一种划分一致性级别的:

一致性是指从系统外部读取系统内部的数据时,在一定约束条件下相同,即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同,可以将一致性级别分为如下几种:

**  ①强一致性(strong consistency)。任何时刻,任何用户都能读取到最近一次成功更新的数据。
**  ②
单调一致性(monotonic consistency)。任何时刻,任何用户一旦读到某个数据在某次更新后的值,那么就不会再读到比这个值更旧的值。也就是说,获取的数据顺序必是单调递增的。

**  ③会话一致性(session consistency)。任何用户在某次会话中,一旦读到某个数据在某次更新后的值,那么在本次会话中就不会再读到比这值更旧的值。会话一致性是在单调一致性的基础上进一步放松约束,只保证单个用户单个会话内的单调性,在不同用户或同一用户不同会话间则没有保障。示例case:php的session概念。
**  ④
最终一致性(eventual consistency)。用户只能读到某次更新后的值,但系统保证数据将最终达到完全一致的状态,只是所需时间不能保障。

**  ⑤**弱一致性(weak consistency)。用户无法在确定时间内读到最新更新的值。

2. 共识(Consensus)

共识问题中所有的节点要最终达成共识,由于最终目标是所有节点都要达成一致,所以根本不存在一致性强弱之分。

例如,Paxos是共识(Consensus)算法而不是强一致性(Consistency)协议。共识算法没有一致性级别的区分。


3.线性化和可串行化的区别

读写操作的线性化与术语“原子一致性”同义,并且是Gilbert和Lynch 对CAP定理的证明中的 “C”或“一致性” 。我们说线性化是可组合的 (或“本地”),因为如果系统中每个对象的操作是可线性化的,那么系统中的所有操作都是可线性化的。

可串行性是ACID中的传统“I”或隔离。如果用户的事务各自保持应用程序的正确性(ACID中的“C”或一致性),则可序列化执行也保持正确性。因此,可串行化是一种保证数据库正确性的机制。

与线性化不同,可串行化本身不会对事务的排序施加任何实时约束。可序列化也是不可组合的。可串行化并不意味着任何类型的确定性顺序 - 它只需要存在一些等效的串行执行。

这些定义如此混乱的原因之一是线性化来自分布式系统和并发编程社区,可串行化来自数据库社区。如今,几乎每个人都使用分布式系统和数据库,这往往会导致过载的术语(例如,“一致性”,“原子”)。

4、zookeeper的一致性分析-单调一致性

很多文章和博客里提到,zookeeper是一种提供强一致性的服务,在分区容错性和可用性上做了一定折中,这和CAP理论是吻合的。但实际上Zookeeper提供的只是单调一致性。

原因

1. 假设有2n+1个server,在同步流程中,leader向follower同步数据,当同步完成的follower数量大于 n+1时同步流程结束,系统可接受client的连接请求。如果client连接的并非同步完成的follower,那么得到的并非最新数据,但可以保证单调性,也就是说,可获取的数据顺序是单调递增的。

2. 假设是follower接收到的写请求,则会转发给leader处理;leader完成两阶段提交的机制。向所有server发起提案,当提案获得超过半数(n+1)的server的ACK后,将对整个集群进行同步,超过半数(n+1)的server同步完成后,该写请求完成。如果client连接的并非同步完成follower,那么得到的并非最新数据,但可以保证单调性,也就是说,可获取的数据顺序是单调递增的。

用分布式系统的CAP原则来分析Zookeeper

(1)C: Zookeeper保证了最终一致性,在十几秒可以Sync到各个节点

(2)A: Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用Sync()

(3)P: 有2点需要分析的

  • 节点多了会导致写数据延时非常大,因为需要多个节点同步.
  • 节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入 observer节点缓解这个问题.

5、 结论

可以的出的结论是Zookeeper的一致性保证的是单调一致性,CAP原则中的C是强一致性。

总结

为了帮助大家更好温习重点知识、更高效的准备面试,特别整理了《前端工程师面试手册》电子稿文件。

内容包括html,css,JavaScript,ES6,计算机网络,浏览器,工程化,模块化,Node.js,框架,数据结构,性能优化,项目等等。

包含了腾讯、字节跳动、小米、阿里、滴滴、美团、58、拼多多、360、新浪、搜狐等一线互联网公司面试被问到的题目,涵盖了初中级前端技术点。

前端面试题汇总

JavaScript

性能

linux


相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
4天前
|
存储 监控 负载均衡
Zookeeper 详解:分布式协调服务的核心概念与实践
Zookeeper 详解:分布式协调服务的核心概念与实践
11 0
|
9天前
|
消息中间件 中间件 程序员
分布式事务大揭秘:使用MQ实现最终一致性
本文由小米分享,介绍分布式事务中的MQ最终一致性实现,以RocketMQ为例。RocketMQ的事务消息机制包括准备消息、本地事务执行、确认/回滚消息及事务状态检查四个步骤。这种机制通过消息队列协调多系统操作,确保数据最终一致。MQ最终一致性具有系统解耦、提高可用性和灵活事务管理等优点,广泛应用于分布式系统中。文章还讨论了RocketMQ的事务消息处理流程和失败情况下的处理策略,帮助读者理解如何在实际应用中解决分布式事务问题。
17 6
|
10天前
|
消息中间件 数据库 RocketMQ
可靠消息最终一致性分布式事务
推荐一个零声教育C/C++后台开发的免费公开课程,个人觉得老师讲得不错,分享给大家:C/C++后台开发高级架构师,内容包括Linux,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK等技术内容,立即学习
24 2
|
15天前
|
运维 程序员 数据库
如何用TCC方案轻松实现分布式事务一致性
TCC(Try-Confirm-Cancel)是一种分布式事务解决方案,将事务拆分为尝试、确认和取消三步,确保在分布式系统中实现操作的原子性。它旨在处理分布式环境中的数据一致性问题,通过预检查和资源预留来降低失败风险。TCC方案具有高可靠性和灵活性,但也增加了系统复杂性并可能导致性能影响。它需要为每个服务实现Try、Confirm和Cancel接口,并在回滚时确保资源正确释放。虽然有挑战,TCC在复杂的分布式系统中仍被广泛应用。
27 5
|
23天前
|
算法 程序员 分布式数据库
分布式一致性必备:一文读懂Raft算法
Raft算法是一种用于分布式系统中复制日志一致性管理的算法。它通过选举领导者来协调日志复制,确保所有节点数据一致。算法包括心跳机制、选举过程、日志复制和一致性保证。当领导者失效时,节点会重新选举,保证高可用性。Raft易于理解和实现,提供强一致性,常用于分布式数据库和协调服务。作者小米分享了相关知识,鼓励对分布式系统感兴趣的读者进一步探索。
114 0
|
26天前
|
算法 程序员
破解Paxos活性难题:分布式一致性的终极指南
Paxos算法是解决分布式系统一致性问题的关键,由Leslie Lamport提出。它涉及提议者、接受者和学习者三个角色,通过准备和接受两个阶段达成共识。然而,确保算法的活性,即在面对网络分区、竞争冲突和节点故障时仍能及时决策,是一个挑战。解决方法包括领导者选举、优化提案编号管理、使用超时机制和Fast Paxos等。实际案例中,通过领导者选举和超时机制,可以提高Paxos在应对网络延迟和冲突时的活性。
39 1
|
27天前
|
程序员
深入解析:分布式一致性的终极解决方案——XA协议
本文介绍了分布式系统中的两种一致性协议:2PC(两阶段提交)和3PC(三阶段提交)。2PC分为准备和提交两个阶段,确保所有参与者在提交前达成一致。3PC则在2PC基础上增加了一个CanCommit阶段,提高容错性和可用性,参与者在超时后可自行中断事务。选择协议需依据业务需求和系统特点,高一致性要求可选3PC,注重性能则选2PC。
28 0
|
1月前
|
算法
基于一致性理论的微电网分布式控制策略仿真模型【自适应虚拟阻抗】【simulink仿真】
基于一致性理论的微电网分布式控制策略仿真模型【自适应虚拟阻抗】【simulink仿真】
|
1月前
|
存储 大数据 Apache
深入理解ZooKeeper:分布式协调服务的核心与实践
【5月更文挑战第7天】ZooKeeper是Apache的分布式协调服务,确保大规模分布式系统中的数据一致性与高可用性。其特点包括强一致性、高可用性、可靠性、顺序性和实时性。使用ZooKeeper涉及安装配置、启动服务、客户端连接及执行操作。实际应用中,面临性能瓶颈、不可伸缩性和单点故障等问题,可通过水平扩展、集成其他服务和多集群备份来解决。理解ZooKeeper原理和实践,有助于构建高效分布式系统。
|
1月前
|
NoSQL Java 关系型数据库
【Redis系列笔记】分布式锁
分布式锁:满足分布式系统或集群模式下多进程可见并且互斥的锁。 分布式锁的核心思想就是让大家都使用同一把锁,只要大家使用的是同一把锁,那么我们就能锁住线程,不让线程进行,让程序串行执行,这就是分布式锁的核心思路
413 2

热门文章

最新文章