來(lái)源 |程序通事

責(zé)編 | Carol

封圖 | CSDN 付費(fèi)下載自視覺(jué)中國(guó)

P0 事故：余額多扣！

這是一個(gè)真實(shí)的生產(chǎn)事件，事件起因如下：

現(xiàn)有一個(gè)交易系統(tǒng)，每次產(chǎn)生交易都會(huì)更新相應(yīng)賬戶(hù)的余額，出賬扣減余額，入賬增加余額。

為了保證資金安全，余額發(fā)生扣減時(shí)，需要比較現(xiàn)有余額與扣減金額大小，若扣減金額大于現(xiàn)有余額，扣減余額不足，扣減失敗。

賬戶(hù)表（省去其他字段）結(jié)構(gòu)如下：

CREATE?TABLE?`account` (`id`??????bigint(20)?NOT?NULL,`balance`?bigint(20)?DEFAULT?NULL,PRIMARY?KEY?(`id`))?ENGINE?=?InnoDBDEFAULT?CHARSET?=?utf8mb4COLLATE?=?utf8mb4_bin;

扣減余額時(shí)，sql 語(yǔ)序如下所示：

更新余額 sql 語(yǔ)序

ps:看到上面的語(yǔ)序，有沒(méi)有個(gè)小問(wèn)號(hào)？為什么相同查詢(xún)了這么多次？

其實(shí)這些 SQL 語(yǔ)序并不在同個(gè)方法內(nèi)，并且有些方法被抽出復(fù)用，所以導(dǎo)致一些相同查詢(xún)結(jié)果沒(méi)辦法往下傳遞，所以只得再次從數(shù)據(jù)庫(kù)中查詢(xún)。

為了防止并發(fā)更新余額，在 t3 時(shí)刻，使用寫(xiě)鎖鎖住該行記錄。若加鎖成功，其他線程的若也執(zhí)行到 t3,將會(huì)被阻塞，直到前一個(gè)線程事務(wù)提交。

t5 時(shí)刻，進(jìn)入到下一個(gè)方法，再次獲取賬戶(hù)余額，然后在 Java 方法內(nèi)比較余額與扣減金額，若余額充足，在 t7 時(shí)刻執(zhí)行更新操作。

上面的 SQL 語(yǔ)序看起來(lái)沒(méi)有什么問(wèn)題吧，實(shí)際也是這樣的，賬戶(hù)系統(tǒng)已經(jīng)在生產(chǎn)運(yùn)行很久，沒(méi)出現(xiàn)什么問(wèn)題。但是這里需要說(shuō)一個(gè)前提，系統(tǒng)數(shù)據(jù)庫(kù)是 Oracle 。

但是從上面表結(jié)構(gòu)，可以得知此次數(shù)據(jù)庫(kù)被切換成 MySQL，系統(tǒng)其他任何代碼以及配置都不修改（sql 存在小改動(dòng)）。

就是這種情況下，并發(fā)執(zhí)行發(fā)生余額多扣，即實(shí)際余額明明小于扣減金額，但是卻做了余額更新操作，最后導(dǎo)致余額變成了負(fù)數(shù)。

下面我們來(lái)重現(xiàn)并發(fā)這種情況，假設(shè)有兩個(gè)事務(wù)正在發(fā)執(zhí)行該語(yǔ)序，執(zhí)行順序如圖所示。

注意點(diǎn)：數(shù)據(jù)庫(kù)使用的是 MySQL，默認(rèn)事務(wù)隔離等級(jí)，即 RR。數(shù)據(jù)庫(kù)記錄為 id=1 balance=1000，假設(shè)只有當(dāng)時(shí)只有這兩個(gè)事務(wù)在執(zhí)行。

各位讀者可以先思考一下，t2,t3,t4,t5,t6,t11 時(shí)刻余額多少。

下面貼一下事務(wù)隔離等級(jí)RR?下的答案。

事務(wù) 1 的查詢(xún)結(jié)果為：

• t2 (1,1000)

• t4 (1,1000)

• t6 (1,1000)

事務(wù) 2 的查詢(xún)結(jié)果為：

• t3 (1,1000)

• t5 (1,900)

• t11 (1,1000)

有沒(méi)有跟你想的結(jié)果的一樣？

接著將事務(wù)隔離等級(jí)修改成?RC，同樣再來(lái)思考一下 t2,t3,t4,t5,t6,t11 時(shí)刻余額。

再次貼下事務(wù)隔離等級(jí)RC?下的答案。

事務(wù) 1 的查詢(xún)結(jié)果為：

• t2 (1,1000)

• t4 (1,1000)

• t6 (1,1000)

事務(wù) 2 的查詢(xún)結(jié)果為：

• t3 (1,1000)

• t5 (1,900)

