前言

大家都知道事务有四个特性：

• 原子性（atomicity）

  原子性是指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作执行都成功，才算整个事务成功。如果事务中任何一个SQL语句执行失败，那么已经执行成功的SQL语句也必须撤销，数据库状态应该退回到执行事务前的状态。

• 一致性（consistency）

  一致性指事务将数据库从一种状态转变为下一种一致的状态。在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。

• 隔离性（isolation）

  一个事务的影响在该事务提交前对其他事务都不可见——这通过锁来实现。

• 持久性（durability）

  事务一旦提交，其结果就是永久性的。即使发生宕机等故障，数据库也能将数据恢复。

对于隔离性的实现，可以参考我的这篇文章：InnoDB锁与事务简析

本篇文章主要讲述其它三个特性是如何实现的：通过数据库的redo和undo来完成。本文如果不做特别说明，默认指的是mysql的InnoDB存储引擎。

实现

基础知识

1. redo log记录的关于每个页（Page）的更改的物理情况
2. undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。
3. LSN称为日志的逻辑序列号(log sequence number)，在innodb存储引擎中，lsn占用8个字节。LSN的值会随着日志的写入而逐渐增大。事务中更新操作会产生一个新的LSN。LSN不仅存在于redo log中，还存在于数据页中。
4. checkpoint检查点，表示脏页写入到磁盘的时候

整体流程

无论是日志还是数据，都是现在buffer里修改，然后再同步到磁盘上的。

1. 启动事务后，修改的数据如果没有在log buffer中，则会从磁盘读取到log buffer

2. 对内存中数据修改之前，将原始数据记录到undo log

3. 对内存中的数据页进行修改，在内存数据页中记录LSN，暂且称之为data_in_buffer_lsn

4. 在修改数据页的同时(几乎是同时)向redo log in buffer中写入redo log，并记录下对应的LSN，暂且称之为redo_log_in_buffer_lsn；

5. 日志刷盘和数据刷盘

   日志刷盘的规则为

   • 发出commit动作时

   • 每秒刷一次

   • 当log buffer中已经使用的内存超过一半时

   • 当有checkpoint时

   数据刷盘的规则为

   • 当有checkpoint时

   日志刷盘的次数比数据刷盘次数更多，另外即使在checkpoint时，innoDB也会**保证在写数据前，需要先写日志，这种方式称为预写日志方式（Write-Ahead Logging，WAL）。**InnoDB存储引擎通过预写日志的方式来保证事务的完整性。

   预写日志方式之所以能保证完整性，是因为日志和数据页中有LSN，通过LSN可以比较日志和数据页中数据记录的顺序。日志文件是真正的核心。

实例

来源于：详细分析MySQL事务日志(redo log和undo log)

上图中，从上到下的横线分别代表：时间轴、buffer中数据页中记录的LSN(data_in_buffer_lsn)、磁盘中数据页中记录的LSN(data_page_on_disk_lsn)、buffer中重做日志记录的LSN(redo_log_in_buffer_lsn)、磁盘中重做日志文件中记录的LSN(redo_log_on_disk_lsn)以及检查点记录的LSN(checkpoint_lsn)。

假设在最初时(12:0:00)所有的日志页和数据页都完成了刷盘，也记录好了检查点的LSN，这时它们的LSN都是完全一致的。

假设此时开启了一个事务，并立刻执行了一个update操作，执行完成后，buffer中的数据页和redo log都记录好了更新后的LSN值，假设为110。这时候如果执行 show engine innodb status 查看各LSN的值，即图中①处的位置状态，结果会是：

log sequence number(110) > log flushed up to(100) = pages flushed up to = last checkpoint at

之后又执行了一个delete语句，LSN增长到150。等到12:00:01时，触发redo log刷盘的规则(其中有一个规则是 innodb_flush_log_at_timeout 控制的默认日志刷盘频率为1秒)，这时redo log file on disk中的LSN会更新到和redo log in buffer的LSN一样，所以都等于150，这时 show engine innodb status ，即图中②的位置，结果将会是：

