cockroachDB,yugabyteDB,kudu, TIDB 这些都是 参考了google spanner 论文 的开源实现.

这些开源实现，包括mongodb 都看过源码架构，看过很多相关的paper,以及重点看了分布式事务的实现: 原子性，隔离性， linearizability(外部一致性). 注：mongodb 虽然起源于no-sql , 但是mongodb4.0 之后的版本 已经不是no-sql 了， 可以与以上任何一位new-sql 代表PK.

这里重点说下cockroachDB 与yugabyteDB 这两款比较喜欢.

先统一下概念：1. table 中的数据 不管是是以 hash 方式还是以range 方式切分，切分之后的单位叫tablet(cockroachdb 里叫range , TIDB 叫partion, yugabyteDB 与kudu 里叫 tablet, mongodb 里叫chunk).

2. serializability& linearizability :这是分布式数据库的黄金标准,也就是google spanner paper 里说的外部一致性. 这里的serializability 是事务隔离的最强保证, linearizability 是CAP 领域 对于C 的最强保证. 这两个概念是正交的,linearizability 在分布式领域中更加关注single-operation,single-object, real-time order ; 而在分布式数据库中, 每个事务的提交可能会修改多个数据对象, 这些数据对象有统一的版本号，如果我们把这些数据对象看成一个整体且是原子的，然后再对这个整体 施加 linearizability 约束就达到了 serializability & linearizability 标准.

3. CAP-consistency : 这里指CAP 领域中的一致性， 不是ACID 中的C。

4. node : 物理机器，容器或者一个进程。

对于serializability & linearizability 标准, 目前这些开源实现里面 一个也没有达到, 只有cockroachDB 在没有 google spanner 原子钟的情况下，是最接近这个黄金标准的. 随着云硬件基础设施的完善，相信会提供出像google 的原子钟及true time api, cockroachDB 也无缝支持. 刚开始我对cockroachDB 的CAP-consistency 有很大误解，认为在没有原子钟及TSO 中心授时 下，会出很多问题, 会有stale-read , 会有性能问题，会破环serializability , 其实不然. 目前cockroachDB 目前在这方面的实现已经足够健壮，具体细节后面再讲.

从架构上讲:

共同点 :

大致都可以分为两层，上层是SQL，下层是 KVStore(支持事务API) . 所有table 数据划分为tablet(比较喜欢这个命名，没有歧义)存储在KVStore 层. 每个tablet 会有一个独立的raft group 来保证 各个replica 的数据一致. 每个raft goup 会有一个leader lease 负责这个tablet 数据的读写.

上面的设计思想应该都是inspired by google spanner . 除了上面这点相同之处， 其余的部分的设计有很多不一样.

cockroachDB 的设计:

1. cocokroachDB 设计之初就是需要Geo-Distributed 的，整个系统没有任何单点, 没有TSO ,都不存在一个单点来检测死锁. 另外table 的scheme 信息 以及tablet 的路由信息都会放到KVStore 上. tablet 的路由信息靠Gossip 同步. cockroachDB 的时间戳服务由 每个node 上的HLC 提供.

cockroachDB 只有一个进程, 但是其SQL 层与KVStore层分界清晰，完全可以把KVStore 独立出来， 这样上层就是一个Dist SQL 层，下层就是支持分布式事务的KVStore层，在cockroachDB 的源码里叫KV-DB. 所以cockroachDB 的部署非常简单.

cockroachDB 里的 KVStore 层提供了一个支持分布式事务的API 接口给SQL 层, 让SQL层感觉下面是一个单机的存储引擎. 所以 cockroachDB 完全可以单机部署, 副本集部署,很好的适配了不同规模的企业.

另外cockroachDB 开发了自己的存储引擎Pebble, 会替换掉RocksDB, 后面可以基于这个Pebble 做很多优化.

2. 每个tablet 的数据及其raft log 在 cockroachDB 中虽然是逻辑上独立的, 但物理上并不独立， 在一个node 上的所有tablet 数据 及raft-log 都是放在一个rocksDB 实例上的，这样弊大于利,不过有提到将这些数据独立的计划.

TIDB 是 所有tablet 的raft-log 放到一个rocksDB 实例，所有tablet 数据放到另一个rocksDB 实例. kudu 是每个tablet 的raft-log 独立,放在不同的文件中，kudu 有自己的存储引擎.

