如何實現資料庫讀一致性

1 導讀

資料的一致性是資料準確的重要指標，那如何實現資料的一致性呢？本文從事務特性和事務級別的角度和大家一起學習如何實現資料的讀寫一致性。

2 一致性

1.資料的一致性：通常指關聯資料之間的邏輯關係是否正確和完整。

舉個例子：某系統實現讀寫分離，讀資料庫是寫資料庫的備份庫，小李在系統中之前錄入的學歷資訊是高中，經過小李努力學習，成功獲得了本科學位。小李及時把資訊變成成了本科，可是由於今天系統備份時間較長，小李變更資訊時，資料已經開始備份。公司的HR通過系統查詢小李資訊時，發現還是本科，小李的申請被駁回。這就是資料不一致問題。

2.資料庫的一致性：是指資料庫從一個一致性狀態變到另一個一致性狀態。這是事務的一致性的定義。

舉個例子：倉庫中商品A有100件，門店中商品A有10件。上午10點，倉庫傳送商品A50件到門店，最後倉庫中有商品A50件，門店有商品A60件，這樣商品的總是是不變的。不能門店收到貨後，倉庫的商品A還是100件，這樣就出現資料庫不一致問題。倉庫和門店商品A的總數是110才是正確的，這就是資料庫的一致性。

3 資料庫事務

資料庫事務( transaction)是存取並可能操作各種資料項的一個資料庫操作序列，這些操作要麼全部執行,要麼全部不執行，是一個不可分割的工作單位。事務由事務開始與事務結束之間執行的全部資料庫操作組成。

事務的性質：

原子性(Atomicity)：事務中的全部操作在資料庫中是不可分割的，要麼全部完成，要麼全部不執行。
一致性(Consistency)：幾個並行執行的事務，其執行結果必須與按某一順序序列執行的結果相一致。
隔離性(Isolation)：事務的執行不受其他事務的干擾，事務執行的中間結果對其他事務必須是透明的。
永續性(Durability):對於任意已提交事務，系統必須保證該事務對資料庫的改變不被丟失，即使資料庫出現故障

4 並行問題

資料庫在並行環境下會出現髒讀、重複讀和幻讀問題。

1.髒讀

事務A讀取了事務B未提交的資料，如果事務B回滾了，事務A讀取的資料就是髒的。
舉例：訂單A需要商品A20件，訂單B需要商品A10件。倉庫中有商品A庫存是20件。訂單B先查詢,發現庫存夠，進行扣減。在扣減的過程中，訂單A進行查詢，發現庫存只有10個不夠訂單數量，丟擲異常。這時候訂單B提交失敗了。庫存數量又變成20了。這時候，倉庫人員去查庫存，發現數量是20，可是訂單A卻說庫存不足，這就讓人很奇怪。

2.不可重複讀

復讀指的是在一個事務內，最開始讀到的資料和事務結束前的任意時刻讀到的同一批資料出現不一致的情況。
舉例：庫房管理員查詢商品A的數量，讀取結果是20件。這是訂單A出庫，扣減了商品10件。這時管理員再去查商品A時，發現商品A的數量時10件和第一此查詢的結果不同了。

3.幻讀

事務A在執行讀取操作，需要兩次統計資料的總量，前一次查詢資料總量後，此時事務B執行了新增資料的操作並提交後，這個時候事務A讀取的資料總量和之前統計的不一樣，就像產生了幻覺一樣，平白無故的多了幾條資料，成為幻讀。
舉例：操作員查詢可生產單量10個，呼叫介面下發10個訂單，事務A增加10個訂單。操作員獲取10個訂單落庫，查詢發現變成30個訂單。

5 事務隔離級別

Read Uncommitted（未提交讀）
一個事務可以讀取到其他事務未提交的資料，會出現髒讀，所以叫做 RU，它沒有解決任何的問題。

Read Committed（已提交讀）
一個事務只能讀取到其他事務已提交的資料，不能讀取到其他事務未提交的資料，它解決了髒讀的問題，但是會出現不可重複讀的問題。

Repeatable Read（可重複讀）
它解決了不可重複讀的問題，也就是在同一個事務裡面多次讀取同樣的資料結果是一樣的，但是在這個級別下，沒有定義解決幻讀的問題。