• t11 (1,900)

事務(wù) 1 的查詢(xún)結(jié)果，大家應(yīng)該會(huì)沒(méi)有什么問(wèn)題，主要疑問(wèn)點(diǎn)應(yīng)該在于事務(wù) 2，為什么換了事務(wù)隔離等級(jí)結(jié)果卻不太一樣？

下面我們先帶著疑問(wèn)，了解一下 MySQL 的相關(guān)原理 ，看完你就會(huì)明白這一切。

• MVCC

• 一致性視圖

• 快照讀與當(dāng)前讀

MVCC

我們先來(lái)看下一個(gè)簡(jiǎn)單的例子：

事務(wù)隔離等級(jí)為 RR ，?id=1 balance=1000

更新時(shí)序

事務(wù) 1 將 id=1 記錄 balance 更新為 900，接著事務(wù) 2 在 t5 時(shí)刻查詢(xún)?cè)撔杏涗浗Y(jié)果，很顯然該行記錄應(yīng)該為?id=1 balance=1000。

如果 t5 查詢(xún)最新結(jié)果 id=1 balance=900，這就讀取到事務(wù) 1 未提交的數(shù)據(jù)，顯然不符合當(dāng)前事務(wù)隔離級(jí)別。

從上面例子可以看到 id=1 的記錄存在兩個(gè)版本，事務(wù) 1 版本記錄為?balance=1000?，事務(wù) 2 版本記錄為?balance=900。

上述功能，MySQL 使用 MVCC 機(jī)制實(shí)現(xiàn)功能。

MVCC：Multiversion concurrency control，多版本并發(fā)控制。摘錄一段淘寶數(shù)據(jù)庫(kù)月報(bào)的解釋：

多版本控制:?

指的是一種提高并發(fā)的技術(shù)。最早的數(shù)據(jù)庫(kù)系統(tǒng)，只有讀讀之間可以并發(fā)，讀寫(xiě)，寫(xiě)讀，寫(xiě)寫(xiě)都要阻塞。引入多版本之后，只有寫(xiě)寫(xiě)之間相互阻塞，其他三種操作都可以并行，這樣大幅度提高了 InnoDB 的并發(fā)度。在內(nèi)部實(shí)現(xiàn)中，與 Postgres 在數(shù)據(jù)行上實(shí)現(xiàn)多版本不同，InnoDB 是在 undolog 中實(shí)現(xiàn)的，通過(guò) undolog 可以找回?cái)?shù)據(jù)的歷史版本。找回的數(shù)據(jù)歷史版本可以提供給用戶(hù)讀(按照隔離級(jí)別的定義，有些讀請(qǐng)求只能看到比較老的數(shù)據(jù)版本)，也可以在回滾的時(shí)候覆蓋數(shù)據(jù)頁(yè)上的數(shù)據(jù)。在 InnoDB 內(nèi)部中，會(huì)記錄一個(gè)全局的活躍讀寫(xiě)事務(wù)數(shù)組，其主要用來(lái)判斷事務(wù)的可見(jiàn)性。

可以看到 MVCC 主要用來(lái)提高并發(fā)，還可以用來(lái)讀取老版本數(shù)據(jù)。

在學(xué)習(xí) MVCC 原理之前，首先我們需要了解 MySQL 記錄結(jié)構(gòu)。

行記錄

如上圖所示，account?表一行記錄，除了真實(shí)數(shù)據(jù)之外，還會(huì)存在三個(gè)隱藏字段，用來(lái)記錄額外信息。

• DB_TRX_ID:事務(wù) id。

• DB_ROLL_PTR: 回滾指針，指向 undolog。

• ROW_ID：行 id,與此次無(wú)關(guān)。

MySQL InnoDB 里面每個(gè)事務(wù)都會(huì)有一個(gè)唯一事務(wù) ID，它在事務(wù)開(kāi)始的時(shí)候會(huì)跟 InnoDB 的事務(wù)系統(tǒng)申請(qǐng)的，并且嚴(yán)格按照順序遞增的。

每次事務(wù)更新數(shù)據(jù)時(shí)，將會(huì)生成一個(gè)新的數(shù)據(jù)版本，然后會(huì)把當(dāng)前的事務(wù) id 賦值給當(dāng)前記錄的?DB_TRX_ID。并且數(shù)據(jù)更新記錄（1,1000---->1,900）將會(huì)記錄在 undo log（回滾日志）中，然后使用當(dāng)前記錄的?DB_ROLL_PTR?指向 und olog。

這樣 MySQL 就可以通過(guò) DB_ROLL_PTR 找到 undolog 推導(dǎo)出之前版本記錄內(nèi)容。

查找過(guò)程如下：

查找過(guò)程

