1.redo log

记录数据修改后的值，对事务持久性的保障，让数据库拥有崩溃恢复能力。
修改操作先对Buffer Pool的数据进行更新并且记录在redo log buffer中，如下图所示，redo log buffer 然后在刷盘到了硬盘中的redo log中。

上面提高了redo log buffer会进行刷盘，那刷盘的时机呢？InnoDB为redo log刷盘提高了innodb_flush_log_at_trx_commit 参数，支持三种策略。默认值为1.
0 ：设置为 0 的时候，表示每次事务提交时不进行刷盘操作
1 ：设置为 1 的时候，表示每次事务提交时都将进行刷盘操作（默认值）
2 ：设置为 2 的时候，表示每次事务提交时都只把 redo log buffer 内容写入 page cache
策略为0的时候：
> - 策略为1的时候：

策略为2的时候：

磁盘中的redo log不是单个文件，而是以文件组的方式存在的，如下图所示，通过write pos（记录写的位置，一遍写一遍后移）和checkpoint（记录是当前要擦除的位置，也是往后推移）来进行标志读写和清除。

存在一个问题，为什么会存在redo log，修改数据直接刷盘就行了？为什么还要存在redo log？因为直接刷盘是按照整个缓存页进行刷盘的，性能十分差，并且修改的数据位置也比较少，用redo log记录去刷盘，性能远远超过直接刷页。

2.binlog

只要发生表数据的更新就会有binlog日志，binlog会记录所有涉及数据的逻辑操作，并且是顺序写。
binlog的作用：MySQL数据库的数据备份、主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。
记录格式：通过binlog_format参数指定：statement（会根据没一条sql语句进行记录）、row（在对statement中处理不了的now()进行修补，用一个引用来代理）、mixed（前两者的混合）
写入机制：先把日志写入binlog cache中，事务提交之后在写入binlog中，如下图所示，系统是将binlog cache在写入文件系统page cache中，速度比较快，然后由fsyn持久化到次哦按中。

write和fsync的时机，可以由参数sync_binlog控制，默认是0。为0的时候，表示每次提交事务都只write，由系统自行判断什么时候执行fsync。

虽然性能得到提升，但是机器宕机，page cache里面的 binlog 会丢失。
为了安全起见，可以设置为1，表示每次提交事务都会执行fsync，就如同 redo log 日志刷盘流程一样。
最后还有一种折中方式，可以设置为N(N>1)，表示每次提交事务都write，但累积N个事务后才fsync。

两阶段提交

作用：为了解决redo log和binlog不一致的问题。
redo log的写入拆成两个步骤prepare和commit。如下图所示。
使用两阶段提交后，写入binlog时发生异常也不会有影响，因为MySQL根据redo log日志恢复数据时，发现redo log还处于prepare阶段，并且没有对应binlog日志，就会回滚该事务。