闲话聊聊事务处理（上）

如前面的一些文章写的，数据系统不可能保证是完全的可靠的，我们会遇上各种各样的问题，比如数据库或者应用突然崩溃，网络连接断了，并发读和并发写，诸如此类。遇上问题总不可能不解决，但是作为一个可靠的数据系统，就必须让使用者感觉不到这些问题的存在。在大数据诞生之前，这种解决方案称之为事务。那什么是事务呢？事务将一些读和写操作聚合在一个逻辑单元里，在这个逻辑单元里，所有的读和写操作都被认为是一个操作。事务有三种状态：succeed、abort和rollback。事务存在的意义在于简化了程序模型，可以让程序不再处理数据系统发生的问题，而是交由数据系统自身去解决。

在开始讨论事务之前，先来看看每个数据库的书都会提到的ACID的概念。1.原子性(Atomisty)，如果你是某个语言的使用者的话，相信你会相当困惑。从一般意义上来说，原子性指的是某样东西已不能再分割成更小的部分了，从并发编程的角度来说，原子性指的是对于一个操作而言，只有对应这个线程才能看到中间状态，其他线程是没法看到任何中间结果的。然而，ACID里的原子性无关并发操作，单纯指的是某个操作如果出现了问题可以毫无问题的回滚或者放弃。显然，abortability更适合它。2.一致性(Consistency)，又是一个被用烂的词语。对于异步数据复制而言，备份数据之间会最终达到最终一致，还有所谓的一致性hash算法，CAP理论里的一致性(Linearizability)，在ACID里，一致性指的数据系统里的数据拥有某种不会发生改变的状态，例如对于转账这个操作而言，写入和写出对数据的影响必然是一致的。从描述上来讲，一致性并不专属于数据系统，而且也需要应用方的配合。3.隔离性(Isolation)，这是针对并发而提出的概念。因为一个数据系统不会只有一个client，而数据库必须使得各个client对数据库的操作彼此之间不会互相影响，和进程的抽象很类似，每个client的操作会认为自己才是数据系统上运行的唯一程序。听起来很美好，在实践中，往往对性能有很大的影响，与其对应的是弱化版本。4.持久性(Durability)，很有趣的话题，对于单机而言，持久性指的是将数据会写入磁盘或者SSD中，对于分布式系统而言，指的是备份。完美的持久性是不存在的，因为不能保证你的所有磁盘不会出现都奔溃的情况。

从对ACID的讨论中，我们可以注意到对于数据系统而言，最重要的性质是原子性和隔离性。事务该如何解决满足这两个性质呢？如果在数据库里，只有一个对象（row，document等）被修改（称之为single-object事务），我们使用日志去解决crash recovery，用锁去防止对象被同时修改，在一些流行的数据库中，还提供了compare-and-set操作去解决单调增之类的问题，single-object事务也被视为一个轻量级的事务。当然，在事务中，常见的不会仅有一个对象被修改，往往是多个对象同时被修改(multi-object事务)，例如关系型数据库中，对于外键的处理，文档数据库中对于一系列文档中某个类型的修改，甚至还有二级索引的修改。这时就麻烦了，我们更需要原子性和隔离性去指导我们解决并发问题。

如果事务出现了失败的情况，我们该如何处理呢？在ORM(object-relational mapping)框架中，常见的处理方式是直接将问题抛给用户，告诉他们，这个事务失败了。在数据系统中，处理方式很简单，那就是retry。不过retry也有retry的问题需要我们去解决。例如事务实际上是成功的，而仅仅只是网络阻塞导致的失败，那么retry只会使得问题更加严重，并且数据系统内部也需要一套去重的机制防止retry导致的数据重复写入，对于死锁等transient问题，retry是无法有效解决问题的，并且如果事务是用来处理外部信息，如邮件，retry意味着发送了两次邮件，在大部分情况是不可接受的。