介紹弱隔離級別

為什麼要有弱隔離級別

如果兩個事務操作的是不同的數據， 即不存在數據依賴關係， 則它們可以安全地並行執行。但是當出現某個事務修改數據而另一個事務同時要讀取該數據， 或者兩個事務同時修改相同數據時， 就會出現併發問題。

在應用程式的開發中，我們通常會利用鎖進行併發控制，確保臨界區的資源不會出現多個線程同時進行讀寫的情況，這其實就對應了事務的最高隔離級別：可串列化。可串列化隔離意味著資料庫保證事務的最終執行結果與串列 （即一次一個， 沒有任何併發） 執行結果相同。

那麼為什麼應用程式中可以提供可串列化的隔離級別，而資料庫卻不能呢？其實根本原因就是應用程式對臨界區大多是記憶體操作，而資料庫要保證持久性（Durability），需要把臨界區的數據持久化到磁碟，可是磁碟操作比記憶體操作要慢好幾個數量級，一次隨機訪問記憶體、 固態硬碟 和 機械硬碟，對應的操作時間分別為幾十納秒、幾十微秒和幾十毫秒，這會導致持有鎖的時間變長，對臨界區資源的競爭將會變得異常激烈，資料庫的性能則會大大降低。

所以，資料庫的研究者就對事務定義了隔離級別這個概念，也就是在高性能與正確性之間做一個權衡，相當於明確地告訴使用者，我們提供了正確性差一點但是性能好一點的模式，以及正確性好一點但是性能差一點的模式，使用者可以根據自己的業務場景來選擇一個合適的隔離級別。

弱隔離級別帶來的風險

弱隔離級別就是非串列化隔離級別。

較弱的隔離級別， 它可以防止某些併發問題，但並非全部的併發問題。

使用這些弱隔離級別，事務併發執行時，可能會出現異常情況，帶來一些難以捉摸的隱患，因此，我們需要瞭解弱隔離級別存在的併發問題以及如何防範存在的併發問題。 然後， 我們就可以使用所掌握的工具和方法來構建正確、 可靠的應用。

各種隔離級別

SQL-92 標准定義了 4 種事務的隔離級別：讀未提交（Read Uncommitted）、讀已提交（Read Committed）、可重覆讀（Repeatable Read）和可串列化（Serializable），在後面的發展過程中，又增加了快照隔離級別（Snapshot Isolation）。

不同的弱隔離級別解決了不同的併發問題（正確性問題），同時也存在一些併發問題。

下麵是各種隔離級別及對應的併發問題：

• ✔️代表該隔離級別已解決該併發問題；
• ❌代表該隔離級別未解決該併發問題。

SQL 標準對隔離級別的定義還是存在一些缺陷，某些定義模棱兩可，不夠精確，且不能做到與實現無關，所以上面的表格只是對常見的隔離級別併發問題的定義，你可以把它當成一個通用的標準參考。

當你使用某一個資料庫時，需要讀一下它的文檔，確定好它的每一種隔離級別具體的併發問題。

• MySQL 的預設隔離級別為：可重覆讀。
• Oracle、PostgreSQL 的預設隔離級別為：讀已提交

事務併發執行時，存在的併發問題

如果兩個事務操作的是不同的數據， 即不存在數據依賴關係， 則它們可以安全地並行執行。但是當出現某個事務修改數據而另一個事務同時要讀取該數據， 或者兩個事務同時修改相同數據時， 就會出現併發問題。

併發問題總結：

• 臟寫：一個事務覆蓋了其他事務尚未提交的寫入。
• 臟讀：一個事務讀到了其他事務尚未提交的寫入。
• 不可重覆讀：一個事務內，多次讀取同一個記錄的結果不一樣。
• 更新丟失：兩個事務同時執行“讀－修改－寫回”操作序列，事務 A 覆蓋了 事務 B 的寫入，但又沒有包含 事務 B 修改後的值，最終導致了部分更新數據發生了丟失。
• 幻讀：一個事務內，多次讀取滿足指定條件的數據，讀出來的結果不一樣。
• 寫傾斜：事務首先查詢數據，根據返回的結果而作出某些決定，然後修改資料庫。當事務提交時，支持決定的前提條件已不再成立。