log sequence number(150) = log flushed up to > pages flushed up to(100) = last checkpoint at

再之后，执行了一个update语句，缓存中的LSN将增长到300，即图中③的位置。

假设随后检查点出现，即图中④的位置，正如前面所说，检查点会触发数据页和日志页刷盘，但需要一定的时间来完成，所以在数据页刷盘还未完成时，检查点的LSN还是上一次检查点的LSN，但此时磁盘上数据页和日志页的LSN已经增长了，即：

log sequence number > log flushed up to 和 pages flushed up to > last checkpoint at

但是log flushed up to和pages flushed up to的大小无法确定，因为日志刷盘可能快于数据刷盘，也可能等于，还可能是慢于。但是checkpoint机制有保护数据刷盘速度是慢于日志刷盘的：当数据刷盘速度超过日志刷盘时，将会暂时停止数据刷盘，等待日志刷盘进度超过数据刷盘。

等到数据页和日志页刷盘完毕，即到了位置⑤的时候，所有的LSN都等于300。

随着时间的推移到了12:00:02，即图中位置⑥，又触发了日志刷盘的规则，但此时buffer中的日志LSN和磁盘中的日志LSN是一致的，所以不执行日志刷盘，即此时 show engine innodb status 时各种lsn都相等。

随后执行了一个insert语句，假设buffer中的LSN增长到了800，即图中位置⑦。此时各种LSN的大小和位置①时一样。

随后执行了提交动作，即位置⑧。默认情况下，提交动作会触发日志刷盘，但不会触发数据刷盘，所以 show engine innodb status 的结果是：

log sequence number = log flushed up to > pages flushed up to = last checkpoint at

最后随着时间的推移，检查点再次出现，即图中位置⑨。但是这次检查点不会触发日志刷盘，因为日志的LSN在检查点出现之前已经同步了。假设这次数据刷盘速度极快，快到一瞬间内完成而无法捕捉到状态的变化，这时 show engine innodb status 的结果将是各种LSN相等。

恢复

mysql的恢复策略是：

1. 恢复时，先根据redo重做所有事务，包括未提交的事务
2. 再根据undo回滚未提交的事务。

通过这种策略，保证了事务的原子性、一致性和持久性。

另外，引入了checkpoint机制，在恢复的时候，只需要从checkpoint的位置往后恢复即可

感想

1. 网络上很多的内容可能不准确，即使是我写的这篇文章，也可能有不准确的地方，解决这个问题的最好办法是读源码
2. 不同的技术可能实现不同，但核心原理往往都是相通的，而这些核心原理一般建立在基础知识之上
3. 学习知识可以学习到不同的深度，看完《MySQL技术内幕：InnoDB存储引擎》便能大体掌握mysql的使用，但是了解的不深入，随着写了这两篇文章，对Mysql的了解更加深入了一些，如果需要继续深入，真的需要看源码了，这个事情感觉得耗费更多的时间。所以需要知道自己需要了解到什么水平，用有限的时间去做性价比更高的事情，选择很重要。

资料

1. 深入学习MySQL事务：ACID特性的实现原理
2. 详细分析MySQL事务日志(redo log和undo log)
3. https://blog.csdn.net/suerge_storm/article/details/90484944
4. https://blog.csdn.net/qq_41151659/article/details/99559397

最后

大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）

往期文章回顾：

1. 事务原子性、一致性、持久性的实现原理
2. 如何锻炼自己的记忆力
3. CDN请求过程详解
4. 关于程序员职业发展的思考
5. 记博客服务被压垮的历程
6. 常用缓存技巧
7. 如何高效对接第三方支付
8. Gin框架简洁版
9. 关于代码review的思考
10. InnoDB锁与事务简析
11. Markdown编辑器推荐-typora

数据库事务原子性、一致性是怎样实现的？

atomicity/consistency

数据库的一致性依赖于其他三种特性：原子性，隔离性，持久性

原子性用于保证事务中的语句要么全部执行要么全部不执行

隔离性用于保证多事务并发处理下事务处理顺序与结果的保证

