弱隔離級別 & 事務并發問題
介紹弱隔離級別
為什么要有弱隔離級別
如果兩個事務操作的是不同的數據， 即不存在數據依賴關系， 則它們可以安全地并行執行。但是當出現某個事務修改數據而另一個事務同時要讀取該數據， 或者兩個事務同時修改相同數據時， 就會出現并發問題。
在應用程序的開發中，我們通常會利用鎖進行并發控制，確保臨界區的資源不會出現多個線程同時進行讀寫的情況，這其實就對應了事務的最高隔離級別：可串行化。可串行化隔離意味著數據庫保證事務的最終執行結果與串行 （即一次一個， 沒有任何并發） 執行結果相同。
那么為什么應用程序中可以提供可串行化的隔離級別，而數據庫卻不能呢？其實根本原因就是應用程序對臨界區大多是內存操作，而數據庫要保證持久性（Durability），需要把臨界區的數據持久化到磁盤，可是磁盤操作比內存操作要慢好幾個數量級，一次隨機訪問內存、 固態硬盤 和 機械硬盤，對應的操作時間分別為幾十納秒、幾十微秒和幾十毫秒，這會導致持有鎖的時間變長，對臨界區資源的競爭將會變得異常激烈，數據庫的性能則會大大降低。
所以，數據庫的研究者就對事務定義了隔離級別這個概念，也就是在高性能與正確性之間做一個權衡，相當于明確地告訴使用者，我們提供了正確性差一點但是性能好一點的模式，以及正確性好一點但是性能差一點的模式，使用者可以根據自己的業務場景來選擇一個合適的隔離級別。
弱隔離級別帶來的風險
弱隔離級別就是非串行化隔離級別。
較弱的隔離級別， 它可以防止某些并發問題，但并非全部的并發問題。
使用這些弱隔離級別，事務并發執行時，可能會出現異常情況，帶來一些難以捉摸的隱患，因此，我們需要了解弱隔離級別存在的并發問題以及如何防范存在的并發問題。 然后， 我們就可以使用所掌握的工具和方法來構建正確、 可靠的應用。
各種隔離級別
SQL-92 標準定義了 4 種事務的隔離級別：讀未提交（Read Uncommitted）、讀已提交（Read Committed）、可重復讀（Repeatable Read）和可串行化（Serializable），在后面的發展過程中，又增加了快照隔離級別（Snapshot Isolation）。
不同的弱隔離級別解決了不同的并發問題（正確性問題），同時也存在一些并發問題。
下面是各種隔離級別及對應的并發問題：
- :heavy_check_mark:代表該隔離級別已解決該并發問題；
- :x:代表該隔離級別未解決該并發問題。
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 種方法（兩段鎖 + 索引區間鎖）
寫傾斜就是：事務首先查詢數據，根據返回的結果而作出某些決定，然后修改數據庫。當事務提交時，支持決定的前提條件已不再成立。寫傾斜可能發生在這樣一個操作場景中：
第一步 select：應用程序從數據庫讀取一組滿足條件 1 的數據
第二步 決定：根據查詢的結果，應用層代碼來決定下一步的操作（有可能繼續，或者報告錯誤井中止）
第三步 寫入：如果應用程序決定繼續執行，它將發起數據庫寫入（insert，update 或 delete）并提交事務。
而第 3 步的這個寫操作會改變第 2 步做出決定的前提條件，如果兩個事務并發執行這樣的“讀取-決定-寫入”操作序列，那么后一個寫入改變了前一個寫入執行的前提條件，導致出現意料之外的結果。
防止寫傾斜
對于寫傾斜問題，有幾種可能的解決方案：
只使用 可串行化隔離級別 即可避免寫傾斜（使用索引區間鎖，避免其他事務寫入滿足條件的行）
更改“讀取-決定-寫入”操作序列的執行順序 為 “寫入-讀取-決定”：先寫入，然后 select 查詢并加獨占鎖（select ...... for update），最后根據查詢的結果來決定是否提交或者放棄。
實體化沖突，也稱物化沖突：有的業務場景 select 查詢的是不滿足給定搜索條件的行（例如 select * from t1 where id != 1）如果第 1 步的查詢根本沒有返回任何行，則 select ...... for update 也就無從加鎖，只能考慮實體化沖突。
本質上這三種可能的解決方案都是對事務所依賴的行顯式的加鎖。
對于實體化沖突（物化沖突）的說明
如果問題的關鍵是查詢結果中沒有對象（空）可以加鎖，或許可以人為引人一些可加鎖的對象。這種方法稱為實體化沖突（或物化沖突），它把幻讀問題轉變為針對數據庫中一組具體行的鎖沖突問題。
然而，弄清楚如何實現實體化往往也具有挑戰性，實現過程也容易出錯，這種把一個并發控制機制降級為數據模型的思路總是不夠優雅。出于這些原因，除非萬不得己，沒有其他可選方案，不推薦采用實體化沖突。