臟寫

一個事務覆蓋了其他事務尚未提交的寫入。

臟讀

一個事務讀到了其他事務尚未提交的寫入。

舉例說明臟讀

事務 B 修改了 x，在事務 B 提交之前，事務 A 讀到了 x 修改後的數據。這時事務 B 回滾了，相當於事務 A 讀到了一個無效的數據（未實際提交到資料庫中的數據），事務 A 的讀就是臟讀。

不可重覆讀

一個事務內，多次讀取同一個記錄的結果不一樣。（一個事務能夠讀到另一個事務對同一個記錄的修改）

舉例說明不可重覆讀

事務 A 讀取了 x，然後事務 B 修改了 x 並提交。這時事務 A 再次讀取 x，發現兩次讀取同一個記錄的結果不一樣，這就是不可重覆讀。

更新丟失

兩個事務同時執行“讀－修改－寫回”操作序列，事務 A 覆蓋了 事務 B 的寫入，但又沒有包含 事務 B 的修改，最終導致了部分更新數據發生了丟失。

舉例說明更新丟失

事務 A 先讀取某記錄，然後事務 B 再讀取某記錄，事務 B 修改並寫回，緊接著 事務 A 修改並寫入。事務 A 覆蓋了 事務 B 的寫入，但又沒有包含 事務 B 的修改，最終導致事務 B 的更新丟失了。

幻讀

一個事務內，多次讀取滿足指定條件的數據，讀出來的結果不一樣（一個事務能夠讀到另一個事務創建的滿足條件的記錄）

舉例說明幻讀

事務 A 讀取一組滿足條件 1 的數據，之後事務 B 創建了滿足條件 1 的數據，使其滿足條件 1 並提交，如果事務 A 用相同的 條件 1 再次讀取，得到一組不同於第一次讀取的數據。這就叫幻讀。

不可重覆讀和幻讀都是一個事務內，多次執行相同的查詢，結果不一樣。那兩者有什麼區別呢？

• 幻讀 主要說的是，讀到了另一個事務的 insert 或者 update 的滿足條件的記錄
• 不可重覆讀 主要說的是，讀到了另一個事務對同一個記錄的 update

寫傾斜

寫傾斜就是：事務首先查詢數據，根據返回的結果而作出某些決定，然後修改資料庫。當事務提交時，支持決定的前提條件已不再成立。

如何防止併發問題

現在我們已經知道了每一個隔離級別可能會出現的併發問題，如果當前資料庫使用了某一個隔離級別，我們也知道這個隔離級別存在的併發問題，是否有辦法來避免併發問題呢？以及對於避免併發問題是如何實現的？

有些併發問題只能通過提升隔離級別來避免，接下來，我們就針對每一種併發問題一一討論。

防止臟寫

允許臟寫這種併發問題出現的資料庫基本上是不可用的。因此所有的隔離級別都不允許出現臟寫這種併發問題。

防止“臟寫”就意味著，寫資料庫時， 只會覆蓋已成功提交的數據。

防止臟寫通常的方式是推遲第二個寫請求，直到前面的事務完成提交（或者中止）。

資料庫通常採用行級鎖來防止臟寫：如果兩個事務同時嘗試寫入同一個對象時 ，以加鎖的方式來確保第二個寫入等待前面事務完成（包括中止或提交）。

這種鎖定是由處於讀已提交模式 （ 或更強的隔離級別） 的資料庫自動完成的。

防止臟讀

防止 “臟讀”就意味著，讀資料庫時， 只能看到已成功提交的數據。

如果業務中不能接受臟讀，那麼隔離級別要在“讀已提交”隔離級別或者以上。

當有以下需求時，需要防止臟讀：