Serializable（序列化）
在這個隔離級別裡面，所有的事務都是序列執行的，也就是對資料的操作需要排隊，已經不存在事務的並行操作了，所以它解決了所有的問題。

6 解決資料讀一致性

有兩個方案可以解決讀一致性問題：基於鎖的並行操作（LBCC）和基於多版本的並行操作（MVCC）

6.1 LBCC

既然要保證前後兩次讀取資料一致，那麼讀取資料的時候，鎖定我要操作的資料，不允許其他的事務修改就行了。這種方案叫做基於鎖的並行控制 Lock Based Concurrency Control（LBCC）。

LBCC是通過悲觀鎖來實現並行控制的。

如果事務A對資料進行加鎖，在鎖釋放前，其他事務就不能對資料進行讀寫操作。這樣並行呼叫，改成了順序呼叫。對目前的大多數系統來說，效能完全不能滿足要求。

6.2 MVCC

要讓一個事務前後兩次讀取的資料保持一致，那麼我們可以在修改資料的時候給它建立一個備份或者叫快照，後面再來讀取這個快照就行了。不管事務執行多長時間，事務內部看到的資料是不受其它事務影響的，根據事務開始的時間不同，每個事務對同一張表，同一時刻看到的資料可能是不一樣的。這種方案我們叫做多版本的並行控制 Multi Version Concurrency Control(MVCC)。

MVCC是基於樂觀鎖的。

在 InnoDB 中，MVCC 是通過Undo log中的版本鏈和Read-View一致性檢視來實現的。

6.2.1 Undo log

undo log是innodb引擎的一種紀錄檔,在事務的修改記錄之前,會把該記錄的原值先儲存起來再做修改,以便修改過程中出錯能夠恢復原值或者其他的事務讀取。undo log是一種用於復原回退的紀錄檔，在事務沒提交之前，MySQL會先記錄更新前的資料到 undo log紀錄檔檔案裡面，當事務回滾時或者資料庫崩潰時，可以利用 undo log來進行回退。

對資料變更的操作不同，undo log記錄的內容也不同:

新增一條記錄的時候，在建立對應undo紀錄檔時，只需要把這條記錄的主鍵值記錄下來，如果要回滾插入操作，只需要根據對應的主鍵值對記錄進行刪除操作。
刪除一條記錄的時候，在建立對應undo紀錄檔時，需要把這條資料的所有內容都記錄下來，如果要回滾刪除語句，需要把記錄的資料內容生產相應的insert語句，並插入到資料庫中。
更新一條記錄的時候，如果沒有更新主鍵，在建立對應undo紀錄檔時，如果要回滾更新語句，需要把變更前的內容記錄下來，如果要回滾更新語句，需要根據主鍵，把記錄的資料更新回去。
更新一條記錄的時候，如果有更新主鍵，在建立對應undo紀錄檔時，需要把資料的所有內容都記錄下來，如果要回滾更新語句，先把變更後的資料刪掉，再執行插入語句，把備份的資料插入到資料庫中。

undo log版本鏈

每條資料有兩個隱藏欄位，trx_id 和 roll_pointer，trx_id表示最近一次事務的id，roll_pointer表示指向你更新這個事務之前生成的undo log。
事務ID：MySQL維護一個全域性變數，當需要為某個事務分配事務ID時，將該變數的值作為事務id分配給事務，然後將變數自增1。

舉例：

事務A id是1 插入一條資料X，這條資料的trx_id =1 ,roll_pointer 是空（第一次插入）。
事務B id 是2 對這條資料進行了更新，這條資料的 trx_id =2 ,roll_pointer 指向事務A的undo log.
事務C id 是3 又對資料進行了更新操作，這條資料的trx_id =3,roll_pointer 指向事務B的undo log.

所以當多個事務序列執行的時候，每個事務修改了一行資料，都會更新隱藏欄位trx_id 和 roll_pointer，同時多個事務的undo log會通過roll_pointer指標串聯起來，形成undo log版本鏈。

6.2.2 Read-View一致性檢視

