背景
現有一個交易系統，每次交易都會更新餘額。出賬扣減餘額，入賬增加餘額。為了保證資金安全，餘額發生扣減時，需要比較現有餘額與扣減金額大小，若扣減金額大於現有餘額，扣減餘額不足，扣減失敗。
餘額表（省去其他字段）結構如下：
CREATE TABLE `account`
(
`id` bigint(20) NOT NULL,
`balance` bigint(20) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8mb4
COLLATE = utf8mb4_bin;
更新餘額方法語序如下：
由於存在併發更新餘額的情況，在 t3 時刻，使用寫鎖鎖住該行記錄。這樣就能保證事務執行期間不會有其他事務提交變更。
現在我們假設有兩個事務正在發執行該語序，執行順序如圖所示。
假設 id=1 記錄 balance=1000，事務隔離等級為 RR。小夥伴們可以根據這個執行時序可以先思考下 t3,t5,t6,t7 結果。
注： 以上時序，順序執行。但是事務 1 執行到 t3 時刻，t4 時刻，事務 2 執行時將會被阻塞，後續無法執行。
t4 時刻之後，只能先將 事務 1 語序執行，事務提交完成後，才能執行 事務 2 剩餘語句。
下面放出問題的答案。
t3 (1,1000)
t5 (1,1000)
t4 (1,900)
t6 (1,1000)
有沒有跟你結果的不太一樣？
事務 1 查詢結果基本沒什麼問題，事務 2 同一個事務內查詢結果卻不同。
現在我們先帶著疑問，看完下面 MySQL 的相關原理，你就會明白一切。
相關原理
MVCC
假設在 RR 下，下圖 id=1 balance=1000 。
上圖時序順序可以執行
事務 1 將 id=1 記錄 balance 更新為 900。然後 t5 查詢結果肯定還是 id=1 balance=1000，不然就讀取到髒數據，不符合當前事務隔離級別。
從上面例子可以看到 id=1 的記錄存在兩個版本，一個為 balance=1000 ，一個為 balance=900。
MySQL 使用 MVCC 實現該功能。
MVCC：Multiversion concurrency control，多版本併發控制。摘錄一段淘寶數據庫月報的解釋：
多版本控制: 指的是一種提高併發的技術。最早的數據庫系統，只有讀讀之間可以併發，讀寫，寫讀，寫寫都要阻塞。引入多版本之後，只有寫寫之間相互阻塞，其他三種操作都可以並行，這樣大幅度提高了InnoDB的併發度。在內部實現中，與Postgres在數據行上實現多版本不同，InnoDB是在undolog中實現的，通過undolog可以找回數據的歷史版本。找回的數據歷史版本可以提供給用戶讀(按照隔離級別的定義，有些讀請求只能看到比較老的數據版本)，也可以在回滾的時候覆蓋數據頁上的數據。在InnoDB內部中，會記錄一個全局的活躍讀寫事務數組，其主要用來判斷事務的可見性。
可以看到 MVCC 主要用來提高併發，還可以用來讀取老版本數據。下面介紹 MVCC 實現的原理。
首先我們先看下 MySQL 記錄結構。
可看到 MySQL 行記錄除了真實數據以外，還會存在三個隱藏字段，用來記錄額外信息。
DBTRXID:事務id。
DBRLLPTR: 回滾指針，指向 undolog。
ROW_I：行 id,與此次無關。
具體行記錄結構，可以參考掘金的小冊『 MySQL 是怎樣運行的：從根兒上理解 MySQL』，說實話小冊寫的真的很好，收益頗豐。哈哈。
MySQL 通過 DBROLLPTR 找到 undolog，而 undolog 記錄數據的變更。這樣 MySQL 就能推導出變更之前記錄內容。
查找過程如下：
若需要道 V1 版本記錄，首先根據當前版本 V3 的
DBROLLPTR 找到 undolog，然後根據 undolog 內容，計算出上一個版本 V2。以此類推，最終找到 V1 這個版本記錄。V1，V2 並不是物理記錄，沒有真實存在，僅僅具有邏輯意義。
一行數據記錄可能同時存在多個版本，但並不是所有記錄都能對當前事務可見。不然上面 t5 就可能查詢到最新的數據。所以查找數據版本時候 MySQL 必須判斷數據版本是否對當前事務可見。
一致性視圖
MySQL 會在事務開始後建立一個一致性視圖（並不是立刻建立），在這個視圖中，會保存所有活躍的事務(還未提交的事務)。
假設當前事務創建活躍事務數組為如下圖。
判斷記錄本對於當前事務是否可見時，基於以下規則判斷：
- 若記錄版本事務 id 小於當前活躍事務 id 數組最小值,如 id 為 40，小於 45,代表當前記錄版本的事務已提交，當前記錄對於當前事務可見。
- 若記錄版本事務 id 大於當前活躍事務數組的最大值，如記錄版本事務 id 為 100， 大於數組最大事務 id 90。說明了這個記錄版本是當前事務創建之後生成，所以記錄對於當前事務不可見。
- 若記錄版本事務 id 是當前活躍數組事務之一，如記錄數據版本事務 id 為 56。代表記錄版本所屬事務還未提交，所以記錄對於當前事務不可見。
- 若記錄版本事務 id 不是當前活躍數組事務之一，但是事務 id 位於數組最小值與最大值之一。如記錄事務 ID 57。代表當前記錄事務已提交，所以記錄對於當前事務可見。
- 若記錄版本事務 id 為當前事務 id，代表該行數據是當前事務變更的，當然得可見。
4 這個規則可能比較繞，結合上面圖片比較好理解。
以上判斷規則可能比較抽象，我們將其總結下面幾句話。
- 未提交事務生成的記錄版本，不可見。
- 視圖生成前，提交事務生成記錄版本可見。
- 視圖生成後，提交事務生成記錄版本不可見。
- 自身事務更新永遠可見。
一致性視圖只會在 RR 與 RC 下才會生成，對於 RR 來說，一致性視圖會在第一個查詢語句的時候生成。而對於 RC 來說，每個查詢語句都會重新生成視圖。
當前讀與快照讀
MySQL 使用 MVCC 機制，可以 讀取之前版本數據。這些舊版本記錄不會且也無法再去修改，就像快照一樣。所以我們將這種查詢稱為快照讀。
當然並不是所有查詢都是快照讀，select .... for update/ in share mode 這類加鎖查詢只會查詢當前記錄最新版本數據。我們將這種查詢稱為當前讀。
問題分析
講完原理之後，我們回過頭分析一下上面查詢結果的原因。
這裡我們將上面答案再貼過來。
事務隔離級別 RR，t1，t2 時刻兩個事務由於查詢語句，分別建立了一致性視圖。
t3 時刻，由於事務 1 使用 select..forupdate 為 id=1 這一行上了一把寫鎖，然後獲取到最新結果。而 t4 時刻，由於該行已被上鎖，事務 2 必須等待事務 1 釋放鎖才能繼續。
t5 時刻根據一致性視圖，不能讀取到其他事務提交的版本，所以數據沒變。t7 時刻餘額扣減 100，t8 時刻提交事務。
此時最新版本記錄為 id=1 balance=900。
由於事務 1 事務提交，行鎖被釋放，t4 獲取到寫鎖。由於 t4 是當前讀，所以查詢的結果為最新版本數據（1,900）。
重點來了。t6 查詢時，id=1 這條記錄最新版本數據為 （1,900）。但是最新版本事務 id，屬於事務 2創建之後未提交的事務，位於活躍事務數組中。所以最新記錄版本對於事務2 是不可見的。沒辦法只能根據 undolog 去讀取上一版本記錄 (1,1000) 。這個版本記錄剛好對於事務 2 可見。
若當前事務隔離級別修改成 RC,那麼結果就與 RR 不同。各位讀者自行分析一下。
下面貼一下 RC 答案。
Refereces
[1] MySQL 是怎樣運行的：從根兒上理解 MySQL: https://juejin.im/book/5bffcbc9f265da614b11b731
[2] mysql mvcc: https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html
[3] 淘寶月報: http://mysql.taobao.org/monthly/2017/12/01/
[4] innodb 相關實現: http://mysql.taobao.org/monthly/2018/11/04/
[5] consistent-read: https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html
閱讀更多 程序通事 的文章
