容易让人误解的分布式概念1:数据一致性

天下观查 2024-02-21 23:57:32

在昨天在整理OceanBase和TiDB/CRDB中一致性协议区别时,说到了数据一致性,当时就想起了以前遇到的让人啼笑皆非之事。

经常有人在了解某分布式数据库采用了raft/paxos以后,又知道这些协议是多数派一致性时,就惊讶的合不拢嘴,发出惊呼“这个分布式数据库竟然不是强一致性,这怎能用在银行核心的交易系统呢,银行疯啦么~~!”

显然,发出这一惊呼的人,把分布式数据库中的两个数据一致性搞混了。现在的新技术存在多层次、复杂的概念,部分原理相近,甚至定义词汇都一样,但是功能却完全不同的技术点,这也难免让人搞混。

数据一致性在分布式数据库中有两个概念:

其一,分布式事务中的数据一致性,而且几乎所有的分布式数据库在这里都是强一致的;不用怀疑,否则那真的没办法支撑准确的交易业务。

其二,是存储层同一份数据多个副本之间的数据一致性。在分布式数据库中,为了实现高可用性,设计了数据的多副本分散存储,因此引入了分布式一致性协议paxos/raft等多数派算法进行同步复制。一般也只有在存储层才用到了这些协议。

经常有人把这两个概念混为一谈,所以才会发出那样啼笑皆非的惊呼。

我们可以用cockroachdb的insert流程简单看一下原生分布式数据库在面对分布式事务时,整体事务过程和存储层是如何配合保证数据一致性的。(为什么我总是用crdb和ob、tidb三者比较呢?因为crdb有一个非常有意思的特征让我很早以前就关注了,就是彻底去中心化的架构设计。Crdb中完全没有管理节点,所有节点对等部署,这个我们留着后面在展开介绍。)

如上图有a,b,c...g共7个节点的crdb集群,根据无中心的特性,应用可以连接任意节点,发送SQL请求。

假设,其连接节点d发送了一条SQL,向表Table中插入了3条数据。而恰好3,4,5这三个值被分到3个不同的range切片中存储,这3个切片也可能不在同一节点上(其实在不在同一个节点上,事务流程基本没差别),这就是典型的分布式事务场景。

被连接的节点d会充当事务协调节点的角色,对SQL进行解析,将数据拆分,发送给3个range切片的leader副本所在节点(即b,d,f节点),由每个leader执行各自数据的写入操作。

只有当bdf三个节点都反馈“写入完成”,协调节点d才会反馈客户端数据写成功!为了保障分布式事务的强一致性,数据库需要用到事务授时/ID、两阶段提交、时间戳排序、锁等多种技术融合在一起。

那么,bdf三个节点是如何实现“写入完成”的呢?这就是存储引擎的工作,也是前面说的常被人误解的地方。

用其中节点b执行put(3)做示例,执行模块向对应的切片leader(副本)发送写入请求,leader接到数据写入时,会判断这行数据操作是否存在冲突,不冲突那么他就将数据写入本地存储中。

Leader写完后,会通过raft协议同时并行向2个follower副本(a、c节点)同步日志。leader只要接收到任1个follower“复制完成”,其就可以向上层(执行模块)反馈“写入完成”。

所以,如果某一个节点故障,丢了一个follower副本,那么对存储引擎的“写入完成”没有任何影响,如果丢失的副本正好是leader副本,那么也能保障至少有一个follower存储已提交的数据,并通过重新选主成为新的leader。如此数据的安全性和业务的连续性都有保障。这就是在存储引擎中用多数派一致性协议的基本价值。

当然,以上演示仅简要说明了数据一致性在两个层次中的简要概念,实际运行过程中有非常繁琐、复杂的工程逻辑在里面,并且不同的数据库处理细节也完全不同。在这里我们只需要知道分布式数据库中有“存储层同一份数据的多个副本数据一致性”和“分布式事务处理中的多份(行)数据一致性”,两者有互相关联,但又完全不同。

0 阅读:14

天下观查

简介:宝哥在职场混迹十多年,分享如何轻松上升管理团队