而yugabyteDB 的KVStore层源自kudu ，但在上面做了大量优化, yugabyteDB 中每个tablet 的 raft-log 放在独立的文件中，可以hash 到不同disk 上, 每个tablet 的数据有一个独立的rocksDB 实例，这样直接把rocksDB 的 wal 关掉，避免了 wal-log 的两次flush disk ，这样每个tablet 数据其实是物理隔离的，这样在很多方面都有性能优势. 就是程序变复杂了，比如:在tablet split 和merge 时候需要做的更多. 当然这种物理隔离会带来更多的想象空间, 以后一个table 可以是行存也可以是列存, 支持多个存储引擎.

多说一句：yugabyteDB的设计也很优秀，主要是C++，比较喜欢. 其TSO 与cockroachDB 一样也是用的HLC ,mongodb 也是, HLC 是大趋势。另外yugabyteDB 的SQL 层是直接在postgreSQL 上直接改的, 下层KVStore 层 源于kudu,在源码里叫TServer. TServer 启动时，会去加载postgreSQL 程序作为一个子进程启动, 这样 SQL 层运行在一个子进程里，TServer也是一个进程，他们之间通过local socket 通信. 会有另外一个Tmaster 会存储tablet 的路由信息，表的scheme , 统计上报信息 等. Tmaster 也是tablet 调度的发起者, 但其并不提供TSO 服务.

cockroachDB 分布式事务: 分布式事务的实现是整个系统中最复杂的，也是必须要保证数据库正确性的.

1. 原子性: 其他开源实现原子性的保证都是基于2PC,看Percolator 的论文就非常清楚了，都大同小异, 但是cockroachDB 做了大量优化，引入了并行提交，让一次分布式事务的延迟优化到了理论上最小值，也就是一次raft consensus 的延迟.另外对于交互式事务，或者说一个事务由多条DML语句的事务，引入了pipeline ，实现了asynchronous raft consensus.

引入了这两个特性后，我们做了测试，极大降低了事务的延迟,比其他几个开源实现性能都要好.

2. 隔离性 ：cockroachDB 实现了serializability . 也是其默认级别，以前的版本实现了SI,但在

新的版本中删除了，因为SI 会有Write-skew 问题，在客户那里出过问题. 其SSI 的实现其实是MVTO 的变种，然后inspired by Write-SI (论文：A Critique of Snapshot Isolation)，虽然MVTO 属于乐观并发控制，但是cockroachDB 为了防止事务不断的restart , 加入了等待机制. 具体的性能数据可以参考其官网数据.

注意的是: cockroachDB 的DML 操作并不会缓存在buffer 里，等 commit 时候 再 laid-down到KVStore 上, 而是事务只要发起DML，就会将相关数据laid-down 到KVStore 上，这点不同于TIDB 与yugabyteDB 。另外 cockroachDB 的分布式事务的协调者 在源码里叫做TxnCoordinator。每次事务都是生成一个TxnCoordinator 对象 来发起2PC, 而TxnCoodinator 其实是在KVStore层.

3. CAP-consistency :

cockroachDB 的一致性保证基本接近 linearizability .

cockroachDB 采用了HLC 来为 其各种读写事件定序，HLC 本质上是lamport logical clock ,且 HLC 是严格单调递增的, 所以很容易对那些由内部因果关系的事件定序。

对于外部因果关系的追踪就需要靠HLC 的 physical clock 部分. 而这个HLC 的physical clock 部分来源于 机器的wall-time。 由于各个机器的物理时钟(物理时钟一般会通过NTP 校准) 是不准的，会有clock-skew , 但cockroachDB 会假设各个 clock 之间 存在一个max clock offset bounds.

如果各个机器的物理时钟在这个max clock offset bounds 内，则cockraochDB 就是可以保证serializability & linearizability, 达到与google spanner 一样的标准, 除了在一些极端情况下，会出现causal reverse, 不满足linearizability, 对于绝大多少应用，这种情况基本不会出现.

如果这个条件不满足，可能会出现stale-read , 但是其serializability 是依然可以保证的.

总之: 即使在机器物理时钟异常情况下，cockroachDB 也是至少可以保证serializability 与内部因果一致的, 其实这已经是非常强的保证了. 另外GPS 原子钟 将来云上应该会提供.