关于double write的思考

double write是Innodb防止部分写的特性，大致原理是：
在把buffer pool脏页刷盘时，先把脏页写入内存中的double write buffer，之后将double write buffer的全部内容分两次写入系统表空间上连续的128个页，然后再把系统表空间上的double write数据写入到各个数据页对应的表的数据文件上。

那么问题就来了：
1.既然直接从buffer pool直接写一个数据页到磁盘，会发生部分写的情况，那么buffer pool buffer写到系统表空间上连续的128个页的时候，虽然是顺序写，效率比较快，也是有可能发生部分写的情况，因为都是从内存写入磁盘，本质还是刷盘。
那如果double write buffer写入系统表空间时发生部分写，也就是说，系统表空间上的double write数据也就存在部分写失效的问题了，这哪里是解决了部分写的问题呢？

2.double write特性比从buffer pool直接刷盘多了两个步骤：1)先写到double write buffer，2)从double write buffer写到系统表空间，然后才是将数据刷到对应的表文件中
那么如果某次刷盘数据比较大，大到double write buffer装不下，因为double write buffer默认大小是2M，那么自然是需要等double write buffer有空间了才能继续将脏页写入其中，而double write要腾空空间，就需要将其中的脏页写入系统表空间，由于是一次写入1M，而且在系统表空间上是顺序写，效率还算比较快，但是要写入系统表空间，也要系统表空间上连续128个页有位置才行，也就是说要等系统表空间上double write的数据写入到对应的表文件，才有空间接受来自内存的新的double write数据，而这时系统表表空间的数据页写入对应标文件，是离散的磁盘写，速度相对较慢，那么也就拖慢了整个流程。
所以double write的特性舍弃了一部分写入效率，而获取了安全性。

问题2是double write拖慢写入性能，那么问题1该如何解释呢？
还没有看过相关源码，但如果让我来设计double write的逻辑解决问题1，应该是这样：
从double write buffer写入系统表空间完整后，再马上调用fsync函数将这些脏页刷到对应的表文件；而如果从double write buffer写入系统表空间的过程还没结束，那么就不会调用fsync函数将这些脏页刷到对应的表文件；
也就是说，只有等系统表空间上对应的1M数据写完整了，才把这一批脏页写入对应的表文件。
那么这样的逻辑，在各种异常情况下都可以进行实例恢复：
1.假如从buffer pool写入double write buffer的过程中，实例挂了，那么这时候脏页还在内存中，重启实例时只要根据磁盘页应用redo日志即可恢复；
2.假如从double write buffer写入系统表空间的过程中，实例挂了，那么这时这一批脏页有可能在系统表空间上存在部分写的情况，但是由于还没有将这一批脏页完整地写入系统表空间，所以尚未将这些脏页写到各自的表文件，也就是说这时这一批脏页对应表文件还是完好的；那么重启实例时也是根据磁盘页应用redo日志即可恢复；
3.假如已经把一批脏页从double write buffer写入系统表空间，在调用fsync将这一批脏页写入各自的表文件时，实例挂了，那么这时脏页在写入各自标文件时有可能会发生部分写失效的情况，但没关系，在系统表空间上还保存这些脏页，实例重启时，只要把存在部分写失效的页从系统表空间再写入一次即可。

double write相对于直接刷盘，区别是
1.多了一次从buffer pool拷贝脏页到double write buffer的操作；
2.多了一次从double write buffer写入系统表空间的磁盘写；
3.需要从系统表空间写入各自表文件。

可以看出，步骤1是内存操作，效率比较快，步骤2是磁盘写，但是由于是顺序写，效率也比较快，而步骤3是离散磁盘写。
所以write double多了一次磁盘写，但并不是造成2倍的IO压力。