一. 架构介绍
从宏观上看，云溪数据库由两局部组成：下层的SQL引擎和上层的作为一个整体的分布式KV数据库。任何针对于数据库的SQL操作，通过SQL引擎的解析之后，都会把它们分解成一组组的kv操作，比方“select * from t”会被分解成scan操作，”update t set a = 1”会被分解成scan和put（conditionalPut）操作......事务次要是在上层的KV数据库对kv操作进行调度，以实现对更底层的存储引擎的并发读写。
二. Percolar事务模型介绍
云溪数据库的事务模型是从Percolator倒退而来。Percolator是构建在BigTable之上的，通过提供一个TSO地方授时服务和一个client lib来封装BigTable的接口，最终将BigTable革新成了一个带有ACID快照隔离语义的反对跨行、跨表事务的分布式多维map。
Percolator的特点是没有集中式的事务处理措施，比方核心事务管理器、全局死锁探测器......事务产生的锁也是和数据关联在一起分布式存储的。就事务的角度而言，全局的惟一单点就是TSO。因而Percolator模型具备良好的程度扩大能力。然而也正式这种无核心的实现形式，导致各种抵触解决都须要通过必要的网络交互来实现，所以事务的提早绝对较高。如果照搬这种实现形式，是无奈满足OLTP数据库对于高性能的事务处理的要求的。
三. 云溪数据库事务模型介绍
云溪数据库事务模型是从Percolator倒退而来的。一方面，它进一步实现了去中心化，通过应用HLC代替TSO，打消了最初一个单点，是零碎的程度扩大能力进一步提高；另一方面，它也做了许多致力来减小Percolator模型事务提早较高的弊病，比方具体的优化有异步开释锁 、 并行提交 、事务流水线、一阶段提交......
1. 规范工夫戳排序协定
云溪数据库通过MVCC+实现戳排序协定实现了SSI的事务隔离级别，上面简略介绍一下工夫戳排序协定。
在规范工夫戳排序协定中，每个事务都有一个惟一固定的工夫戳，在事务开始时获取，读、写、提交都在该工夫戳上进行。每个数据项放弃两个工夫戳，W-timestam示意胜利执Write(Q)的所有事务的最大工夫戳；R-timestamp示意胜利执Read(Q)的所有事务的最大工夫戳。
1：假如事务Ti收回read(Q)。
- 若TS（Ti）< W-timestamp(Q)，则Ti须要读入的Q值曾经被笼罩。因而read操作被回绝，Ti回滚。
- 若TS（Ti）>= W-timestamp(Q)，则执行read操作，R-timestamp（Q）被设置为R-timestamp（Q）于TS（Ti）两者的最大值。
2：假如事务Ti收回write（Q）
- 若TS（Ti）< R-timestamp(Q)，则Ti产生的Q值是先后面所须要的值，且零碎曾经假设该值不会再产生因而，write操作被回绝，Ti回滚。
- 若TS（Ti）< W-timestamp（Q），则Ti试图写入的Q值曾经过期。因而，write操作被回绝，Ti回滚。
- 其余状况，零碎执行write操作，将W-timestamp（Q）设置为TS（Ti）。
2. 规范工夫戳排序协定的缺点
规范工夫戳排序协定是一个无锁（free lock）的并发控制协议，读写操作都不须要加锁，这尽管能取得高性能，单却存在级联回滚问题和不可复原调度。
不可复原调度问题：当txn1回滚时，txn2原本也应该回滚，因为它读的A是txn1写入的。然而因为txn2曾经提交，所以没有办回滚，导致数据的一致性被毁坏。
级联回滚问题：txn2依赖txn1，txn3依赖txn2，可能会有txn4依赖txn3……当txn1回滚时，会造成大面积的事务回滚。
为了防止下面这两个问题，云溪数据库会对写入的未提交数据加排他锁，这样在相似下面的场景中，txn2和txn3在读A时会被阻塞，直到txn1提交才回放行。这样就不会产生级联问题和不可复原调度问题。
3. 云溪数据库对规范工夫戳排序协定的优化
工夫戳排序协定是一个比拟乐观的协定，它假如抵触很少产生，因而在事务开启的时候就确定事务也能够在这个工夫戳提交，工夫戳排序的抵触解决规定就是建设在这个前提之上的，任何呈现违反了这个规定的状况都会导致事务回滚。因而在高并发高抵触的场景中，工夫戳排序协定的事务回滚率和回滚代价都是比拟高的。为了升高回滚率，云溪数据库引入了工夫戳forward(push)机制，规定如下：一个事务保护两个工夫戳，readTS和writeTS。事务在readTS上执行所有读取操作，以获取始终性快照；所有的写操作在writeTS产生，当遇到RW抵触时，W事务的writeTS forward到抵触工夫戳的ts.next，而后继续执行，在必要时刻或者最终提交时进行查看尝试将readTS refresh到writeTS，如果胜利，则事务提交，否则事务回滚。
在这个机制之下，当遇到上图的场景时，因为txn1在commit时能把它的readTS refresh到writeTS，所以txn1还是能够提交。然而在规范的工夫戳排序协定中，因为txn1 write(B)时发现B的R-Timestamp大于本人的ts，所以事务txn1须要回滚。
4. 云溪数据库事务模型总结
· 没有单点和集中式解决，扩展性好
· 因为同步点机制，任何抵触都须要拜访同步点来确认抵触的最终后果，网络交互多
· 锁和数据一起存储，每个写操作都会给存储引擎产生两三倍的写入压力，抵触解决流程波折
· HLC的时钟偏移太大，在某些场景下对同一数据的W、R容易导致重试
· 工夫戳排序并发控制协议比拟乐观、导致事务容易重试和回滚，且代价较大