android wal模式,WCDB 的 WAL 模式和异步 Checkpoint

WAL 模式是 SQLite 3.7.0 版本推出的改进写性能和并发性的功能，至今已经7年多了，但由于WAL是默认关闭的，可能有相当多的应用并没有用上，仍然使用性能较差的传统模式。

微信 APP 开启了 WAL 模式，同时还针对 WAL 做了一点改进 —— 异步 Checkpoint。通过 A/B Test，最终相比传统 Rollback 模式写耗时减少 70% 以上，还稍稍降低了 DB 损坏率。

WAL 和异步 Checkpoint

SQLite 实现 原子性提交和回滚操作 的默认方法是 rollback journal。当对 DB 进行写操作的时候，SQLite 首先将准备要修改部分的原始内容(以 Page 为单位)拷贝到“回滚日志”中，用于后续可能的 Rollback 操作以及 Crash、断电等意外造成写操作中断时恢复 DB 的原始状态，回滚日志存放于名为“DB文件名-journal”的独立文件中(以下简称“-journal”)。对原始内容做备份后，才能写入修改后的内容到 DB 主文件中，当写入操作完成，用户提交事务后，SQLite 清空 -journal 的内容，至此完成一个完整的写事务。

图：Rollback journal 工作模式

Rollback 模式中，每次拷贝原始内容或写入新内容后，都需要确保之前写入的数据真正写入到磁盘，而不是缓存在操作系统中，这需要发起一次 fsync 操作，通知并等待操作系统将缓存真正写入磁盘，这个过程十分耗时。

除了耗时的 fsync 操作，写入 -journal 以及 DB 主文件的时候，是需要独占整个 DB 的，否则别的线程/进程可能读取到写到一半的内容。这样的设计使得写操作与读操作是互斥的，并发性很差。

WAL 模式则改变了上述流程，写操作不直接写入 DB 主文件，而是写到“DB文件名-wal”文件(以下简称“-wal”)的末尾，并且通过 -shm 共享内存文件来实现 -wal 内容的索引。读操作时，将结合 DB 主文件以及 -wal 的内容返回结果。由于读操作只读取 DB 主文件和 -wal 前面没在写的部分，不需要读取写操作正在写到一半的内容，WAL 模式下读与写操作的并发由此实现。WCDB 的多线程并发，也是基于 WAL 模式下实现连接池实现的。

WAL 写操作除了上面的流程，还增加了一步：Checkpoint࿰