结论：只要redo log和binlog保证持久化到磁盘，就能确保MySQL异常重启后，数据可以恢复。
binlog的写入机制
日志写入binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。
每个线程都会被系统给binlog cache分配一片内存，参数binlog_cache_size用于控制单个线程内binlog cache所占内存的大小，超过之后就要暂存到磁盘
1 write操作指的是把日志写到文件系统的page cache,没有持久化到磁盘，所以比较快
2 fsync才将数据持久化到磁盘，这个才占磁盘IOPS
sync_binlog=0 的时候，表示每次事务都只write,不fsync
sync_binlog=1的时候，表示每次事务都会执行fsync
sync_binlog=N的时候，表示每次提交都write,但是N个事务之后才fsync
一般设置为100-1000中的值
redo log 的写入机制
redo log buffer中的并不是每次生成后都需要持久化到磁盘，但是由于自动执行的线程会刷一部分进到磁盘
innodb_flush_log_at_trx_commit设置值
1 为0的时候，每次事务提交，只是留在redo log buffer中
2 为1的时候，每次事务提交，直接持久化到磁盘
3 为2的时候 ，每次事务提交，直到page cache
innoDB 后台有一个线程，每隔1s 就会把redo log buffer中的日志，调用write写到文件系统的page cache,然后fsync持久化到磁盘
另外两种场景也会让redo log写入到磁盘中
1 一种是 redo log buffer到innodb_log_buffer_size一半的时候，后台线程会自动写盘。只是到page cache
2 并行的事务提交，顺带着把这个事务的redo log buffer持久化到磁盘