MySql事务篇

事务的目的

可以确保数据要么所有修改都已经保存了，要么所有修改都不保存。

事务特性（ACID）

• 原子性（atomicity）：事务是一个整体，不可再分，要么同时成功，要么同时失败
• 一致性（consistency）：数据库从一种一致的状态转换成下一种一致性的状态
• 隔离性（isolation）：事务之间相互隔离，提交事务前其他事务不可见
• 持久性（durability）：事务一旦提交，其结果就是永久性的，即使宕机或者发生故障，也能恢复数据

事务实现

通过学习锁的知识我们知道了事务的隔离性是通过锁实现的（数据修改会产生排它锁，其他事务读取的是快照版本）

原子性、一致性、持久性通过数据库的redo log和undo log来完成

redo log

redo log 实现事务了的持久性，其由内存中的重做日志缓冲（redo log buff）和持久的重做日志文件（redo log file）组成。其中每次事务提交时，必须先将事务所有日志写入重做日志文件进行持久化。

redo log基本上都是顺序写入，而undo log是随机读写。

在每次重做日志缓冲写入重做日志后，系统都会调用一次fsync操作，确保重做日志写入磁盘。

bin log 记录了系统中的所有sql语句，redo log记录的是对每个页的修改

bin log 是在事务提完成后进行一次写入，redo log是在事务中不断被写入

undo

在对数据库修改不但会参生redo log，还会参生undo log，当事务失败和事务回滚时，可以利用undo log 回滚到事务前状态

除了回滚，mvcc也是通过undo 实现的，当读取某行数据被其他事务占用时，当前事务可以通过读取undo 之前版本的信息，来实现一致性非锁定读。undo log的参生会伴随着redo log 的参生，因为undo log也需要持久化

事务隔离级别

• 读未提交
• 读已提交
• 可重复读（默认）：使用Next-Key Lock 避免幻读
• 串行读：每个SELECT语句后自动加上LOCK IN SHARE MODE

分布式事务

InnoDB存储引擎提供了对XA事务的支持，并通过XA事务来支持分布式事务的实现

XA事务由一个或多个资源管理器（Resource Managers）、一个事务管理器（Transaction Manager）以及一个应用程序（Application Program）组成

资源管理器：提供访问事务资源的方法。通常一个数据库就是一个资源管理器。
事务管理器：协调参与全局事务中的各个事务。需要和参与全局事务的所有资源管理器进行通信。
应用程序：定义事务的边界，指定全局事务中的操作。

分布式事务使用两段式提交（two-phase commit）的方式。在第一阶段，所有参与全局事务的节点都开始准备（PREPARE），告诉事务管理器它们准备好提交了。在第二阶段，事务管理器告诉资源管理器执行ROLLBACK还是COMMIT。如果任何一个节点显示不能提交，则所有的节点都被告知需要回滚。可见与本地事务不同的是，分布式事务需要多一次的PREPARE操作，待收到所有节点的同意信息后，再进行COMMIT或是ROLLBACK操作。

关于分布式事务其实还有很多其他解决方案，比如TCC啥的，有兴趣可以自行了解，不在此进行解释