SQLite教程（十二）：鎖和並發控制詳解，sqlite詳解

SQLite教程（十二）：鎖和並發控制詳解，sqlite詳解

一、概述：

    在SQLite中，鎖和並發控制機制都是由pager_module模組負責處理的，如ACID(Atomic, Consistent, Isolated, and Durable)。在含有資料修改的事務中，該模組將確保或者所有的資料修改全部提交，或者全部復原。與此同時，該模組還提供了一些磁碟檔案的記憶體Cache功能。
    事實上，pager_module模組並不關心資料庫儲存的細節，如B-Tree、編碼方式、索引等，它只是將其視為由統一大小(通常為1024位元組)的資料區塊構成的單一檔案，其中每個塊被稱為一個頁(page)。在該模組中頁的起始編號為1，即第一個頁的索引值是1，其後的頁編號以此類推。
   
二、檔案鎖：

    在SQLite的目前的版本中，主要提供了以下五種方式的檔案鎖狀態。
    1). UNLOCKED：
    檔案沒有持有任何鎖，即當前資料庫不存在任何讀或寫的操作。其它的進程可以在該資料庫上執行任意的讀寫操作。此狀態為預設狀態。
    2). SHARED：
    在此狀態下，該資料庫可以被讀取但是不能被寫入。在同一時刻可以有任意數量的進程在同一個資料庫上持有共用鎖定，因此讀操作是並發的。換句話說，只要有一個或多個共用鎖定處於活動狀態，就不再允許有資料庫檔案寫入的操作存在。
    3). RESERVED：
    假如某個進程在將來的某一時刻打算在當前的資料庫中執行寫操作，然而此時只是從資料庫中讀取資料，那麼我們就可以簡單的理解為資料庫檔案此時已經擁有了保留鎖。當保留鎖處於活動狀態時，該資料庫只能有一個或多個共用鎖定存在，即同一資料庫的同一時刻只能存在一個保留鎖和多個共用鎖定。在Oracle中此類鎖被稱之為預寫鎖，不同的是Oracle中鎖的粒度可以細化到表甚至到行，因此該種鎖在Oracle中對並發的影響程式不像SQLite中這樣大。
    4). PENDING：
    PENDING鎖的意思是說，某個進程正打算在該資料庫上執行寫操作，然而此時該資料庫中卻存在很多共用鎖定(讀操作)，那麼該寫操作就必須處於等待狀態，即等待所有共用鎖定消失為止，與此同時，新的讀操作將不再被允許，以防止寫鎖饑餓的現象發生。在此等待期間，該資料庫檔案的鎖狀態為PENDING，在等到所有共用鎖定消失以後，PENDING鎖狀態的資料庫檔案將在擷取獨佔鎖定之後進入EXCLUSIVE狀態。
    5). EXCLUSIVE：
    在執行寫操作之前，該進程必須先擷取該資料庫的獨佔鎖定。然而一旦擁有了獨佔鎖定，任何其它鎖類型都不能與之共存。因此，為了最大化並發效率，SQLite將會最小化獨佔鎖定被持有的時間總量。
   
    最後需要說明的是，和其它關係型資料庫相比，如MySQL、Oracle等，SQLite資料庫中所有的資料都儲存在同一檔案中，與此同時，它卻僅僅提供了粗粒度的檔案鎖，因此，SQLite在並發性和伸縮性等方面和其它關係型資料庫還是無法比擬的。由此可見，SQLite有其自身的適用情境，就如在本系列開篇中所說，它和其它關係型資料庫之間的互換性還是非常有限的。

三、復原日誌：

    當一個進程要改變資料庫檔案的時候，它首先將未改變之前的內容記錄到復原記錄檔中。如果SQLite中的某一事務正在試圖修改多個資料庫中的資料，那麼此時每一個資料庫都將產生一個屬於自己的復原記錄檔，用於分別記錄屬於自己的資料改變，與此同時還要產生一個用於協調多個資料庫操作的主要資料庫記錄檔，在主要資料庫記錄檔中將包含各個資料庫復原記錄檔的檔案名稱，在每個復原記錄檔中也同樣包含了主要資料庫記錄檔的檔案名稱資訊。然而對於無需主要資料庫記錄檔的復原記錄檔，其中也會保留主要資料庫記錄檔的資訊，只是此時該資訊的值為空白。
    我們可以將復原日誌視為"HOT"記錄檔，因為它的存在就是為了恢複資料庫的一致性狀態。當某一進程正在更新資料庫時，應用程式或OS突然崩潰，這樣更新操作就不能順利完成。因此我們可以說"HOT"日誌只有在異常條件下才會產生，如果一切都非常順利的話，該檔案將永遠不會存在。

