经常有人在了解某分布式数据库采用了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。如此数据的安全性和业务的连续性都有保障。这就是在存储引擎中用多数派一致性协议的基本价值。

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