write-ahead-log与append-only-file的原理

2019独角兽企业重金招聘Python工程师标准>>>

    无论是RMSDB，还是NOSQL DB，如何最大程度上保证故障时的数据恢复，都涉及到数据持久化的技术。本位重点说明write-ahead-log与append-only-file这两种持久化机制的原理。

    write-ahead-log，WAL日志,是数据库中一种高效的日志算法。从数据库原理而言，它实现的是redo日志模式。即修改数据库时，不直接修改数据库内容，而是将修改完的数据写入日志同步到磁盘上，这样对其他读进程就没有影响。如果数据库崩溃，重启后扫描日志文件，然后更新到数据库中。为了提高效率，WAL日志模式提供checkpoint操作，来定时进行数据更新操作。

    以SQLite、MapDB为例，WAL的实现就是是按照上面原理来的。在更新数据页时，会将更新完的页先同步到磁盘上，并定时进行checkpoint操作。读数据库的时候，为了读到最新的页面，需要扫描日志文件，得到最新的数据页。为了提高日志文件扫描速度，还需要设计一些wal-index索引来加快对WAL日志的操作速度。

    append-only-file，AOF日志，以Redis为例。在Redis异常死掉时，最近的数据会丢失（丢失数据的多少视你save策略而定），当业务量很大时，可能丢失的数据会很多。Append-only方法可以做到全部数据不丢失，但Redis的性能就要差些。AOF就可以做到全程持久化，开启AOF之后，Redis每执行一个修改数据的命令，都会把它添加到aof文件中，当Redis重启时，将会读取AOF文件进行“Log-Rewriting 重放”以恢复到Redis关闭前的最后时刻。

    Log-Rewriting随着AOF文件越来越大，重放速度会越来越慢。但是AOF中如同流水账一样，会记录很多某一个key的全部变化过程。因此Redis有了一种比较有意思的特性：会在后台重建AOF文件，而不会影响client端操作。在任何时候执行BGREWRITEAOF命令，会对当前AOF中的数据进行整合，为每个key重新生成最短序列的AOF文件，这些数据完全可以用于构建当前某个Key的数据情况，而不会存在多余的变化情况（比如状态变化，计数器变化等），从而缩小了AOF文件的大小。所以当使用AOF时，redis推荐同时使用BGREWRITEAOF。

    AOF文件刷新的方式，有三种，参考配置参数appendfsync ：appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全；appendfsync everysec每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据；appendfsync no依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差。默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。

    LOG Rewrite的工作原理:同样用到了copy-on-write：首先redis会fork一个子进程；子进程将最新的AOF写入一个临时文件；父进程增量的把内存中的最新执行的修改写入（这时仍写入旧的AOF，rewrite如果失败也是安全的）；当子进程完成rewrite临时文件后，父进程会收到一个信号，并把之前内存中增量的修改写入临时文件末尾；这时redis将旧AOF文件重命名，临时文件重命名，开始向新的AOF中写入。

转载于:https://my.oschina.net/blacklands/blog/875179