水文：事务（未完）

事务

1. 事务/数据库事务

1.1 定义

事务，提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，这个执行单元的所有操作全部成功才算执行事务，否则整个事务进行回滚。

总而言之，事务提供一种“要么全部成功，要么全部失败”的机制

说明：事务是存储引擎实现的。支持事务的存储引擎常见的有InnoDB、NDB Cluster等，不支持的有MyISAM和Memory

1.2 特性：ACID

ACID指数据库正确执行的四个基本特性的缩写：

• 原子性，Atomicity
• 一致性，Consistency
• 隔离性，Isolation
• 持久性，Durability

按照严格的标准，同时满足ACID特性才是事务。但是各大数据库厂商的实现中，真正满足事务特性的少，例如：MySQL的NDB Cluster事务不满足隔离性和持久性、InnoDB事务不满足隔离性（默认事务隔离级别为可重复读）、Oracle事务不满足隔离性（默认事务隔离级别为读已提交）。

Prepare：MySQL日志

日志类型有多种，如二进制日志、错误日志、查询日志、慢查询日志等

InnoDB提供了两种事务日志：redo log（重做日志）和undo log（回滚日志）

• redo log，用于保证事务持久性
• undo log，用于保证事务原子性和隔离性

原子性：Atomicity

定义：一个事务是一个不可分割的执行单元。

实现：unod log。

事务回滚：执行失败、或调用rollback
存储引擎：执行undo log内容的相反操作，如记录insert，则执行delete；记录delete，则执行insert...

一致性：Consistency

隔离性：Isolation

作用更偏向于处理并发事务的影响。

定义：事务内部的操作，与其他事务是隔离的，并发执行的各个事务之间互不干扰。

严格的隔离性：Serializable（可串行化），效率低。

详情见1.3

持久性：Durability

定义：事务一旦提交，对数据库的更新就是永久的。

实现：redo log

读写流程：缓冲，磁盘
作用：提高效率
问题：缓冲区数据没有写入磁盘时，宕机会丢失数据，持久性无法保证

如何解决：除了修改缓冲，还会在redo log记录这次操作。具体顺序是先写入redo log，再更新到缓冲，保证数据不因MySQL宕机而丢失

说明：redo log和binlog区别。

redo log和binlog，都可用于恢复数据，区别：
	1. 层次
		redo log用于crash recovery，保证持久性
		binlog用于point-in-time recovery，保证数据库基于时间点恢复，此外还可用于主从复制
	2. 作用
		redo log是InnoDB存储引擎实现，binlog是数据库实现
    3. 内容
    	redo log是物理日志，binlog是二进制日志
    4. 写入时间
    	redo log写入时间不确定，在缓冲前写入
    	binlog在事务提交时写入

1.3 数据库事务如何实现

原子性和持久性：日志

事务的原子性和持久性是由事务日志，即回滚日志（undo.log）和重做日志（redo.log）

• 回滚日志，发生错误或回滚操作，反执行undo.log，保证原子性
• 重做日志，事务提交但没写入磁盘时宕机，下次重启会再次执行redo.log，保证持久性

隔离性

隔离级别和并发事务引发的问题

隔离级别	脏读	不可重复读	幻读
未提交读Read Uncommitted	√	√	√
已提交读Read Committed		√	√
可重复读Repeatable Read			√
可串行化Serializable

实现机制

1. 锁：读写锁，或者共享锁
2. 时间戳：CAS
3. 多版本和快照隔离，即MVCC：基于日志

1.4 数据库的分布式事务解决方案：2PC

[待完善]

2. Spring事务

2.1 接口

// 事务管理器、事务定义信息（隔离级别、传播行为、超时、只读、回滚规则）、事务运行状态
PlatformTransactionManager
TransactionDefinition
TransactionStatus

2.2 隔离级别：见1.3

2.3 传播行为

场景：当事务方法被另一个事务方法调用时，事务如何传播？
7种传播行为：暂略

类型	说明

2.4 事务定义信息：超时、只读、回滚

超时，一个事务所允许执行的最长时间
只读：只读或读写两种类型，设为只读，事务处理性能更高
回滚规则：定义了遇到哪些异常会导致事务回滚

2.5 code

[待完善]

3. 分布式事务

3.1 定义

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

3.2 产生原因

一个应用由多个微服务组成
一个应用的数据库由多个数据库组成，比如一个微服务一个库

3.3 基础

CAP

C 强一致性；A 可用性；P 分区容错性
应用：CP或AP

BASE：基于AP的扩展

BA 基本可用：分布式系统出现故障，允许损失部分可用功能，保证核心功能可用
S 软状态：允许系统中存在中间状态，不影响系统可用性，指不一致
E 最终一致性：经过一段时间，所有节点数据到达一致

3.4 分布式方案

2PC：强一致性

3PC：

TCC：最终一致性

本地消息表：最终一致性

MQ事务：最终一致性

Saga事务：最终一致性

参考

[深入学习MySQL事务：ACID特性的实现原理

『浅入深出』MySQL 中事务的实现

数据库事务总结与整理（一）

再有人问你分布式事务，把这篇扔给他

一文了解InnoDB事务实现原理

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