InnoDB為每個事務維護了一個陣列，這個陣列用來儲存這個事務啟動的瞬間，當前活躍的事務ID。這個陣列裡有兩個水位值：低水位(事務ID 最小值)和高水位(事務ID 最大值 + 1);這兩個水位值就構成了當前事務的一致性檢視（Read-View）

ReadView中主要包含4個比較重要的內容：

m_ids：表示在生成ReadView時當前系統中活躍的讀寫事務的事務id列表。
min_trx_id：表示在生成ReadView時當前系統中活躍的讀寫事務中最小的事務id，也就是m_ids中的最小值。
max_trx_id：表示生成ReadView時系統中應該分配給下一個事務的id值。
creator_trx_id：表示生成該ReadView的事務的事務id。

有了這些資訊，這樣在存取某條記錄時，只需要按照下邊的步驟判斷記錄的某個版本是否可見：

如果被存取版本的trx_id屬性值與ReadView中的creator_trx_id值相同，意味著當前事務在存取它自己修改過的記錄，所以該版本可以被當前事務存取。
如果被存取版本的trx_id屬性值小於ReadView中的min_trx_id值，表明生成該版本的事務在當前事務生成ReadView前已經提交，所以該版本可以被當前事務存取。
如果被存取版本的trx_id屬性值大於ReadView中的max_trx_id值，表明生成該版本的事務在當前事務生成ReadView後才開啟，所以該版本不可以被當前事務存取。
如果被存取版本的trx_id屬性值在ReadView的min_trx_id和max_trx_id之間，那就需要判斷一下trx_id屬性值是不是在m_ids列表中，如果在，說明建立ReadView時生成該版本的事務還是活躍的，該版本不可以被存取；如不在，說明建立ReadView時生成該版本的事務已經被提交，該版本可以被存取。
如果某個版本的資料對當前事務不可見的話，那就順著版本鏈找到下一個版本的資料，繼續按照上邊的步驟判斷可見性，依此類推，直到版本鏈中的最後一個版本。如果最後一個版本也不可見的話，那麼就意味著該條記錄對該事務完全不可見，查詢結果就不包含該記錄。

6.2.3 資料的查詢方式

1.快照讀

快照讀又叫一致性讀，讀取的是歷史版本的資料。不加鎖的簡單的SELECT都屬於快照讀，即不加鎖的非阻塞讀，只能查詢建立時間小於等於當前事務ID的資料或者刪除時間大於當前事務ID的行（或未刪除）。

2.當前讀

當前讀查詢的是記錄的最新資料。加鎖的SELECT、對資料進行增刪改都會進行當前讀。

6.2.4 資料舉例

如圖所示：

事務A id =1 初始化了資料
事務B id=2 進行了查詢操作（MVCC唯讀取建立時間小於當前事務ID的資料或者刪除時間大於當前事務ID的行）
事務B的結果是 (商品A：10,商品B：5）

事務C id =3 插入了商品C
事務B id=2 進行了查詢操作（MVCC唯讀取建立時間小於當前事務ID的資料或者刪除時間大於當前事務ID的行）
事務B的結果是 (商品A：10,商品B：5）

事務D id =4 刪除商品B
事務B id=2 進行了查詢操作（MVCC唯讀取建立時間小於當前事務ID的資料或者刪除時間大於當前事務ID的行）
事務B的結果是 (商品A：10,商品B：5）

事務E id =4 修改商品A的數量
事務B id=2 進行了查詢操作（MVCC唯讀取建立時間小於當前事務ID的資料或者刪除時間大於當前事務ID的行）
事務B的結果是 (商品A：10,商品B：5）

所以當事務E提交後，當前讀獲取的資料和事務B讀取的快照資料明顯不同。

6.2.5 可解決問題

MVCC可以很好的解決讀一致問題，只能看到這個時間點之前事務提交更新的結果，而不能看到這個時間點之後事務提交的更新結果。而且降低了死鎖的概率和解決讀寫之間堵塞問題。

7 小結

LBCC和MVCC都可以解決讀一致問題，具體使用哪種方式，要結合業務場景選擇最合適的方式，MVCC和鎖也可以結合使用，沒有最好只有更好。