若需要知道 V1 版本記錄，首先根據(jù)當(dāng)前版本 V3 的?DB_ROLL_PTR?找到?undolog，然后根據(jù)?undolog?內(nèi)容，計(jì)算出上一個(gè)版本 V2。以此類(lèi)推，最終找到 V1 這個(gè)版本記錄。

V1，V2 并不是物理記錄，沒(méi)有真實(shí)存在，僅僅具有邏輯意義。

一行數(shù)據(jù)記錄可能同時(shí)存在多個(gè)版本，但并不是所有記錄都能對(duì)當(dāng)前事務(wù)可見(jiàn)。不然上面 t5 就可能查詢(xún)到最新的數(shù)據(jù)。所以查找數(shù)據(jù)版本時(shí)候 MySQL 必須判斷數(shù)據(jù)版本是否對(duì)當(dāng)前事務(wù)可見(jiàn)。

一致性視圖

MySQL 會(huì)在事務(wù)開(kāi)始后建立一個(gè)一致性視圖（并不是立刻建立），在這個(gè)視圖中，會(huì)保存所有活躍的事務(wù)(還未提交的事務(wù))。

假設(shè)當(dāng)前事務(wù)保存活躍事務(wù)數(shù)組為如下圖。

視圖數(shù)組

判斷版本對(duì)于當(dāng)前事務(wù)是否可見(jiàn)時(shí)，基于以下規(guī)則判斷：

若版本事務(wù) id 小于當(dāng)前活躍事務(wù) id 數(shù)組最小值,比如版本 id 為 40，小于活躍數(shù)組最小值 45。這就代表當(dāng)前版本的事務(wù)已提交，當(dāng)前版本對(duì)于當(dāng)前事務(wù)可見(jiàn)。

若版本事務(wù) id 大于當(dāng)前活躍事務(wù)數(shù)組的最大值，如版本事務(wù) id 為 100， 大于數(shù)組最大事務(wù) id 90。說(shuō)明了這個(gè)版本是當(dāng)前事務(wù)創(chuàng)建之后生成，所以這個(gè)版本對(duì)于當(dāng)前事務(wù)不可見(jiàn)。

若版本事務(wù) id 是當(dāng)前活躍數(shù)組事務(wù)之一，比如版本事務(wù) id 為 56。代表記錄版本所屬事務(wù)還未提交，所以該版本對(duì)于當(dāng)前事務(wù)不可見(jiàn)。

若版本事務(wù) id 不是當(dāng)前活躍數(shù)組事務(wù)之一，但是事務(wù) id 位于活躍數(shù)組最小值與最大值之一，比如如事務(wù) ID 57。代表當(dāng)前記錄事務(wù)已提交，所以該版本對(duì)于當(dāng)前事務(wù)可見(jiàn)。

若版本事務(wù) id 為當(dāng)前事務(wù) id，代表該行數(shù)據(jù)是當(dāng)前事務(wù)變更的，當(dāng)然得可見(jiàn)。

4 這個(gè)規(guī)則可能比較繞，結(jié)合上面圖片比較好理解。

以上判斷規(guī)則可能比較抽象，看不懂，沒(méi)事，我們?cè)儆么蟀自?huà)解釋一下：

未提交事務(wù)生成的記錄版本，不可見(jiàn)。

視圖生成前，已提交事務(wù)生成記錄版本可見(jiàn)。

視圖生成后，新事務(wù)生成記錄版本不可見(jiàn)。

自身事務(wù)更新永遠(yuǎn)可見(jiàn)。

一致性視圖只會(huì)在 RR 與 RC 下才會(huì)生成，對(duì)于 RR 來(lái)說(shuō)，一致性視圖會(huì)在第一個(gè)查詢(xún)語(yǔ)句的時(shí)候生成。而對(duì)于 RC 來(lái)說(shuō)，每個(gè)查詢(xún)語(yǔ)句都會(huì)重新生成視圖。

當(dāng)前讀與快照讀

MySQL 使用 MVCC 機(jī)制，可以讀取之前版本數(shù)據(jù)。這些舊版本記錄不會(huì)且也無(wú)法再去修改，就像快照一樣。所以我們將這種查詢(xún)稱(chēng)為快照讀。

當(dāng)然并不是所有查詢(xún)都是快照讀，select .... for update/ in share mode 這類(lèi)加鎖查詢(xún)只會(huì)查詢(xún)當(dāng)前記錄最新版本數(shù)據(jù)。我們將這種查詢(xún)稱(chēng)為當(dāng)前讀。

問(wèn)題分析

講完原理之后，我們回過(guò)頭分析一下上面查詢(xún)結(jié)果的原因。

這里我們將上面答案再貼過(guò)來(lái)。

