redo log 叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中。
PS：mysql 为了提升性能不会把每次的数据修改都实时同步到磁盘，而是会先存到 Boffer Pool(缓冲池)里头，把这个当作缓存来用。然后使用后台线程去做缓冲池和磁盘之间的同步。 redo log 主要用来恢复数据， 用于保障，已提交事务的持久化特性（宕机时，redo log 的信息是全的）
2.undo log
undo log 叫做回滚日志，用于记录数据被修改前的信息。他正好跟前面所说的重做日志所记录的相反，重做日志记录数据被修改后的信息。
undo log 主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。
PS：mysql 每次写入数据或者修改数据之前都会把修改前的信息记录到 undo log undo log 是用来回滚数据，用于保障 未提交事务的原子性
3.mysql 锁技术
当多个请求同时来临时，mysql 要控制读读可并行，而写读，写写不能并行
4.MVCC 基础
MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制。
InnoDB 的 MVCC ，是通过在每行记录的后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存了行的过期时间，当然存储的并不是实际的时间值，而是系统版本号。
他的主要实现思想是通过数据多版本来做到读写分离。从而实现不加锁读进而做到读写并行。
总结
事务的原子性是通过 undo log 来实现的
事务的持久性是通过 redo log 来实现的 -事务的隔离性是通过 (读写锁+MVCC)来实现的
而事务的终极大 boss 一致性是通过原子性，持久性，隔离性来实现的！！！
2.分布式事务 2.1分布式事务概念 2.1.1 分布式事务产生的原因随着互联网高速发展，事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用。在这种环境中，我们之前说过数据库的 ACID 四大特性，已经无法满足我们分布式事务。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
CAP 定理，又被叫作布鲁尔定理。CAP 指的是：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 定律说的是，在一个分布式系统中，最多只能满足 C、A、P 中的两个，不可能三个同时满足。而在分布式系统中，网络无法 100% 可靠，分区其实是一个必然现象。
如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是 A 又不允许，所以分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。
而且，显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。
2.1.3 BASE 理论往往在分布式系统中无法实现完全一致性，于是有了BASE 理论，它是对 CAP 定律的进一步扩充
BASE 指的是：
Basically Available（基本可用） ： 分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用
Soft state（软状态）： 允许系统中存在中间状态，这个状态不影响系统可用性
Eventually consistent（最终一致性） ： 经过一段时间后，所有节点数据都将会达到一致