微信 SQLite 数据库修复实践

作者:guoling

1、前言

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

2、SQLite 损坏原因及其优化

我们首先来看 SQLite 损坏的原因,SQLite官网上列出以下几点:

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

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

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

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

2.1、优化空间占用

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

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

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

2.2、优化文件 sync

2.2.1、synchronous = FULL

设置SQLite的文件同步机制为全同步,亦即要求每个事物的写操作是真的flush到文件里去。

2.2.1、fullfsync = 1

通过与苹果工程师的交流,我们发现在 iOS 平台下还有 fullfsync 这个选项,可以严格保证写入顺序跟提交顺序一致。设备开发商为了测评数据好看,往往会对提交的数据进行重排,再统一写入,亦即写入顺序跟App提交的顺序不一致。在某些情况下,例如断电,就可能导致写入文件不一致的情况,导致文件损坏。

2.3、优化效果

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

3、SQLite 修复逻辑优化

3.1、master 表

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

3.2、官方修复算法率低下原因

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

3.3、备份 master 表

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

3.3.1、备份时机

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

3.3.2、备份文件有效性

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

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

3.4、优化效果

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

4、其他

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

本文来源于:WeMobileDev 微信公众号

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

5 条评论
登录 后参与评论

相关文章

来自专栏ImportSource

Docker架构里那些名字背后的秘密

Docker作为一个linux平台上一款轻量级虚拟化容器的管理引擎。在短短的两三年内火得不得了。人人都在说docker,大大小小的容器summit。 Docke...

3415
来自专栏数据和云

静默错误:Oracle 数据库是如何应对和处理的 ?

说明:关于本文提到的所有参考文档,一律上传分享,关注本公众号回复 122arch 获得。

732
来自专栏后端技术探索

Nginx从听说到学会(1.简介和对比)

没有听过Nginx?那么一定听过它的“同行”Apache吧!Nginx同Apache一样都是一种WEB服务器。基于REST架构风格,以统一资源描述符(Unifo...

653
来自专栏互联网高可用架构

白话阿里巴巴Java开发手册(安全规约)

1222
来自专栏北京马哥教育

常用集群架构实战练习篇

一、简介 企业中常用的web架构主要的目的是实现高可用及其容灾备份,说白了就是让用户有更好的用提体验,一个架构的可用性只有在经历过上线后接受用户的使用才能体现...

4136
来自专栏北京马哥教育

Linux 的 OOM 终结者

现在是早晨6点钟。已经醒来的我正在总结到底是什么事情使得我的起床闹铃提前了这么多。故事刚开始的时候,手机铃声恰好停止。又困又烦躁的我看了下手机,看看是不是我自己...

3446
来自专栏FreeBuf

基于Casbin的Docker权限管理访问控制插件

Docker是目前主流的一种容器技术。为了解决多用户同时访问Docker时产生的安全问题,Docker设计了访问控制插件(Authorization Plugi...

594
来自专栏杨建荣的学习笔记

VXFS启用异步IO导致的严重问题(r2笔记56天)

今天在做数据迁移的时候,碰到了一个严重的问题,数据加载完全hang住了,最后无奈回退了。 系统使用的vxfs文件系统,在生产升级前一个月的时候,做过一次小规模的...

3177
来自专栏黑白安全

跨站点请求伪造(CSRF)攻击

跨站点请求伪造(CSRF),也称为XSRF,Sea Surf或会话骑马,是一种攻击媒介,它会诱使Web浏览器在用户登录的应用程序中执行不需要的操作。

583
来自专栏企鹅号快讯

TRITON病毒可渗透关键基础设施,导致工控系统关机

据美国安全厂商FireEye报告:民族国家黑客使用了一款名为TRITON的恶意软件渗透了一个关键基础设施的安全系统,导致了工控系统关机。该恶意软件对施耐德电气S...

3388

扫码关注云+社区