隔离性的处理分为四个级别

• read uncommit ted
• read committed
• repeatable read
• serializable

原子性如何保证

atomicity

innodb使用undo log

回滚日志，记录事务操作以便回滚

• insert->delete
• delete->insert
• update->update 更新的回滚就先记录更改前的数据然后回滚就跟新为之前的状态

使用undo log撤回之前的操作

持久性如何保证

durability

redo log

Mysql是先把磁盘上的数据加载到内存中，在内存中对数据进行修改，再刷回磁盘上。如果此时突然宕机，内存中的数据就会丢失。

怎么解决？

事务提交前直接把数据写入磁盘

太浪费IO资源

使用redo log来解决持久性和读写IO消耗严重问题

当做数据修改的时候，不仅在内存中操作，还会在redo log中记录这次操作。当事务提交的时候，会将redo log日志进行刷盘（redo log一部分在内存一部分在磁盘）。当数据库宕机重启会将redolog中的内容恢复到数据库再根据undo log和binlog内容决定回滚数据还是提交数据

隔离性如何保证？

isolation

使用锁机制，保证每个事务能够看到的数据总是一致的，就好像其他事务不存在一样，多个事务并发执行后的状态和它们串行执行后的状态是等价的

两种锁

• 悲观锁

  当前事务设计操作的对象加锁，操作完成后释放给其它对象使用。

  提高性能->{各种粒度：数据库/表/行/各种性质：共享/排他/共享意向/排他意向/共享排他意向}

  解决死锁->{两阶段协议/死锁检测}

• 乐观锁

  不同事物可同时可能到同一对象的不同历史版本。使用MVCC（多版本并发控制，Multi-Version Concurrency Control），可在事务提交前查看修改事务的版本，如果与读取版本不一致可放弃提交

  如果有两个事务同时修改了同一数据行，那么在较晚的事务提交时进行冲突检测。实现:通过undo log来获取历史版本，另一种简单地在内存中保存同一数据行的多个历史版本，通过时间戳来区分。

一、案例缘起

我们经常使用事务来保证数据库层面数据的ACID特性。

举个栗子，用户下了一个订单，需要修改余额表，订单表，流水表，于是会有类似的伪代码：

start transaction;

         CURDtable t_account;  any Exception rollback;

         CURDtable t_order;       any Exceptionrollback;

         CURDtable t_flow;         any Exceptionrollback;

commit;

如果对余额表，订单表，流水表的SQL操作全部成功，则全部提交，如果任何一个出现问题，则全部回滚，以保证数据的一致性。

 

互联网的业务特点，数据量较大，并发量较大，经常使用拆库的方式提升系统的性能。如果进行了拆库，余额、订单、流水可能分布在不同的数据库上，甚至不同的数据库实例上，此时就不能用事务来保证数据的一致性了。这种情况下如何保证数据的一致性，是今天要讨论的话题。

 

二、补偿事务

补偿事务是一种在业务端实施业务逆向操作事务，来保证业务数据一致性的方式。

举个栗子，修改余额表事务为

int Do_AccountT(uid, money){

start transaction;

         //余额改变money这么多

         CURDtable t_account with money;       anyException rollback return NO;

commit;

return YES;

}

 

那么补偿事务可以是：