事務(wù)隔離級(jí)別為 RR，t2，t3 時(shí)刻兩個(gè)事務(wù)由于查詢(xún)語(yǔ)句，分別建立了一致性視圖。

t4 時(shí)刻，由于事務(wù) 1 使用?select.. for update?為 id=1 這一行上了一把鎖，然后獲取到最新結(jié)果。而 t5 時(shí)刻，由于該行已被上鎖，事務(wù) 2 必須等待事務(wù) 1 釋放鎖才能繼續(xù)執(zhí)行。

t6 時(shí)刻根據(jù)一致性視圖，不能讀取到其他事務(wù)提交的版本，所以數(shù)據(jù)沒(méi)變。t8 時(shí)刻余額扣減 100，t9 時(shí)刻提交事務(wù)。

此時(shí)最新版本記錄為?id=1 balance=900。

由于事務(wù) 1 事務(wù)已提交，行鎖被釋放，t5 成功獲取到鎖。由于 t5 是當(dāng)前讀，所以查詢(xún)的結(jié)果為最新版本數(shù)據(jù)（1,900）。

重點(diǎn)來(lái)了，當(dāng)前這條記錄的最新版本數(shù)據(jù)為?（1,900），但是最新版本事務(wù) id，卻是事務(wù) 2 創(chuàng)建之后未提交的事務(wù)，位于活躍事務(wù)數(shù)組中。所以最新記錄版本對(duì)于事務(wù) 2 是不可見(jiàn)的。

沒(méi)辦法只能根據(jù) undolog 去讀取上一版本記錄?(1,1000)?，這個(gè)版本記錄剛好對(duì)于事務(wù) 2 可見(jiàn)，所以 t11 的記錄為?(1,1000)。

而當(dāng)我們將事務(wù)隔離等級(jí)修改成 RC，每次都會(huì)重新生成一致性視圖。所以 t11 時(shí)刻重新生成了一致性視圖，這時(shí)候事務(wù) 1 已提交，當(dāng)前最新版本的記錄對(duì)于事務(wù) 2 可見(jiàn)，所以 t11 的結(jié)果將會(huì)變?yōu)?（1,900）。

總結(jié)

MySQL 默認(rèn)事務(wù)隔離等級(jí)為 RR，每一行數(shù)據(jù)（InnoDB）的都可以有多個(gè)版本，而每個(gè)版本都有獨(dú)一的事務(wù) id。

MySQL 通過(guò)一致性視圖確保數(shù)據(jù)版本的可見(jiàn)性，相關(guān)規(guī)則總結(jié)如下：

• 對(duì)于 RR 事務(wù)隔離等級(jí)，普通查詢(xún)僅能查到事務(wù)啟動(dòng)前就已經(jīng)提交完成的版本數(shù)據(jù)。

• 對(duì)于 RC 事務(wù)隔離等級(jí)，普通查詢(xún)可以查到查詢(xún)語(yǔ)句啟動(dòng)前就已經(jīng)提交完成的版本數(shù)據(jù)。

• 當(dāng)前讀總是讀取最新版本的數(shù)據(jù)。

參考資料

[1]?https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html
[2]?http://mysql.taobao.org/monthly/2017/12/01/
[3]?http://mysql.taobao.org/monthly/2018/11/04/
[4]?https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html

6月2日20:00，CSDN 創(chuàng)始人&董事長(zhǎng)、極客幫創(chuàng)投創(chuàng)始合伙人蔣濤攜手全球頂級(jí)開(kāi)源基金會(huì)主席、董事，聚焦中國(guó)開(kāi)源現(xiàn)狀，直面開(kāi)發(fā)者在開(kāi)源技術(shù)、商業(yè)上的難題，你絕不可錯(cuò)過(guò)的開(kāi)源巔峰對(duì)談！立即免費(fèi)圍觀：

推薦閱讀

• 因?yàn)橐粋€(gè)跨域請(qǐng)求，我差點(diǎn)丟了飯碗

• 沒(méi)錯(cuò)，你離分布式搜索只差一個(gè)Elasticsearch入門(mén)！
  

• Python開(kāi)發(fā)之：Django基于Docker實(shí)現(xiàn)Mysql數(shù)據(jù)庫(kù)讀寫(xiě)分離、集群、主從同步詳解 | 原力計(jì)劃
  

• 全球Python調(diào)查報(bào)告：Python 2正在消亡，PyCharm比VS Code更受歡迎
  

• 無(wú)代碼來(lái)了，還要程序員嗎？

• 再見(jiàn)，Eclipse | 原力計(jì)劃

• 區(qū)塊鏈共識(shí)算法總結(jié) | 原力計(jì)劃

真香，朕在看了！

總結(jié)

以上是生活随笔為你收集整理的MySQL 可重复读，差点就让我背上了一个 P0 事故！的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。