• 如果事務需要進行多個操作更新多個對象，我們需要保證另一個事務或者應用層要麼看到所有操作執行前的狀態，要麼看到所有操作完成後的狀態，而不能看到部分操作完成的中間狀態。如果我們要提供這樣的保證，那麼就必須防止臟讀。臟讀意味著另一個事務可能會看到部分更新， 而非全部，觀察到部分更新的數據可能會造成用戶的困惑。
• 如果事務發生中止，則所有寫入操作都需要回滾，那麼就必須防止臟讀，避免用戶觀察到一些稍後被回滾的數據， 而這些數據實際並未實際提交到資料庫中。

防止臟讀的解決方案：

• 兩段鎖協議；
• 存儲數據的舊版本和新版本。

一種選擇是使用和防止臟寫相同的鎖，所有試圖讀取該對象的事務必須先申請鎖，事務完成後釋放鎖，從而確保不會發生讀取到一個髒的、 未提交的值。

然而， 加鎖的方式在實際中並不可行， 因為運行時間較長的寫事務會導致許多只讀的事務等待太長時間， 這會嚴重影響只讀事務的響應時間。應用程式任何局部的性能問題會擴散，進而影響整個應用，產生連鎖反應。

因此， 大多數資料庫採用了下麵的方式來防止臟讀：對於每個待更新的對象， 資料庫都會維護對象的兩個版本（其舊值 和 當前持鎖事務將要設置的新值）。在事務提交之前， 其他事務的讀操作都讀取舊值；僅當寫事務提交之後， 才會切換到讀取新值。而 MySQL 使用了多版本併發控制來防止臟讀，多版本比兩個版本更加通用。

防止不可重覆讀

防止“不可重覆讀”就意味著，一個事務執行過程中看到的數據，總是跟這個事務在啟動時看到的數據是一致的。

不能忍受不可重覆讀的場景：

• 備份場景：備份任務要複製整個資料庫，這可能需要花費幾小時才能完成。在備份過程中，數據可以繼續寫入資料庫。因此，備份里可能包含部分舊版本數據和部分新版本數據。 如果從這樣的備份進行恢復，那麼就導致了永久性的不一致。

如果業務中不能接受不可重覆讀，那麼隔離級別要在“可重覆讀”隔離級別或者以上。

在 MySQL 種，可重覆讀隔離級別即快照級別隔離。快照級別隔離的總體想法是：每個事務總是在某個時間點的一致性快照中讀取數據。

為了實現快照級別隔離， MySQL 資料庫採用了一種被稱為多版本併發控制（MultiVersion Concurrency Control，MVCC）的機制。

防止更新丟失

更新丟失可能發生在這樣一個操作場景中：應用程式從資料庫讀取某些值，根據應用邏輯做出修改，然後寫回新值 （read-midify-write 過程）。當有兩個事務在同樣的數據對象上執行類似操作時，後一個寫操作並不包含前一個寫操作的修改，最終導致前一個寫操作的修改丟失。

更新丟失屬於寫事務併發衝突。

防止更新丟失，目前有多種可行的解決方案。

• 原子更新操作：許多資料庫提供了原子更新操作，以避免在應用層代碼完成“讀－修改－寫回”操作序列，如果資料庫支持原子更新操作的話，通常這就是防止更新丟失最好的解決方案。

• • 原子操作通常採用對讀取對象加獨占鎖的方式來實現，這樣在更新被提交之前其他事務不可以讀取它。
  • 原子操作的另一種實現方式是：強制所有的原子操作都在單線程上執行。這也是 Redis 防止更新丟失的解決方案

• 顯式的加鎖：既然原子操作採用對讀取對象加獨占鎖的方式來實現，那麼我們也可以顯式的鎖定待更新的對象，使“讀－修改－寫回”操作序列串列執行。例如使用 MySQL 的 select ...... for update;

原子更新操作和 顯式的加鎖 都是通過強制“讀－修改－寫回”操作序列串列執行來防止丟失更新。

