微信 SQLite 數據庫修復實踐
1、前言
眾所周知，微信在后臺服務器不保存聊天記錄，微信在移動客戶端所有的聊天記錄都存儲在一個 SQLite 數據庫中，一旦這個數據庫損壞，將會丟失用戶多年的聊天記錄。而我們監控到現網的損壞率是0.02%，也就是每 1w 個用戶就有 2 個會遇到數據庫損壞。考慮到微信這么龐大的用戶基數，這個損壞率就很嚴重了。更嚴重的是我們用的官方修復算法，修復成功率只有 30%。損壞率高，修復率低，這兩個問題都需要我們著手解決。
2、SQLite 損壞原因及其優化
我們首先來看 SQLite 損壞的原因，SQLite官網( http://www.sqlite.org/howtocorrupt.html )上列出以下幾點：
-
文件錯寫
-
文件鎖 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 ( https://www.sqlite.org/pragma.html#pragma_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、其他
通過這些優化，我們提高了微信聊天記錄存儲的可靠性。這些優化實踐，會同之前在并發性能方面的優化實踐，將會合并到微信即將開源的 WCDB（WeChat Database）組件中。我們正在進行緊張的代碼整理工作，爭取在 2017 年年中開源 WCDB。
來自：https://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=2649286467&idx=1&sn=ea5b6dbfecffd33e333ec814473e1313&chksm=8334c3c1b4434ad7c364ff3acae1e62bc5e871a7350aa9cdcb24bd299b42875f0b020acb3620