面试系列-innodb存储引擎的架构设计

1. 缓冲池Buffer pool：缓存很多的数据，以便于以后在查询的时候，万一你要是内存缓冲池里有数据，就可以不用去查磁盘了；

1. undo日志文件：更新的数据回滚；
2. Redo Log Buffer：内存里的数据进行了修改，但是磁盘上的数据还没修改，万一MySQL所在的机器宕机了，必然会导致内存里修改过的数据丢失，避免数据丢失，把对内存所做的修改写入到一个Redo Log Buffer里去，这也是内存里的一个缓冲区，是用来存放redo日志；

提交事务的时候将redo日志写入磁盘中：

策略配置：innodb_flush_log_at_trx_commit
0：参数的值为0的时候，那么提交事务的时候，不会把redo log buffer里的数据刷入磁盘文件的，
   此时可能都提交事务了，结果mysql宕机了，然后此时内存里的数据全部丢失。
   相当于提交事务成功了，但是由于MySQL突然宕机，导致内存中的数据和redo日志都丢失了
1：参数的值为1的时候，提交事务的时候，就必须把redo log从内存刷入到磁盘文件里去，
   只要事务提交成功，那么redo log就必然在磁盘里了
2：提交事务的时候，把redo日志写入磁盘文件对应的os cache缓存里去，而不是直接进入磁盘文件，可
   能1秒后才会把os cache里的数据写入到磁盘文件里去。这种模式下，提交事务之后，
   redo log可能仅仅停留在os cache内存缓存里，没实际进入磁盘文件，万一此时要是机器宕机了，
   那么os cache里的redo log就会丢失，同样会让感觉提交事务了，结果数据丢了

提交事务的时候，redo日志必须是刷入磁盘文件里的。这样可以严格的保证提交事务之后，数据是绝对不会丢失的，因为有redo日志在磁盘文件里可以恢复你做的所有修改。如果要是选择0的话，可能你提交事务之后，mysql宕机，那么此时redo日志没有刷盘，导致内存里的redo日志丢失，你提交的事务更新的数据就丢失了；如果要是选择2的话，如果机器宕机，虽然之前提交事务的时候，redo日志进入os cache了，但是还没进入磁盘文件，此时机器宕机还是会导致os cache里的redo日志丢失；所以对于数据库这样严格的系统而言，一般建议redo日志刷盘策略设置为1，保证事务提交之后，数据绝对不能丢失。

1. binlog归档日志，binlog不是InnoDB存储引擎特有的日志文件，是属于mysql server自己的日志文件。

提交事务的时候，会把redo log日志写入磁盘文件中去。然后其实在提交事务的时候，我们同时还会把这次更新对应的binlog日志写入到磁盘文件中去。

1. binlog日志的刷盘策略：

策略配置：sync_binlog
0：默认值是0，此时你把binlog写入磁盘的时候，其实不是直接进入磁盘文件，而是进入os cache内存缓存。
如果此时机器宕机，那么你在os cache里的binlog日志是会丢失的
1:设置为1的话，那么此时会强制在提交事务的时候，把binlog直接写入到磁盘文件里去，
那么这样提交事务之后，哪怕机器宕机，磁盘上的binlog是不会丢失的

1. 基于binlog和redo log完成事务的提交：

当把binlog写入磁盘文件之后，接着就会完成最终的事务提交，此时会把本次更新对应的binlog文件名称和这次更新的binlog日志在文件里的位置，都写入到redo log日志文件里去，同时在redo log日志文件里写入一个commit标记。根据redo log中的最终commit标记，标记事务的成功与否，保证数据最终的准确性。

1. 后台IO线程随机将内存更新后的脏数据刷回磁盘

MySQL有一个后台的IO线程，会在之后某个时间里，随机的把内存buffer pool中的修改后的脏数据给刷回到磁盘上的数据文件里去，IO线程把buffer pool里的修改后的脏数据刷回磁盘的之后，磁盘上的数据才会跟内存里一样，在你IO线程把脏数据刷回磁盘之前，哪怕mysql宕机崩溃也没关系，因为重启之后，会根据redo日志恢复之前提交事务做过的修改，然后等适当时机，IO线程自然还是会把这个修改后的数据刷到磁盘上的数据文件里去的；