• 自動檢測更新丟失：先讓“讀－修改－寫回”操作序列併發執行，但如果事務管理器檢測到了更新丟失風險，則會中止當前事務，並強制回退到安全的“讀－修改－寫回”方式。
• 比較並設置：先讓“讀－修改－寫回”操作序列併發執行，如果讀取的內容已經發生了變化且值與“舊內容”不匹配，則更新失敗，需要應用層再次檢查併在必要時進行重試。例如 update t1 set col1 = '新內容' where id = 1 and col1 = '舊內容';

自動檢測更新丟失

PostgreSQL 的可重覆讀， Oracle 的可串列化以及 SQL Server 的快照級別隔離等，都可以自動檢測何時發生了更新丟失，然後會中止違規的那個事務。

但是， MySQL 中 InnoDB 存儲引擎的可重覆讀卻並不支持自動檢測更新丟失。

防止幻讀 & 寫傾斜

防止幻讀：

• 使用 可串列化隔離級別
• 在 MySQL 的 可重覆讀隔離級別下，使用 select ...... for update;

使用可串列化隔離級別可以防止幻讀。

可串列化隔離通常被認為是最強的隔離級別。使用可串列化隔離級別可以防止所有可能的競爭條件。

可串列化隔離保證即使事務可能會並行執行，但最終的執行結果與每次執行一個事務（即串列執行）的結果相同。

可串列化隔離級別的實現有以下幾種方式：

• 實際串列執行：
• 兩段鎖 + 索引區間鎖：將兩段鎖與索引區間鎖結合使用，實現可串列化隔離
• 可串列化快照隔離：（這個暫時還沒有瞭解）

MySQL 的可串列化隔離級別使用了第 2 種方法（兩段鎖 + 索引區間鎖）

寫傾斜就是：事務首先查詢數據，根據返回的結果而作出某些決定，然後修改資料庫。當事務提交時，支持決定的前提條件已不再成立。寫傾斜可能發生在這樣一個操作場景中：

1. 第一步 select：應用程式從資料庫讀取一組滿足條件 1 的數據
2. 第二步 決定：根據查詢的結果，應用層代碼來決定下一步的操作（有可能繼續，或者報告錯誤井中止）
3. 第三步 寫入：如果應用程式決定繼續執行，它將發起資料庫寫入（insert，update 或 delete）並提交事務。

而第 3 步的這個寫操作會改變第 2 步做出決定的前提條件，如果兩個事務併發執行這樣的“讀取-決定-寫入”操作序列，那麼後一個寫入改變了前一個寫入執行的前提條件，導致出現意料之外的結果。

防止寫傾斜

對於寫傾斜問題，有幾種可能的解決方案：

• 只使用 可串列化隔離級別 即可避免寫傾斜（使用索引區間鎖，避免其他事務寫入滿足條件的行）
• 更改“讀取-決定-寫入”操作序列的執行順序 為 “寫入-讀取-決定”：先寫入，然後 select 查詢並加獨占鎖（select ...... for update），最後根據查詢的結果來決定是否提交或者放棄。
• 實體化衝突，也稱物化衝突：有的業務場景 select 查詢的是不滿足給定搜索條件的行（例如 select * from t1 where id != 1）如果第 1 步的查詢根本沒有返回任何行，則 select ...... for update 也就無從加鎖，只能考慮實體化衝突。

本質上這三種可能的解決方案都是對事務所依賴的行顯式的加鎖。

對於實體化衝突（物化衝突）的說明

如果問題的關鍵是查詢結果中沒有對象（空）可以加鎖，或許可以人為引人一些可加鎖的對象。這種方法稱為實體化衝突（或物化衝突），它把幻讀問題轉變為針對資料庫中一組具體行的鎖衝突問題。

然而，弄清楚如何實現實體化往往也具有挑戰性，實現過程也容易出錯，這種把一個併發控制機制降級為數據模型的思路總是不夠優雅。出於這些原因，除非萬不得己，沒有其他可選方案，不推薦採用實體化衝突。

參考資料

24｜事務（三）：隔離性，正確與性能之間權衡的藝術-極客時間 (geekbang.org)

《數據密集型應用系統設計》

本文來自博客園，作者：真正的飛魚，轉載請註明原文鏈接：https://www.cnblogs.com/feiyu2/p/16683430.html