微信团队原创分享：微信客户端SQLite数据库损坏修复实践

本文由微信开发团队人员编写，转自 WeMobileDev，感谢。

1、引言

众所周知，微信在后台服务器不保存聊天记录，微信在移动客户端所有的聊天记录都存储在一个 SQLite 数据库中。一旦这个数据库损坏，将会丢失用户多年的聊天记录。而我们监控到现网的损坏率是0.02%，也就是每 1w 个用户就有 2 个会遇到数据库损坏。考虑到微信这么庞大的用户基数，这个损坏率就很严重了。更严重的是我们用的官方修复算法，修复成功率只有 30%。损坏率高，修复率低，这两个问题都需要我们着手解决。

* 推荐阅读：《微信本地数据库破解版(含iOS、Android)，仅供学习研究 [附件下载]》。

2、SQLite 数据库损坏原因分析

我们首先来看 SQLite 损坏的原因，SQLite官网(http://www.sqlite.org/howtocorrupt.html)上列出以下几点：

• 文件错写
• 文件锁 bug
• 文件 sync 失败
• 设备损坏
• 内存覆盖
• 操作系统 bug
• SQLite bug
  

但是我们通过收集到的大量案例和日志，分析出实际上移动端数据库损坏的真正原因其实就3个：

• 空间不足
• 设备断电
• 文件 sync 失败
  

接下来我们需要针对这些原因一一进行优化。

3、微信客户端对SQLite 损坏问题的优化策略

1优化空间占用

首先我们来优化微信的空间占用问题。在这之前微信的部分业务也做了空间清理，例如朋友圈会自动删除7天前缓存的图片。但是总的来说对文件空间的使用缺乏一个全局把控，全靠各个业务自觉。我们需要做得更积极主动，要让开发人员意识到用户的存储空间是宝贵的。我们采取以下措施：

• 业务文件先申请后使用，如果某个文件没有申请就使用了，会被自动扫描出来并删除；
• 每个业务文件都要申明有效期，是一天、一个星期、一个月还是永久存储；
• 过期文件会被自动清理。
  

对于微信之外的空间占用，例如相册、视频、其他App的空间占用，微信本身是做不了什么事情的，我们可以提示用户进行空间清理：

2优化文件 sync

第一步：synchronous = FULL
设置SQLite的文件同步机制为全同步，亦即要求每个事物的写操作是真的flush到文件里去。

第二步：fullfsync = 1
通过与苹果工程师的交流，我们发现在 iOS 平台下还有 fullfsync (https://www.sqlite.org/pragma.html#pragma_fullfsync) 这个选项，可以严格保证写入顺序跟提交顺序一致。设备开发商为了测评数据好看，往往会对提交的数据进行重排，再统一写入，亦即写入顺序跟App提交的顺序不一致。在某些情况下，例如断电，就可能导致写入文件不一致的情况，导致文件损坏。

3优化效果

多管齐下之后，我们成功将损坏率降低了一半多；DB损坏还是无法完全避免，我们还是得提高修复成功率。

4、SQLite 修复逻辑优化

1master 表

首先我们来看 SQLite 的架构。SQLite 使用 B+树 存储一个表，整个 SQLite 数据库就是这些 B+树 组成的森林。对于每个表的元数据（表名、根节点地址、表 scheme 等），都记录在一个叫 sql_master 的表中。这个 sql_master 表(下简称 master 表) 本身也是一个 B+树 存储的普通表。

2官方修复算法率低下原因

官方修复算法是这样一个流程：从 master 表中读出一个个表的信息，根据根节点地址和创表语句来 select 出表里的数据，能 select 多少是多少，然后插入到一个新 DB 中。要注意的是 master 表他本身也是一个 B+树 形式的普通表，DB 第0页就是他的根节点。那么只要 master 表某个节点损坏，这个节点下面记录的表就都恢复不了。更坏的情况是 DB 第0页损坏，那么整个 master 表都读不出来，就导致整个DB都恢复失败。这就是官方修复算法成功率这么低的原因，太依赖 master 表了。

3备份 master 表

那么最自然的想法，自然是另外备份一份 master 表了，也不需要用B+树，直接用数组序列化存储就好。我们只需要每隔一段时间轮询 master 表，看看最近有没有增删 table，有的话就全量备份。

备份时机：

这里有个担忧，就是普通数据表的插入会不会导致表的根节点发生变化，也就是说 master 表会不会频繁变化，如果变化很频繁的话，我们就不能简单地进行轮询方案了。通过分析源码，我们发现 SQLite 里面 B+树 算法的实现是 向下分裂 的，也就是说当一个叶子页满了需要分裂时，原来的叶子页会成为内部节点，然后新申请两个页作为他的叶子页。这就保证了根节点一旦定下来，是再也不会变动的。实际的代码调试也证实了我们这个推论。所以说 master 表只会在新创建表或者删除一个表时才会发生变化，我们完全可以采用定时轮询方案。

备份文件有效性：

接下来的难题是既然 DB 可以损坏，那么这个备份文件也会损坏，怎么办呢？我们采用了 双备份 的机制。具体来说就是会有新旧两个备份文件，每个文件头都加上 CRC 校验；每次备份时，从两个备份文件中选出一个进行覆盖。具体怎么选呢？优先选损坏那个备份文件，如果两个都有效，那么就选相对较旧的。这就保证了即使本次写入导致文件损坏，还有另外一份备份可以用。这个做法跟 Realm 标榜的 MVCC（多版本并发控制）的做法有异曲同工之妙，相当于确认新写入的文件有效之后，才使用新写入的文件，否则还是继续用旧的有效的文件。

前面提到 DB 损坏的一个常见场景是空间不足，这种情况下还要分配文件空间给备份文件也是会失败的。为了解决这个问题，我们采取 预先分配空间 的做法，初始值是 32K，大约可存 750 个表的元信息，后续则按照32K的倍数进行增长。

4优化效果

通过备份 master 表，我们成功将修复成功率提高了一倍多。

5、本文小结

通过这些优化，我们提高了微信聊天记录存储的可靠性。这些优化实践，会同之前在并发性能方面的优化实践（微信iOS SQLite源码优化实践），将会合并到微信即将开源的 WCDB（WeChat Database）组件中。我们正在进行紧张的代码整理工作，争取在 2017 年年中开源 WCDB。

后绪：WCDB已如期开源，详见《一篇文章get微信开源移动端数据库组件WCDB的一切！》。

（原文链接：点此进入）

附录：相关文章汇总

[1] 有关QQ、微信的技术文章：
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事：
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
>> 更多同类文章 ……

不得不说，微信的技术做的真是扎实

学习了~！~~相当不错的教程~~~~

引用：一地鼻血 发表于 2017-04-30 16:41
不得不说，微信的技术做的真是扎实

是啊，以前都没考虑过这个场景

厉害，必须收藏！

现在也开始接手做IM项目了，入职一年才发现有一个WCDB的库引入，看了下原来还有这个功能。学习了