阿里沈询：分布式事务原理与实践

Posted 2021-04-25 猿族崛起

事务简介

事务的核心是锁和并发，采用同步控制的方式保证并发的情况下性能尽可能高，且容易理解。这种方式的优势是方便理解；它的劣势是性能比较低。

计算机可以简单的理解为一个标准的打字机，尽管看起来计算机可以并行处理很多事情，但实际上每个CPU单位时间内只能做一件事，要么读取数据、要么计算数据、要么写入数据，所有的任务都可以看成这三件事的集合。计算机的这种特性引出了一个问题：当多个人去读、算、写操作时，如果不加访问控制，系统势必会产生冲突。而事务相当于在读、算、写操作之外增加了同步的模块，进而保证只有一个线程进入事务当中，而其他线程不会进入。

单个事务单元

事务的四大特性分别是：原子型、一致性、隔离性和持久性。其中1/原子性指的是事务中包含的所有操作要么全做，要么全不做；2/一致性是指在事务开始以前，数据库处于一致性的状态，事务结束后，数据库也必须处于一致性的状态；3/隔离性要求系统必须保证事务不受其他并发执行的事务的影响；4/持久性是指一个事务一旦成功完成，它对数据库的改变必须是永久的，即使是在系统遇到故障的情况下也不会丢失，数据的重要性决定了事务的持久性的重要。

备注：（原子性和一致性容易理解不透，原子性这个侧重点是事务执行的完整，一套事务下来，如果有一个失败，那整体失败。也就是要么大家一起成功，要么全都回滚

     一致性这个讲的是事务是按照预期生效的，也就是你举例的那个转账的，一致性的核心一部分是靠原子性实现的，而另一部分是逻辑实现。

举个栗子吧：

    转账：张三给李四转账100元。那数据库假设需要 张三扣100，李四加100，记录一条流水。

如果流水没记录成功，那整体回滚，张三也没转账成功，李四也没多钱。这就是原子性的体现。

而张三必须扣100，李四必须加100，这个就是一致性了，如果因为某些逻辑原因，导致张三扣了100，流水记录100转账，而李四只加了60。然后这3条操作都成功了，那原子性就符合了，但是一致性就不符合了~~~

其实在实际应用中肯定不是这么简单的例子的。往往是类似，买东西扣库存这类的逻辑，主表里有库存，库存表里有库存，SKU表里还有，然后就因为设计缺陷，就算加了事务还是出现了超卖、SKU库存对不上总库存的问题。。这个就是一致性不满足的了。）

事务单元是通过Begin-Traction，然后Commit（Begin-Traction、Commit和Rollback之间所有针对数据的写入、读取的操作都应该添加同步访问），Begin和Commit之间就是一个同步的事务单元。例如，Bob给Smith 100块钱就是一个事务单元，这个过程中有很多步操作，具体如上图所示；但对业务来说，仅是一个转账的操作。

一组事务单元

当三个账户都在进行转账操作时，每个操作都涉及Smith账户，所有的事务都会排队，形成一组事务单元。

事务单元之间的Happen-Before关系中的四种可能性：读写、写读、读读、写写。所有事务之间的关系都可以抽象成这四种之一，来对应现在所有的业务逻辑处理。在此基础之上，需要用最快的速度处理多个事务单元之间的关系，同时还能保障这四种操作的逻辑顺序。

单个事务单元的其他例子

重点：除了转账操作是事务单元外，诸如商品要建立一个基于GMT_Modified的索引、从数据库中读取一行记录、向数据库中写入一行记录，同时更新这行记录的所有索引、删除整张表等都是一个事务单元。

事务单元的实现方式

        Two Phase Lock（2PL）是数据库中非常重要的一个概念。数据库操作Insert、Update、Delete都是先读再写的操作，例如Insert操作是先读取数据，读取之后判读数据是否存在，如果不存在，则写入该数据，如果数据存在，则返回错误。假设在该场景下没有读操作，只是单纯写入数据，则数据本身并没有事务操作，Delete、Update操作与之类似。数据库利用这些操作的特性，在每一次查询过程中，只要查到数据，就会在该数据上加锁。理论上，所有被读取的数据都已加锁，不会再被其他人读到，也就是说对数据进行的中间操作状态对所有人都不可见，当所有中间状态完成后，提交操作时，解开锁，此时数据对所有系统可见，例如在转账过程中，所有人只能看到两种状态：开始时，A有钱，B没钱；结束时，B有钱，A没钱，而中间A减掉钱，B尚未加上钱的状态被锁隐藏掉了，这个操作就是数据库中处理事务的最标准的方式。如上图所示：事务中的T 行执行；Trx1需要Lock两个数据Boblock和Smithlock，而Trx3同样需要Lock这两个数据，因此Trx3必须等待，且等待在Boblock上；Joe事务会先结束，Trx3会等到Trx1完成后才会开始。