int Compensate_AccountT(uid, money){

         //做一个money的反向操作

         returnDo_AccountT(uid, -1*money){

}

 

同理，订单表操作为

Do_OrderT，新增一个订单

Compensate_OrderT，删除一个订单

 

要保重余额与订单的一致性，可能要写这样的代码：

// 执行第一个事务

int flag = Do_AccountT();

if(flag=YES){

         //第一个事务成功，则执行第二个事务

         flag= Do_OrderT();

         if(flag=YES){

                  // 第二个事务成功，则成功

                   returnYES;

}

else{

         // 第二个事务失败，执行第一个事务的补偿事务

         Compensate_AccountT();

}

}

 

该方案的不足是：

（1）不同的业务要写不同的补偿事务，不具备通用性

（2）没有考虑补偿事务的失败

（3）如果业务流程很复杂，if/else会嵌套非常多层

 

例如，如果上面的例子加上流水表的修改，加上Do_FlowT和Compensate_FlowT，可能会变成一个这样的if/else：

// 执行第一个事务

int flag = Do_AccountT();

if(flag=YES){

         //第一个事务成功，则执行第二个事务

         flag= Do_OrderT();

         if(flag=YES){

                  // 第二个事务成功，则执行第三个事务

                   flag= Do_FlowT();

                   if(flag=YES){

                            //第三个事务成功，则成功

                            returnYES;

}

else{

         // 第三个事务失败，则执行第二、第一个事务的补偿事务

         flag =Compensate_OrderT();

         if … else … // 补偿事务执行失败？

                  flag= Compensate_AccountT();

                   if … else … // 补偿事务执行失败？

}

}

else{

         // 第二个事务失败，执行第一个事务的补偿事务

         Compensate_AccountT();

         if … else … // 补偿事务执行失败？

}

}

 

三、事务拆分分析与后置提交优化

单库是用这样一个大事务保证一致性：

start transaction;

         CURDtable t_account;  any Exception rollback;

         CURDtable t_order;       any Exceptionrollback;

         CURDtable t_flow;         any Exceptionrollback;

commit;

拆分成了多个库，大事务会变成三个小事务：

start transaction1;

         //第一个库事务执行

         CURDtable t_account;  any Exception rollback;

         …

// 第一个库事务提交

commit1;

start transaction2;

         //第二个库事务执行

         CURDtable t_order;       any Exceptionrollback;

         …

// 第二个库事务提交

commit2;

start transaction3;

         //第三个库事务执行

         CURDtable t_flow;         any Exceptionrollback;

         …

// 第三个库事务提交

commit3;

 

一个事务，分成执行与提交两个阶段，执行的时间其实是很长的，而commit的执行其实是很快的，于是整个执行过程的时间轴如下：

第一个事务执行200ms，提交1ms；

第二个事务执行120ms，提交1ms；

第三个事务执行80ms，提交1ms；

那在什么时候系统出现问题，会出现不一致呢？

回答：第一个事务成功提交之后，最后一个事务成功提交之前，如果出现问题（例如服务器重启，数据库异常等），都可能导致数据不一致。

 

如果改变事务执行与提交的时序，变成事务先执行，最后一起提交，情况会变成什么样呢：

第一个事务执行200ms；

第二个事务执行120ms；

第三个事务执行80ms；

第一个事务执行1ms；

第二个事务执行1ms；

第三个事务执行1ms；

 

那在什么时候系统出现问题，会出现不一致呢？

问题的答案与之前相同：第一个事务成功提交之后，最后一个事务成功提交之前，如果出现问题（例如服务器重启，数据库异常等），都可能导致数据不一致。

 

这个变化的意义是什么呢？

方案一总执行时间是303ms，最后202ms内出现异常都可能导致不一致；

方案二总执行时间也是303ms，但最后2ms内出现异常才会导致不一致；

虽然没有彻底解决数据的一致性问题，但不一致出现的概率大大降低了！

 

事务提交后置降低了数据不一致的出现概率，会带来什么副作用呢？

回答：事务提交时会释放数据库的连接，第一种方案，第一个库事务提交，数据库连接就释放了，后置事务提交的方案，所有库的连接，要等到所有事务执行完才释放。这就意味着，数据库连接占用的时间增长了，系统整体的吞吐量降低了。

 

四、总结

trx1.exec();

trx1.commit();

trx2.exec();

trx2.commit();

trx3.exec();

trx3.commit();

优化为：

trx1.exec();

trx2.exec();

trx3.exec();

trx1.commit();

trx2.commit();

trx3.commit();

这个小小的改动（改动成本极低），不能彻底解决多库分布式事务数据一致性问题，但能大大降低数据不一致的概率，带来的副作用是数据库连接占用时间会增长，吞吐量会降低。对于一致性与吞吐量的折衷，还需要业务架构师谨慎权衡折衷。