OceanBase1.0的分布式事务程序.doc

OceanBase 1.0 的分布式事务 数据库的功能强大而繁杂，其中，“事务（Transaction）”是使用者不自觉就会用到的功能。作为开发数据库的工程师，我们是倾注了大量的精力和时间在事务这个功能上，并且深知数据库系统实现事务是付出了很大代价的。这代价不仅包括数据库软件开发的工作，而且还包括数据库运行过程中的代价。换句话说，在其他情况不变的时候，如果数据库放弃事务功能，能获得更好的性能。在数据库软件刚出现时，并没有事务这个功能，但这种情况下，使用数据库开发软件很多时候无法保证数据的正确性和一致性，或者把软件搞得很复杂。所以，数据库支持了事务功能，提供给使用者一个将许多数据库的操作打包在一起的功能，例如 Atomic（原子性），保证事务内对数据的多次修改操作，要么全部完成要么全部回滚。虽然付出了很多代价，但是用户的应用程序会因此大大简化。而且，用户操作数据的流程越来越复杂，如果没有事务特性的保证，使用者更加无法确切知道数据在数据库中是否保持正确。 事务重要的 4 个特性 ACID 分别代表 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）。 Atomicity（原子性）表示事务中的多个操作要么全部完成，要么全部没有生效，不会出现中间状态； Consistency（一致性）表示事务操作不会违反数据库的一致性约束； Isolation（隔离性）表示多个并发事务之间不互相影响； Durability（持久性）表示事务一旦成功就不会丢失。 数据库系统有很多工程化方法来实现这些事务特性。其中，保证所有数据都存储在持久化设备中，就可以保证数据的 Durability（持久性）。常用的持久化设备有磁盘和 SSD，这种设备保证在断电的时候数据都不会丢失。事务的一致性是数据库系统对于数据的约束，常见的约束有数据库的外键（Foreign Key），数据库系统保证事务执行后这些约束都不会被破环。这两个功能点，在有原子性（Atomicity）和隔离性（Isolation）的基础上，系统实现起来相对简单。所以，在这篇文章中，我们只详细描述原子性（Atomicity）和隔离性（Isolation）两个特性。 原子性（Atomicity） 原子性（Atomicity）是事务中最重要的特性，如果一切操作正常，保证原子性（Atomicity）并不复杂。保证事务原子性（Atomicity）的复杂性多出自异常处理，例如宕机恢复、主备切换等。以一个事务修改两行数据为例，如果在修改完第一行之后、修改第二行之前机器宕机了，如果没有其他机制保证，待机器重新恢复服务，就只有第一行的修改存留在系统中，违反了原子性（Atomicity）的要求。 什么是原子性（Atomicity） 实现原子性（Atomicity）的一种方法是将多个操作的生效时机放在一个原子操作上。计算机系统在内存操作上可以做到原子性的操作有给一个内存变量赋值、CAS 操作等。硬盘的原子性操作和硬件本身有关，磁盘一般是一个 512 字节的块写入是原子的，SSD 一般是 4KB 的块写入是原子的。用一个数据结构的例子说明这种原子性实现机制。 struct Balance { int accountA; int accountB; }; 上面是 C++ 的结构体，表示了两个账户 A 和 B 的余额。如果从 A 转账 5 元给 B，对应的 C++ 代码如下： x-accountA -= 5; x-accountB += 5; 上面的代码不是原子的，在两条语句中间，如果另一个线程读取 accountA 和 accountB 的值，会发现转账操作只执行了一半。如果使用下面的代码，就可以保证无论什么时候读取，都不会读到转账执行了一半的情况： Balance * tmp = new Balance(); tmp-accountA = x-accountA - 5; tmp-accountB = x-accountB + 5; x = tmp; 操作的生效时间是x = tmp;语句，单一变量的赋值操作是原子的，保证了整个转账操作是原子的。 使用日志实现原子性（Atomicity） 上面基于原子性操作的实现方法在数据结构中很常用，但是现在数据库系统都是使用日志技术（log）实现原子性（Atomicity），因为日志技术解决原子性的方法更灵活，还能同时解决了事务的持久性（Durability）需求，而且比直接持久化数据有更好的性能，所以几乎所有的数据库系统都采用了日志技术（log），甚至还包括文件系统、队列系统等。 使用 log 时，先把整个事务的操作编码成连续的日志信息，再把日志信息写入持久化设备，当日志成功写入后，就是保证事务