(备注：Two Phase Lock（2PL）的解释，两段锁协议是指每个事务的执行可以分为两个阶段：生长阶段（加锁阶段）和衰退阶段（解锁阶段）。

加锁阶段：在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁，在进行写操作之前要申请并获得X锁。加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。

解锁阶段：当事务释放了一个封锁以后，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。

两段封锁法可以这样来实现：事务开始后就处于加锁阶段，一直到执行ROLLBACK和COMMIT之前都是加锁阶段。ROLLBACK和COMMIT使事务进入解锁阶段，即在ROLLBACK和COMMIT模块中DBMS释放所有封锁。)

处理事务的常见方法

处理事务的常见方法有排队法、排他锁、读写锁、MVCC等方式，下面来一一解析。

排队法

事务处理中最重要也是最简单的方案是排队法，单线程地处理一堆数据。在Redis中，如果数据全部在内存中，则单线程处理所有Put、Get操作效率最高。这是因为多线程本质是CPU模拟多个线程，这种模拟是以上下文切换为代价，而对于内存的数据库来说，没有上下文切换时效率最高。因此，单个CPU绑定一块内存的数据，针对这块数据做多次读写操作时都是在单个CPU上完成的，单线程处理方式在内存的情况是效率是最优的。

那么什么时候事务需要用到多线程呢？这个问题的本质取决于下层所使用的存储，如果是内存操作，则可以动态地申请和销毁内存块；而磁盘的IOPS很低，但吞吐量很高。如果一个场景涉及多次读写操作，单线程可以很高的效率对于内存进行读写操作；但是，由于磁盘的IOPS仅为内存的几千分之一，如果依旧用操作内存的方式操作磁盘，那系统的整体性能将会很低，这意味着必须将大量的读写操作聚合成一个Batch后再提交时才能达到较好的性能。而将大量请求攒到一起的方式一是异步，也就是请求本身和线程不绑定，线程可以不Block（本质来说还是一种多线程的方式），处理完一个线程后再处理其他线程。这种做法的核心是将大量不同的请求提交到一个Buff

设备中，多线程或异步非常常见，在设计系统时，面对磁盘、网络、SSD等慢速设备必须考虑使用多线程。

排他锁

有些场景不适合用单线程操作，可以利用排他锁的方式来快速隔离并发读写事务。数据库中有一些事务单元是共享的，如图中的事务单元1是共享的，事务单元2/3共享数据；针对事务单元2/3共享数据的所有读写Block住，事务单元1单独用一个锁来控制，用这种方式完成系统的访问控制。

读写锁

如果是一个只读的事务，例如只对数据进行查询操作，在该过程中数据一定不被修改，因此多个查询操作可以并行执行，因此一种针对读读场景的优化自然而然产生——读写锁。读写锁的核心是在多次读的操作中，同时允许多个读者来访问共享资源，提高并发性。

MVCC

在最初的数据库事务实现中是不存在MVCC的，它是Oracle在八十年代新加的功能，本质是Copy On Write，也就是每次写都是以重新开始一个新的版本的方式写入数据，因此，数据库中也就包含了之前的所有版本。在数据读的过程中，先申请一个版本号，如果该版本号小于正在写入的版本号，则数据一定可以查询到，无需等到新版本完全写完即可返回查询结果。这种方式可以在读读不阻塞的前提下，实现读写/写读不阻塞，尽可能保证所有的读操作并行，而写操作串行。

事务的调优原则

事务的调优的思路是在不影响业务应用的前提下：

第一，尽可能减少锁的覆盖范围，例如Myisam表锁到Innodb的行锁就是一个减少锁覆盖范围的过程；对于原位锁（排他锁、读写锁等）可变为MVCC多版本（本质仍然是减少锁的范围）。

第二，增加锁上可并行的线程数，例如读锁和写锁的分离，允许并行读取数据。

第三，选择正确锁类型，其中悲观锁适合并发争抢比较严重的场景；乐观锁适合并发争抢不太严重的场景。

来源：http://jm.taobao.org/2017/02/09/20170209/