About the author: Li Haixiang, screen name "that the deep blue sea," Tencent financial cloud database technology experts. Renmin University of China School of Information Engineering Master of Business mentor. Author of "art database transaction processing: transaction management and concurrency control", "art database query optimizer: Principles and resolve SQL performance optimization", "big data management," acclaimed.
Share text: May 8, 2019, Tencent Tencent TDSQL team brings the latest database technology core database technology for the Chinese Assembly DTCC: TDSQL original global read consistency technology.
Li Haixiang Tencent expert engineers on DTCC on the theme "Global Tencent TDSQL read consistency" technical content sharing. Consistency and distribution of this share, based on the core technology database transaction processing concurrent access control technology and distributed system consistency CAP theory, TDSQL original algorithm provides a comprehensive solution to read consistency, was distributed transactions the consistency of systems of unified together.
The following are the main contents of this share, from the perspective of the following eight overall share of global consistency of past lives, a bright future.
Transaction processing database technology to solve the problem?
Distributed transactional database, the emergence of a new problem? - Read semi-submitted data anomalies
The industry is how to solve the problem of reading and a half has been submitted abnormal data?
Distributed transactional database, read half solved submitted data anomalies, once and for all it?
TDSQL transaction models
What is global consistency?
TDSQL is how to solve a variety of data anomaly?
Looking to the future
First, transaction processing database technology to solve the problem?
It is a highly concurrent database system, all the operations to be bound by transactional semantics. And semantics, the performance of the transaction for the transaction of four properties, ACID. And a database system, its core technology, is transaction processing technology, in order to protect ACID, using a variety of complex database technology, which is the core of the core technology of concurrent access control algorithm.
Transaction processing technology, there are two mind: First, the correctness of the data, the second is complicated by high efficiency.
Operation of the database, to simplify the semantics of SQL statements, only read and write operations two kinds. Concurrent operation is concurrent read and write operations, the combination into four categories: read, write, write, read, write. Among them, read, write, read, write three kinds will produce a variety of "data anomalies." Common data anomalies shown in Figure 1, the occurrence of these data anomalies, we can not guarantee the accuracy of the above data.
So much data anomalies (Figure 1 lists 11 kinds), will bring the problem? Its performance is in the data item, a "inconsistency" phenomenon logically should not be there. Say inconsistent, abstract difficult to understand, do not see the harm, so we used "dirty read data anomalies" give a simple example:
A liar T2 transfer 1000 yuan to the transaction T1, T1 check their account transactions, accounted for 1,000 yuan, then the transaction T1 to T2 liar sold a piece of clothing, then roll back the transfer of $ 1000 to get the clothes after the operation liar T2 and then fled. Transaction T1 has neither the money also lost clothes, a great loss. So to avoid such an exception occurs.
Therefore, the transaction mechanism of the database is to prevent commercial transactions (concurrent interactions) the emergence of various trade anything party damage occurred.
So, transactional database proposed a variety of concurrent access control algorithm (Figure 2) and other related technologies, to ensure that normal business transactions. The term database with speaking, is to ensure that the four ACID properties. Various algorithms in FIG. 2, the single isolation level serializable transaction isolation level, various types of data can be ensured in FIG abnormality does not occur. (Small problem, please consider: distributed transactional database concurrency control algorithm can ensure that all the data in Figure 1 exception does not happen?)
Second, distributed transactional database, the emergence of a new problem? - Read semi-submitted data anomalies
In the financial payment and other business scenarios, reconciliation services, payment system is the most important part, but also to ensure the transaction, financial security is the last line of defense. Involved in financial services, it must be reconciled.
Using a database to make reconciliation, FIG. 3, there are two physical nodes, Na and Nb are two accounts X and Y (X and Y also represent the account balance), now a first write transaction to the account from the X Y account transfer $ 10, when the completion of this write transaction commit nodes Na, Nb but not yet submitted to the node (e.g., network delay occurs, load is heavy or the node Nb is still not able to perform a transaction commit operation). At this time, another distributed transaction do read transaction reconciliation operations which read a value "X-10" have been presented in the nodes Na, Nb and the read node is a "Y" (not read uncommitted ), the general ledger for the "X-10 + Y", the data is inconsistent, because 10 dollars less total accounts. According to the database system can not tolerate this kind of thing happen.
对于任何一个分布式事务型数据库，如果基于封锁并发访问机制实现并发事务的可串行化调度，是不会存在这里所讨论的问题的。其原因在于：一旦Na节点写完毕数据，则表明Nb节点至少在Y账户这个数据项上施加了写锁，而新的对账读事务是不能读取Y数据项的值的，其只能等待，因此不会发生对账不平的问题。腾讯TDSQL就是这样的，换句话说，没有实现可串行化的数据库，大概率会存在读半已提交数据异常（小问题，请思考：为什么这里说大概率呢？答案参见图4中的2次读算法）。
但是，如果纯粹使用封锁并发访问控制机制实现可串行化，事务处理的并发度降低，分布式数据库的事务处理吞吐量就会底，这违背了事务处理技术的另外一个初衷：高效。所以类似TDSQL的分布式数据库，用户通常不使用可串行化隔离级别，原因就在于想要使得数据库高效。而如OceanBase、Oracle等数据库，干脆没有实现可串行化隔离级别，而是直接把出现数据异常的危险抛给了用户。
现在，我们再来讨论一下，TDSQL会不会出现“读半已提交数据异常”？
TDSQL除了支持可串行化隔离级别外，还支持可重复读（RR）、读已提交（RC），但这2个隔离级别，同另外一种并发访问控制算法、MVCC技术紧密绑定，绑定的原因，是为了提高并发度，使得读写、写读操作互不影响。就是在MVCC机制下，TDSQL出现了“读半已提交数据异常”，为什么呢？
因为前述“在Nb节点读到的是“Y”（未提交的不能读）”就是Y的旧版本，而不是未提交的新版本，这是MVCC机制决定的（小问题，请思考：是不是所有使用MVCC技术的，都得小心是不是存在“读半已提交数据异常”啦？是哈，得小心+小心。要不然，账目不平可就解释不清楚了）。
三 、业界是怎么解决读半已提交数据异常问题的？
其实，业界目前没有特别好的解决方式。如图4，典型的解法如下5类：
第一种：全局事务管理器架构。典型的例子如PostgreSQL-XC，其存在一个全局的事务处理节点，用于解决整个分布式系统分为内的所有事务冲突，这样需要把各个子节点的事务相关信息都发送给全局唯一的事务处理节点，不光通信量大，而且存在单点瓶颈，限制了事务的处理能力。
第二种：TDSQL以封锁机制实现全局可串行化。前述已经分析过，不再赘述。
第三种：物理时钟，全序排序事务降低并发度。典型的例子如著名的Spanner。Spanner彻底地解决了所有数据异常，这是通过实现所有以事务为单位的事件全序排序来完成的。换句话说，实现了线性一致性和事务的可串行化隔离。但是，Spanner以Truetime机制全序排序事务的方式，降低了并发度，导致其分布式事务的吞吐量很低，效率甚至低于基于封锁的并发访问控制下的可串行化实现（即：以线性一致性串起了事务一致性，所以理论上看，Spanner每秒数百个的事务的吞吐量使得效率低到了极限）。
第四种：混合时间戳机制，实习局部偏序排序。典型的例子如仿Spanner的CockroachDB，通过SSI实现了可串行化解决了事务类型的数据异常，但是不能解决全局读一致性的问题（需要全局排序才能解决全局读一致性问题，但混合时钟机制做不到全局有序）。另外，如果选择非可串行化隔离级别，则和Spanner一样，还是可能会出现“读半已提交数据异常”。
第五种：特定的解决机制--两次读机制。2次读机制，源自学术界《Scalable atomic visibility with ramp transactions》这篇paper。其核心思想，是在Na和Nb节点第一次分别读到“X-10”和“Y”这两个版本后，通过特定算法识别这两个数据不是出于一个一致的点，所以重新去Nb节点再读一次，这时，因为一段时间过去了，Nb节点大概率完成提交，读到的数据很可能是“Y+10”，因而可以保持对账不出现差错（X-10+Y+10=X+Y，账目保持平衡）。但是，两次读延迟了事务的执行，降低了整个事务的吞吐量；更重要的是，这种解决问题的方式，只针对“读半已提交数据异常” （小问题，请思考：如果有新的数据异常，还需要读2次数据吗？）。
四 、分布式事务型数据库，解决了读半已提交数据异常，就一劳永逸了吗？
如标题所言，分布式事务型数据库，解决了如图1和图3提及的各种数据异常之后，是不是就完美了呢？答案是否定的。
一波未平一波又起。
很不幸，图5有给出了新的数据异常。在《Distributed snapshot isolation: global transactions pay globally, local transactions pay locally》这篇Paper中，称之为“Cross数据异常”。
图5列出两类分布式系统下的数据异常，，其中第一类本质上就是“读半已提交数据异常”，而第二种“Cross数据异常”，其发生的背景，依然可以放到金融对账的业务背景中来理解。请看图5右子图部分，有两个物理节点，分别执行了本地事务和分布式事务。事务s和t是本地事务，修改了不同的数据项；事务x和事务y是两个分布式事务，都在读取数据；两个分布式数据读取数据被本地事务影响，读到了不一致的数据，事务x读到的是（a0，b1），事务y读到的是（b0，a1），而数据的一致状态要么是（a0，b0）要么是（a1，b1）。从业务的角度看，事务x和事务y都发起对账，结果对出来的结果不仅不同而且还是一个临时状态对应的结果，这就是数据异常，对账业务不能容忍此类事情发生。
数据库内核层，解决这样的数据异常，通常的方式，是通过建立事务之间的读写依赖关系图，从中看是否有环存在，如果有则表明数据异常出现，因而需要打破环，即回滚其中某个事务，避免问题出现（小问题，请思考：会不会还有新的数据异常呢？数据异常如果也层出不穷该怎么办？）。
五 、TDSQL的事务处理模型
先来分享一下TDSQL的事务处理框架，这个框架，可以用图2来做大的知识背景。
首先，TDSQL第一代的事务处理模型，采取了图2中的基于封锁的并发访问控制协议和MVCC并发访问控制协议，混合解决并发冲突问题。所以图6中给出的SS2PL整体就是封锁的并发访问控制协议，然后用2PC技术来实现提交阶段的原子写操作。这是整体架构。
在具体实现冲突解决的时候，需要结合MVCC和隔离级别，来解决各种数据异常。这就要区分写写冲突、读写冲突和写读冲突三种具体的情况。
写写冲突，通常依靠封锁机制。原理较为简单，不再赘述。
读写冲突和写读冲突，则借助MVCC来避免锁造成的延迟事务执行的问题，使得后者能继续继续，提高了并发度，所以主流的数据库基本上都实现了MVCC机制。
其次，TDSQL第二代的事务处理模型，新支持了图7基于OCC（乐观并发访问控制技术）和DTS（动态调整时间戳的并发访问控制技术）的技术，使得TDSQL的分布式事务处理能力产生了质的飞跃（OCC使得并发度提高，DTS使得并发访问控制算法去中心化），分布式事务处理性能提升数倍，并减少了对中心化时间戳节点的依赖，在分布式事务处理的去中心化的道路上，迈出一大步。
六 、什么是全局一致性？
还记得标题四中的小问题不？小问题，请思考：会不会还有新的数据异常呢？数据异常如果也层出不穷该怎么办？
现在，我们正面来谈谈，什么是全局读一致。目的就是一劳永逸的解决各种数据异常。
在单机数据库时代，数据库理论中有个“可串行化”技术，对应到了隔离级别中的可串行化隔离级别，因为理论上把所有事务都排序，消除了并发，因而不会再有数据异常产生。
但是，在分布式数据库时代，为了提高效率不想使用全局事务管理器限制并发，就采用了去中心化的架构设计分布式数据库；不想使用有额外成本的原子钟等，但又得解决各种数据异常，因此“可串行化”就不够用了（“可串行化”的本质就是在排序）。
再加上，分布式系统，存在各种不确定性，如网络发生分区、瞬间闪断、延时等，使得发生在分布式系统内的读和写事件反序（与发生的顺序相反）到达某个节点，这就又为分布式数据库识别事件之间的先后逻辑关系带来困难。为了规避这些问题带来的“逻辑认识上的困扰”，分布式系统中提出各种“一致性”，如线性一致性、因果一致性、单调写、写后读等各种问题（这些问题参见图8左子图）。
因此，分布式事务型数据库其核心要解决的问题就是：同时满足2个一致。一是分布式读一致性，二是分布式事务一致性。我们把这两种一致性，称为“全局一致性”（注意不是全局读一致性哦）。
分布式读一致性（即全局读一致性），从外部用户的视角，观察数据库内部发生的事件产生的结果之间的顺序要与事件发生的实际顺序保持一致，不能A事件先于B事件发生，但先不到B事件的结果后才可能看到A事件的影响。这意味着，需要对实际发生的事件进行排序。
而对于分布式事务型数据库，是从数据库内核层的角度，保证并发的事务之间，能造成数据异常的情况（读写依赖关系图形成了环）下部分事务被回滚或阻止其发生。及确保事务的可串行化。
如上两者都被保证的情况下，数据异常可被杜绝。Spanner就是从分布式读一致性中的线性一致性出发，约束了事务使之串行提交而保证无数据异常的，这好比用一根竹签先后串起了两种一致性需求（但效率因事务提交需要等待而低下），确保所有的事件全序排序杜绝任何异常。
但是，正式提出一个问题：大问题，请思考：有没有高效的方式确保全局一致性？
答案是：有。请看下一节，TDSQL的解决技术。
注意本文的概念变化：标题是全局读一致性，这是引子；但到本节发展成为了全局一致性；概念的变迁，有其内在的因素，请多体会哦。
七 、TDSQL是怎么解决各种数据异常的？
让我们回顾一下TDSQL的发展史，TDSQL2017年推出分布式事务处理技术，2018年推出全时态数据库系统。在全时态数据库技术中，提出一个“全态数据可见性判断算法”。
这个算法，初衷意在解决“分布式事务型数据库中，全态数据在任何时间点上怎么能够读到一致的数据”这样的问题（算法参考腾迅论文《Efficient time-interval data extraction in MVCC-based RDBMS》）。但是，以这个算法为基础，还可以做到全局一致性。更多技术，请参考VLDB 2019，腾讯论文《A Lightweight and Efficient Temporal Database Management System in TDSQL》。
如图9左上子图所示：
初始时刻t0：r11、r21、r31三个初始的数据项分布式在不同的物理节点上，此时这三个数据项处于一个“一致的”状态。
t1时刻：r11被修改为r12，此时之后，r12、r21、r31三个数据项处于一个“一致的”状态；虚线表示了他们处于一致状态。
t2时刻：r21、r31同时被同一个事务修改，分别变为了r22、r32，所以事务提交后，r12、r22、r32这三个数据项处于一个“一致的”状态。
其他时刻依次类推。
不支持全时态的数据库，只有当前态，所以DML类操作，只读取最新数据即可。
支持了全时态的数据库，需要从历史上任何一个点出发，找出这个出发点对应的处于一致性状态的数据。所以怎么标识哪些数据的所有值（当前值、历史值）和事务之间的关系，是全时态数据库当初解决的一个问题。
现在，有了如上这个基础，做到全局一致性，就容易了很多。所用技术如图9右子图部分。
写写冲突封锁机制互斥：对于前面我们提到的写写冲突，还是依靠封锁机制解决，避免丢失更新等数据异常发生。
MVCC从新版本到旧版本：基于MVCC，可以使得读写和写读冲突并发执行，提高了事务处理的效率，不然数据库系统性能一塌糊涂不可使用。另外，使用MVCC，读区版本的顺序是有讲究的，从最新版本开始读就要求构造版本链的时候版本由新到旧。
局部节点处于Prepared状态：在MVCC背景下，修改可见性判断算法，当数据在2PC阶段所有节点同意提交后，正常情况下事务就一定能够提交（系统故障发生后可被恢复），这时，数据即对满足快照的事务可见。
全局事务Committed状态：设立全局事务提交状态，当协调器在2PC阶段所有节点同意提交后，即可设置事务状态的全局标志为Committed（注意不是Prepared），然后通知子节点设置各自状态为Prepared的。只有全局提交标志为Committed，事务读取到的数据才是合法数据，可参考如图8中的左下子图部分，表示了分布式父子事务之间状态导致可见性的关系。如上2点，避免了前述的读半已提交数据异常。
异步、批量设置本地事务状态：协调器上全局事务状态信息，异步地发给涉及的各个子节点，完成子节点上原子事务状态的Committed化。这点是性能优化的问题。
全局逻辑时钟（非跨城/洲分布）：使用全局逻辑时钟，为事务建立全局一致的快照，即用SI技术（快照技术），确保全局读一致性。
Conflict serializable: the coordinator while loop determines whether a conflict exists, the type of data to resolve Cross exception. (Small problem, think: there is no other way to resolve cross abnormal?)
So, TDSQL achieve global consistency, namely to achieve consistency and strong consistency of unified external affairs. Here introduced the main process, in order to improve efficiency, TDSQL has done a lot of optimization points, to improve throughput transaction.
But, again formally ask a question: big problem, think: Is there a more efficient way to ensure global consistency?
Eight, look to the future, why TDSQL in transaction processing technology is leading?
TDSQL been walking on the road to explore the distributed transaction processing, we walked the streets full of challenges (Figure 10). At the same time enjoy the team to overcome the challenges posed by "can not be made and where the sound of silence with me ahead of the game" fun.
The way forward, TDSQL hand in the Ministry of Education Key Laboratory of Data Engineering and Knowledge Engineering, Renmin University of China, a dynamic time stamps to resolve conflicts and affairs to the center of global timestamp dependence, reduce transaction conflict with data-drive technology, reducing transaction with fine-grained conflict, implementation of distributed transaction processing capabilities to enhance the efficiency TDSQL distributed transaction processing. We look forward to the opportunity to share these technologies.
Special thanks to the Ministry of Education Key Laboratory of Data Engineering and Knowledge Engineering, Renmin University of China, together with Tencent TDSQL, jointly developed technology to share this article