四、資料寫入：

    如果某一進程要想在資料庫上執行寫操作，那麼必須先擷取共用鎖定，在共用鎖定擷取之後再擷取保留鎖。因為保留鎖則預示著在將來某一時刻該進程將會執行寫操作，所以在同一時刻只有一個進程可以持有一把保留鎖，但是其它進程可以繼續持有共用鎖定以完成資料讀取的操作。如果要執行寫操作的進程不能擷取保留鎖，那麼這將說明另一進程已經擷取了保留鎖。在此種情況下，寫操作將失敗，並立即返回SQLITE_BUSY錯誤。在成功擷取保留鎖之後，該寫進程將建立復原日誌。
    在對任何資料作出改變之前，寫進程會將待修改頁中的原有內容先行寫入復原記錄檔中，然而，這些資料發生變化的頁起初並不會直接寫入磁碟檔案，而是保留在記憶體中，這樣其它進程就可以繼續讀取該資料庫中的資料了。
    或者是因為記憶體中的cache已滿，或者是應用程式已經提交了事務，最終，寫進程將資料更新到資料庫檔案中。然而在此之前，寫進程必須確保沒有其它的進程正在讀取資料庫，同時復原日誌中的資料確實被物理的寫入到磁碟檔案中，其步驟如下：
    1). 確保所有的復原日誌資料被物理的寫入磁碟檔案，以便在出現系統崩潰時可以將資料庫恢複到一致的狀態。
    2). 擷取PENDING鎖，再擷取獨佔鎖定，如果此時其它的進程仍然持有共用鎖定，寫入線程將不得不被掛起並等待直到那些共用鎖定消失之後，才能進而得到獨佔鎖定。
    3). 將記憶體中持有的修改頁寫出到原有的磁碟檔案中。
    如果寫入到資料庫檔案的原因是因為cache已滿，那麼寫入進程將不會立刻提交，而是繼續對其它頁進行修改。但是在接下來的修改被寫入到資料庫檔案之前，復原日誌必須被再一次寫到磁碟中。還要注意的是，寫入進程擷取到的獨佔鎖定必須被一直持有，直到所有的改變被提交時為止。這也意味著，從資料第一次被重新整理到磁碟檔案開始，直到事務被提交之前，其它的進程不能訪問該資料庫。
    當寫入進程準備提交時，將遵循以下步驟：
    4). 擷取獨佔鎖定，同時確保所有記憶體中的變化資料都被寫入到磁碟檔案中。
    5). 將所有資料庫檔案的變化資料物理的寫入到磁碟中。
    6). 刪除記錄檔。如果在刪除之前出現系統故障，進程在下一次開啟該資料庫時仍將基於該HOT日誌進行恢複操作。因此只有在成功刪除記錄檔之後，我們才可以認為該事務成功完成。
    7). 從資料庫檔案中刪除所有的獨佔鎖定和PENDING鎖。
    一旦PENDING鎖被釋放，其它的進程就可以開始再次讀取資料庫了。
    如果一個事務中包含多個資料庫的修改，那麼它的提交邏輯將更為複雜，見如下步驟：
    4). 確保每個資料庫檔案都已經持有了獨佔鎖定和一個有效記錄檔。
    5). 建立主要資料庫記錄檔，同時將每個資料庫的復原記錄檔的檔案名稱寫入到該主要資料庫記錄檔中。
    6). 再將主要資料庫記錄檔的檔案名稱分別寫入到每個資料庫復原記錄檔的指定位置中。
    7). 將所有的資料庫變化持久化到資料庫磁碟檔案中。
    8). 刪除主記錄檔，如果在刪除之前出現系統故障，進程在下一次開啟該資料庫時仍將基於該HOT日誌進行恢複操作。因此只有在成功刪除主記錄檔之後，我們才可以認為該事務成功完成。
    9). 刪除每個資料庫各自的記錄檔。
    10).從所有資料庫中刪除掉獨佔鎖定和PENDING鎖。
   
    最後需要說明的是，在SQLite2中，如果多個進程正在從資料庫中讀取資料，也就是說該資料庫始終都有讀操作發生，即在每一時刻該資料庫都持有至少一把共用鎖定，這樣將會導致沒有任何進程可以執行寫操作，因為在資料庫持有讀鎖的時候是無法擷取寫鎖的，我們將這種情形稱為"寫饑餓"。在SQLite3中，通過使用PENDING鎖則有效避免了"寫饑餓"情形的發生。當某一進程持有PENDING鎖時，已經存在的讀操作可以繼續進行，直到其正常結束，但是新的讀操作將不會再被SQLite接受，所以在已有的讀操作全部結束後，持有PENDING鎖的進程就可以被啟用並試圖進一步擷取獨佔鎖定以完成資料的修改操作。
   
五、SQL層級的事務控制：

    SQLite3在實現上確實針對鎖和並發控製做出了一些精巧的變化，特別是對於事務這一SQL語言層級的特徵。在預設情況下，SQLite3會將所有的SQL操作置於antocommit模式下，這樣所有針對資料庫的修改操作都會在SQL命令執行結束後被自動認可。在SQLite中，SQL命令"BEGIN TRANSACTION"用於顯式的聲明一個事務，即其後的SQL語句在執行後都不會自動認可，而是需要等到SQL命令"COMMIT"或"ROLLBACK"被執行時，才考慮提交還是復原。由此可以推斷出，在BEGIN命令被執行後並沒有立即獲得任何類型的鎖，而是在執行第一個SELECT語句時才得到一個共用鎖定，或者是在執行第一個DML語句時才獲得一個保留鎖。至於排它鎖，只有在資料從記憶體寫入磁碟時開始，直到事務提交或復原之前才能持有排它鎖。
    如果多個SQL命令在同一個時刻同一個資料庫連接中被執行，autocommit將會被順延強制，直到最後一個命令完成。比如，如果一個SELECT語句正在被執行，在這個命令執行期間，需要返回所有檢索出來的行記錄，如果此時處理結果集的線程因為商務邏輯的需要被暫時掛起並處於等待狀態，而其它的線程此時或許正在該串連上對該資料庫執行INSERT、UPDATE或DELETE命令，那麼所有這些命令作出的資料修改都必須等到SELECT檢索結束後才能被提交。

    這是該系列中最後一篇關於SQLite理論與應用方面的部落格了，後面將發布兩篇關於如何利用SQLite編程的部落格，其中還將包含四個典型的應用程式碼範例，望大家繼續保持關注。