- 什么是强一致性 -
说到zab到底是强一致性,还是最终一致性,相信大家一定能搜到大量互相打架的文章。在评判这个问题前,咱们在回顾下Consistency(一致性)、Consensus(共识)。这两者间的关系如下:
共识是一种数据同步过程,一致性是数据同步状态。所以一致性包含了共识。 分布式架构设计篇(十三)-一致性算法概述
其次,在了解一个知识,单单Raft、Paxos都是共识算法,共识算法只能提供基础,要实现线性一致还需要在算法之上做出更多调整。所以说共识和一致性具备一定的一体两面性。
在看 CAP 的 一致性 和 ACID的一致性,我们可以在2002年CAP理论的论证论文《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services》中看到两者的关系。在论文中我们可以清晰的看到 CAP关于一致性的完整称呼叫"Atomic Consistency",即原子一致性:原子一致性是针对单个请求/响应操作序列的属性,而数据库一致性是事务的组成,包含了数据库概念中一致性和原子性。
在CAP论文中对一致性缺少了对隔离性的说明,而隔离性是并发控制的体现,所以我们还得挖挖原子一致性,原子一致性又称为线性一致性(linearizability)、立即一致性(immediate consistency)、外部一致性(external consistency )、严格一致性(Strict Consistency)。线性一致性由Maurice P. Herlihy 与 Jeannette M. Wing共同提出,其中跟并发控制的内容比较绕,最后笔者翻阅了蛮多学术论文,先给大家一个自己的结论:线性一致性是读取和写入寄存器的新鲜度保证(recency guarantee),它不会将操作组合为事务,因此它存在写偏差等并发控制问题: 如果读取请求与写入请求并发,则可能会返回旧值或新值。
在数据库中,为了提高数据库对外性能,通常采用写MVCC等。而且生产实践中,我们通常认为数据库是强一致性的,而数据库的隔离级别通常默认是RC注1,存在幻读等并发控制问题。
注1:MySQL的RR其实是利用MVCC + RC来实现。
综上所述,我们可以知道强一致性具有一定的模糊性和习惯性,因此我们可以认为强一致性是一种统称,那么我们怎么判断强一致性和最终一致性呢?这需要我们通过场景来实际分析。
- ZooKeeper 一致性保证 -
ZooKeeper 是一项高性能、可扩展的服务。读取和写入操作都设计为快速,尽管读取比写入快。这样做的原因是:在读取的情况下,ZooKeeper可以提供较旧的数据,这反过来又为ZooKeeper提供了一致性保证:
总结一下:Zookeeper并不保证读取的是最新数据:实现了CAP中的A-可用性、P-分区容错性、C-写入强一致性,丧失了C-读取一致性。
- ZooKeeper 的一致性确定 -
在ZooKeeper中,为了追求更高的性能,对Paxos做了简化落地,并称之为ZAB算法:
ZAB的算法在并发控制中:如果读取请求与写入请求并发,未参与过半写入的节点对外提供的数据可能是历史数据,造成了客户端的读取不一致性,新增加了这个级别的并发控制现象。
从 章节一 我们也知道 ,不管是传统数据库,还是线性一致性都存在一定的并发控制问题,所以是否可以认为并发控制的隔离性是可以接受一定的可损性?我们在从一些案例来ZooKeeper到底是强一致性的CP,还是最终一致性的AP:
通过上述案例,再加上我们也知道ZooKeeper在分布式系统中是充当协调器的存在,在大部分使用场景中都是CP的表现,那么这时结合 第一小节的总述和这边的案例,我们是不是可以认为顺序一致性等于强一致性?笔者通常认为在分布式系统大部分场景中,只要达到线性写,顺序读这样的级别就可以认为是强一致性。
- 作者介绍 -
林淮川
毕业于西安交通大学;奈学教育首席架构师,教学教研负责人;前大树金融高级架构师、技术委员会开创者、技术总监;前天阳宏业交易事业部技术主管;多年互联网金融行业(ToB)经验。