02｜强一致性：那么多数据一致性模型，究竟有啥不一样？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了分布式数据库的强一致性概念及其在实际系统中的应用。从数据一致性和事务一致性两个方面入手，分析了强一致性的特点及应用场景。文章首先介绍了数据一致性的两个视角：状态一致性和操作一致性。在状态一致性方面，以MySQL全同步复制和NoSQL最终一致性为例，分析了强一致性和弱一致性的特点及应用场景。接着从操作视角讲解了五种常见的一致性模型，其中以“写后读一致性”为例，生动地阐述了其在实际应用中的效果。通过对不同一致性模型的比较和解析，读者可以更好地理解强一致性的概念及其在实际系统中的运用。文章内容深入浅出，逻辑清晰，为读者提供了全面的分布式数据库一致性知识概览。 文章还介绍了单调读一致性、前缀一致性、线性一致性和因果一致性等概念。通过生动的案例和图示，阐述了这些一致性模型在实际场景中的应用和实现方式。特别是对于线性一致性和因果一致性，文章深入探讨了其在分布式系统中的实际应用和工程实现，为读者提供了深入的技术视角和实践经验。总的来说，本文对分布式数据库一致性问题进行了全面而深入的探讨，为读者提供了宝贵的技术参考和实践指导。 文章通过对一致性模型的介绍和比较，使读者更好地理解了强一致性的概念及其在实际系统中的应用。同时，还提出了一些思考题，引发读者对Paxos一致性协议与数据一致性的关系进行深入思考。整体而言，本文内容丰富，逻辑清晰，是一篇值得深入阅读和思考的技术文章。
《分布式数据库 30 讲》，新⼈⾸单¥59
全部留言(45)
- 最新
- 精选
- chenchukun从状态和操作两个视角看待副本的一致性这点讲的很透彻，之前都没有考虑过这点。 从状态视角看，是不是只有全同步这种方式实现了强一致性，即使像paxos、raft这些实现了操作上线性一致性的算法，从状态视角看也不是强一致的。 然而全同步降低了系统的可用性，paxos、raft不保证所有节点状态的一致，而是通过额外的算法来保证操作视角的一致性，同时提高了系统的可用性。
作者回复: 你好，你的理解非常准确，点赞
2020-08-1372 
峰感觉很长一段时间都被翻译给耽误了，ACID的C是一致性，强调的是数据的状态变迁的特性，CAP里的C共识，强调的是多副本条件下，多个节点怎么就数据的变动，达成共识，统一修改。 而paxos，raft是在牺牲一定A的条件下（多数节点存活才ok），实现C的一种多节点的通信协议，Paxos貌似不需要主节点这个角色去统一时序，Raft，zab需要主节点，它们都是实现线性一致性的方式。作者回复: 你好，其实CAP的C也是Consistency，是多副本、单操作的数据一致性；而ACID里的C是指单副本、多操作的事务一致性。Paxos这类共识算法，可以看作是复制协议的一种，虽然有时也叫做一致性协议，但这个一致性是指Consensus。Consensus是实现数据一致性目标下的具体技术，但并不是唯一的选择。采用主从复制也可以达到同样效果，比如04讲会提到的PGXC风格的分布式数据库就是采用主从复制的方式。
2020-08-12547
微思CAP的C是多副本、单操作的数据一致性；而ACID的C是单副本、多操作的事物一致性；作者回复: 正确������
2020-09-0726
南国老师，其实我还是没太懂前缀一致性和因果一致性的区别，前缀一致性是某些关系可比，并发的不可比，不也是一个偏序关系嘛？我还一直觉得这两个是一回事呢。作者回复: 你好，简单的说，因果一致性是靠逻辑时钟确定偏序关系，不需要应用介入；而前缀一致性靠事件之间显式声明的依赖关系，可以在应用层处理
2020-08-1520
孟磊和那些偏理论的课程不同，能感觉到作者对于分布式数据库的理解非常深刻，且结合了实际的金融业务，有点追剧的感觉了。 能不能拿出OceanBase goldendb这类领头羊产品给大家讲讲选型要注意的？作者回复: 你好，孟磊，谢谢你的鼓励。我在构思这个专栏的时候，就订下一个目标，就是把学术的东西和目前工业界的实践联系起来，再落到具体的工作中，比如技术选型。所以，能得到你的肯定，我很高兴。当然，对产品的关注是必不可少的，从04开始的每一讲我都会对领头羊产品做局部设计上的拆解，并且比对不同方案的优劣，不过这个领头羊并不固定，因为我想向你介绍最有特点的设计。希望你能喜欢这种组织方式，后面的课程中，期待还能收到你的反馈，我们结合问题一起讨论。
2020-08-1718
tt我觉得数据一致性是从数据的用户视角出发对数据属性的描述，而paxos协议是达成共识的过程的一种实现方式，是从数据的生产者或者维护者角度出发的作者回复: 说的很好
2020-08-1312
扩散性百万咸面包强一致性和弱一致性的定义感觉还是不够准确。 1. MySQL这个例子是全同步复制，实际上Raft也是强一致性算法，但它在应答客户端的请求成功后并不保证多副本之间暂时的数据一致性，有可能数据存在不同。只不过在收到读请求的时候会转发给Master，保证强一致性。 2. 弱一致性是说有可能不同用户看到的state不一样，而不仅仅是副本之间数据不一致。可能A先比B发起请求，但是是B的修改却被A覆盖了 如果按作者的作者回复: 你好，关于第一点，我再补充一下。 Raft是多数派协议，从写入成功那一刻的数据状态来说，肯定不是一致的。不过，通过操作方面的封装，约定由主副本对外提供服务，所以不会体现出副本间的差异。一致性模型，除了副本的状态，还要看读写操作。最终一致性的定义，其实只是描述了副本的状态而已。我认为，一致性模型，主要还是从读写操作的效果来分析，也数据副本的一致性有关但不是强依赖。比如，如果不使用Raft，用半同步，也可以做到线性一致性。 第二点，我没有完全理解，咱们可以继续探讨
2020-08-1236
李鑫磊线性一致性和状态一致性（ACID 中的 C），到底有啥不一样？我理解的线性一致性是最终一致性里面最强的一致性模型。线性一致性和状态一致性的区别在于：读的那一瞬间，数据在多个副本之间是不是一样的；一样的就是状态一致性。线性一致性，我的理解：可以在多个数据副本之上抽象出一条逻辑上的时间轴，数据按提交到系统时的时间，从左到右依次排开；数据刚排在时间轴上时是灰色的，只有数据在多个副本之间同步完成，数据在时间轴上的点才回被“点亮”；读的时候，只能读到这样的数据：其在时间轴上已经被“点亮”了，且其左边的所有数据都已被“点亮”了。Ivan，你说是不是这样滴？作者回复: 你好，李鑫磊，你把多数据副本的同步过程说的很形象。不过ACID里的C是说事务一致性，和数据一致性还是不同的，03讲有具体的介绍，我推荐你读一下。数据一致性中还有一点很重要，就是操作之间的先后次序判断，这也是为什么我们说，线性一致性必须要有全局时钟支持。也许02中的表述还不够直观，我建议关注一下第12讲，说不定会有收获
2020-08-184- 扩散性百万咸面包Paxos本质上是共识算法，主要是用来维护数据库副本的一致性/权威性。而今天讲的一致性是从用户角度来谈，而不局限于是数据副本。 同时，今天讲的一致性也需要共识算法Paxos，Raft来保证。比如选举，如何才能选出正确的Leader等等。
作者回复: 高级别的一致性模型，可以基于Raft算法复制，但使用主从复制也是可以的😊
2020-08-124 
xzy数据一致性分为：状态一致性和操作一致性 从数据状态的角度看分为：强一致性和最终一致性 从操作的角度看又分为：写后读一致性、单调读一致性、前缀一致性、因果一致性、线性一致性等等 写后读一致性：自己写入的数据，立马就能读到，可以通过读负责写入的节点解决 单调读一致性：读到新值后，又读到旧值，好像出现了“时光倒流”，可以通过读固定副本解决 前缀一致性：B评论了A评论，先看到B评论，后看到A评论，可以通过在事件上增加显示的因果关系，系统可以据此控制其他进程的读取顺序 线性一致性：整个系统表现的好像只有一个副本，所有的操作都记录在一条时间线上，并且被原子化，这样任意的两个事件都可以比较先后顺序 因果一致性：依赖逻辑时钟，实现偏序关系 因果一致性是靠逻辑时钟确定偏序关系，不需要应用介入；而前缀一致性靠事件之间显式声明的依赖关系，可以在应用层处理 一致性模型，出了看数据状态，还要看读写操作：RAFT协议，从状态的角度看是最终一致性，从操作的角度看是线性一致性。 CAP中C的是多副本单操作一致性，ACID中的C是单副本多操作的一致性。作者回复: 总结的很好，点赞
2022-11-12归属地：北京3
