由一個bug引起的SQLite緩存一致性探索

問題

     咱們在生產環境中使用SQLite時中發現建表報「table xxx already exists」錯誤，但DB文件中並無該表。後面才發現這個是SQLite在實現過程當中的一個bug，而這個bug與數據字典的一致性相關，下面這篇文章主要討論SQLite的緩存機制，以及緩存一致性實現的策略，但願對你們瞭解SQLite緩存機制有必定的幫助。

緩存

      SQLite中緩存主要包括兩方面，數據字典緩存和數據頁緩存。SQLite自己是一個文件數據庫，全部的數據都在一個DB文件中，文件以塊(page)的形式存放，默認狀況下每一個page是1024個字節。爲了不每次訪問都產生磁盤IO，針對數據塊在SQLite內部實現了一層緩存
pagecache，pagecache的做用就是緩存頁數據。在SQLite內部，除了用戶數據，還有一部份內容是元數據信息，包括表，視圖，索引和觸發器等，這部分元數據信息在數據庫領域通常稱爲數據字典，這部分信息也存在DB文件中。因爲每次執行語句時，都須要數據字典進行語義分析和執行計劃優化(表是否存在，列是否存在，是否有索引可用，是否存在觸發器等)，若是每次獲取這些信息時，都須要從DB文件中獲取，則很是影響性能。你可能會說，不是已經有pagecache了嗎？對的，數據字典的內容也緩存在pagecahce中，可是，要知道page中的數據都是二進制的，須要對內容進行解析產生結構化數據才能使用。爲此，爲了不分析語句時，頻繁解析獲取數據字典，將解析好的數據進行緩存，以供屢次使用，提升效率。

數據頁緩存一致性
     咱們這裏討論的數據頁緩存對應MySQL的概念就是BufferPool，固然其它數據庫Oracle，SQLServer都有相似的概念。
傳統PC上面的數據庫，都是在數據庫服務啓動時，根據參數設定值一次性分配特定大小的BufferPool。而SQLite採用懶分配策略，即「用多少則分配多少」，pagecache默認大小是2000個page，2000個page能夠認爲是一個緩存的上限。一次性分配的好處是，內存在物理是連續的，不容易產生內存碎片；而懶分配則更節約內存，因爲SQLite通常用於端設備，採用懶分配方式可能更經濟實惠。SQLite的緩存分配策略採用LRU，保留最近訪問的page，淘汰最老的page。
      SQLite中每一個數據庫鏈接對應一個DB句柄，應用經過DB句柄來操做數據庫，而pagecache實際上就做爲一個成員掛在DB句柄中，所以每一個DB句柄都有本身獨立的緩存，這點與傳統的PC數據庫不一樣(好比MySQL中，全部鏈接共享BufferPool)。既然每一個DB句柄有獨立的緩存，那麼緩存之間如何同步？好比有Connection1和Connection2兩個鏈接，Connection1首先從文件中讀取了page_A並加入到了緩存；隨後Connection2也從文件中讀取Page_A，並進行了更新；那麼當Connection1再次讀取page_A時，Connection1如何知道本身緩存的page_A已經不是最新了，須要從新到DB文件中讀取？
SQLite爲了處理這個問題，在DB的文件控制頭中存放的DB的版本信息，開始執行SQL時會讀取DB的版本信息並緩存，如何發現本次的版本信息與以前的不一樣，則確認DB文件已經被修改，清理自身的緩存。每次事務提交時，都會調用pager_write_changecounter進行更新，具體位置在第一頁的第24個字節，佔4個字節。

數據字典緩存一致性
     咱們這裏討論的數據字典對應MySQL的概念就是information_schema的系統表，字典緩存就是對系統表信息的結構化信息存儲。在SQLite中字典信息採用Hash表存儲，包括(tblHash,idxHash,trigHash和fkeyHash等)判斷一個對象是否存在的依據是Hash表中對象是否存在。openDatabase函數經過調用sqlite3Init對數據字典進行初始化，並設置標記。與數據頁緩存同樣，字典緩存也是每一個DB句柄有單獨的一份數據，一樣的，SQLite文件頭中一樣存放了數據字典的版本信息，具體位置在第一頁的第40個字節，佔4個字節。進行DDL操做時(CREATE,DROP,ALTER等)，會調用sqlite3ChangeCookie更新字典版本號(Schema cookie)。在Prepare階段分析語句時，若發現對象不存在，會觸發一次Schema cookie檢查，若是數據字典不是最新，則會調用sqlite3SchemaClear進行清理，並從新加載數據字典。另外，SQLite的數據字典表很是簡單，主要在sqlite_master表中，每一個對象都是一行記錄，記錄中包含了表定義，加載字典時，實際就是將表定義語句分析一遍，經過調用sqlite3EndTable將對象加入Hash表，很是方便。

小結
     能夠看到，不管數據頁緩存也好，數據字典緩存也好，SQLite都是採用一個版本號來控制版本信息，很是簡單實用，但缺點是粒度很是大。若是DB寫很是頻繁，那麼每次讀基本都會致使物理IO，可能修改的是A表，訪問B表也須要將緩存清空。這裏也能夠解釋爲何頁緩存是「懶加載」模式，這樣清空緩存的代價也相對較小。對於數據字典緩存，粒度一樣很粗，每修改一個表，視圖，觸發器等對象，都會觸發數據字典版本更新。固然SQLite不會傻傻的每次執行SQL時都去判斷本身的版本是否最新，只是在訪問對象時，對象不存在的狀況纔去檢查版本，這樣在必定程度上減小了加載的次數，但這樣也帶來了問題，下面回到問題自己。

回到問題
     前面咱們拋出了一個SQLite的bug，這裏來細說前因後果。假設有兩個DB句柄，分別稱爲A和B。執行以下序列： A：create table t(id int); B：DROP table if exists t; A: create table t(id int); 第二次A建表時會報「table t already exists」錯誤，而實際上表已經不存在了。這主要緣由就是第3步A建表時發現表存在並無觸發去判斷數據字典是否最新的邏輯，致使誤報。復現該問題時要注意關閉sharecache,由於在sharecache模式下，全部的DB句柄共享一個緩存區。其實問題很簡單，但猜想復現問題仍是花了一點精力。