基础架构

最顶层是sql层，cockroachDB的sql层和传统关系型数据库的概念一致。

cr2-1.png

cr2-2.png

每个Range有3个副本，节点和Range可以根据不同的物理网络拓扑结构进行编排，从而在可靠性和性能之间折衷。 N为总副本数，F为可容忍故障副本数，则N=2F+1。

CockroachDB key可以是任意字节数组。key有两种类型：系统表key和用户表key。
系统表key被用于内部的数据结构和元数据。用户表key包含用户表数据。
系统表key和用户表key通过前缀区分。系统表key始终小于用户表key

多版本数据

维护了数据的历史版本，版本之间通过事务的提交时间戳区分。制定快照时间可读取此时间戳之前的最新版本数据。所有的版本都有一个最小的期限。当系统进行compaction时候，过去的版本会被系统回收。用户可以自行制定数据的有效期。

无锁分布式事务

两种食物隔离级别
快照隔离级别
串行化快照隔离级别

SI性能好，实现简单，但是存在写偏序问题。
tip（写偏序（Write Skew）也是一致性约束下的异常现象，即两个并行事务都基于自己读到的数据集去覆盖另一部分数据集，在串行化情况下两个事务无论何种先后顺序，最终将达到一致状态，但SI隔离级别下无法实现。下图的“黑白球”常常被用来说明写偏序问题。）

cr2-3.png

相比而言，SSI的实现上稍微复杂一点。
SI和SSI都要求缓存该Range上发生的读操作结果，如果写操作时间戳比最近一次读操作时间戳要小，则写操作失败。因此，每个Range都有一个缓存（timestamp cache），保存该Range中key被读取的最新时间戳。
依据队列的方式，最老的时间戳会被优先剔除
每个事务开始的时候都会被分配一个随机优先级和“候选时间戳”（就是当时本地的时间戳），如果没有事务冲突的话，在事务完成后，这将成为事务的最终提交时间戳。

在跨多个节点的分布式事务执行过程中，SI允许事务的候选时间戳变大，而SSI不允许。（todo，为啥呢？是因为它是一系列事务串行合集，只会回滚，不会变化）

每个CockroachDB，维持本地的HLC（混合逻辑时钟），当发送数据的时候，会获取本地的时钟作为时间戳，接受事件时，会根据接受到的事件的时间戳来更新本地的HLC。
换句话说，每个节点维护自己的时间戳，当发生事务交互（读写操作时），都会更新本地的HLC，一是用来做事务冲突处理，二是保证之后的事务请求时间戳都大于当前的事务请求时间。事务冲突处理有两种方式，重启和中断，是根据事务类型来做区分。

reference

关于SSI实现，可参考Cahill论文《Serializable Isolation for Snapshot Databases》
关于SSI如何解决读写冲突，可参考论文《Fast Distributed Transactions for Partitioned Database Systems》
关于SSI实现主要参考Yabandeh 的论文《A Critique of Snapshot Isolation》。