2021-07-22 14:07:38 +08:00
# 第七章：事務
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
>
>
> ， ： （ ）
------
[TOC]
在資料系統的殘酷現實中，很多事情都可能出錯：
- 資料庫軟體、硬體可能在任意時刻發生故障（包括寫操作進行到一半時）。
- 應用程式可能在任意時刻崩潰（包括一系列操作的中間）。
- 網路中斷可能會意外切斷資料庫與應用的連線，或資料庫之間的連線。
- 多個客戶端可能會同時寫入資料庫，覆蓋彼此的更改。
- 客戶端可能讀取到無意義的資料，因為資料只更新了一部分。
- 客戶之間的競爭條件可能導致令人驚訝的錯誤。
為了實現可靠性，系統必須處理這些故障，確保它們不會導致整個系統的災難性故障。但是實現容錯機制工作量巨大。需要仔細考慮所有可能出錯的事情，並進行大量的測試，以確保解決方案真正管用。
（ ） （ ） （ ） ， （ ）
（ ）
，
## 事務的棘手概念
（ ） ， ， ： ， ， ，
2000年以後， （ ） （ ） ， （ ） （ ） ： ， ，
隨著這種新型分散式資料庫的炒作， ， ，
事實並非如此簡單：與其他技術設計選擇一樣，事務有其優勢和侷限性。為了理解這些權衡，讓我們瞭解事務所提供保證的細節——無論是在正常執行中還是在各種極端（但是現實存在）情況下。
### ACID的含義
事務所提供的安全保證， ， （ ） ， （ ） ， （ ） （ ） ，
但實際上， ， ， （ ） ， ， ， ，
（ ， （ ） ， （ ） （ ） ， ， ， ）
讓我們深入瞭解原子性，一致性，隔離性和永續性的定義，這可以讓我們提煉出事務的思想。
#### 原子性（ ）
一般來說，原子是指不能分解成小部分的東西。這個詞在計算機的不同領域中意味著相似但又微妙不同的東西。例如，在多執行緒程式設計中，如果一個執行緒執行一個原子操作，這意味著另一個執行緒無法看到該操作的一半結果。系統只能處於操作之前或操作之後的狀態，而不是介於兩者之間的狀態。
相比之下， （ ） ** *I*** 中，即[**隔離性（ ） （ ）
ACID的原子性而是描述了當客戶想進行多次寫入， ， ， ， （ ） ， ，
如果沒有原子性，在多處更改進行到一半時發生錯誤，很難知道哪些更改已經生效，哪些沒有生效。該應用程式可以再試一次，但冒著進行兩次相同變更的風險，可能會導致資料重複或錯誤的資料。原子性簡化了這個問題：如果事務被**中止（ ）
ACID原子性的定義特徵是： **可中止性（ ） 是更好的術語，但本書將繼續使用原子性，因為這是慣用詞。
#### 一致性（ ）
一致性這個詞被賦予太多含義：
* 在[第5章](ch5.md)中，我們討論了副本一致性，以及非同步複製系統中的最終一致性問題（參閱“[複製延遲問題](ch5.md#複製延遲問題)”）。
* [一致性雜湊（ ） ](ch6.md#一致性雜湊 ))是某些系統用於重新分割槽的一種分割槽方法。
* 在[CAP定理](ch9.md#CAP定理)中，一致性一詞用於表示[可線性化](ch9.md#線性化)。
* 在ACID的上下文中，
很不幸，這一個詞就至少有四種不同的含義。
ACID一致性的概念是， （ ）
但是，一致性的這種概念取決於應用程式對不變數的觀念，應用程式負責正確定義它的事務，並保持一致性。這並不是資料庫可以保證的事情：如果你寫入違反不變數的髒資料，資料庫也無法阻止你。 （一些特定型別的不變數可以由資料庫檢查，例如外來鍵約束或唯一約束，但是一般來說，是應用程式來定義什麼樣的資料是有效的，什麼樣是無效的。—— 資料庫只管儲存。）
原子性， ， （ ） ， ，
[^i]: 喬·海勒斯坦（ ） ， ， ，
#### 隔離性（ ）
大多數資料庫都會同時被多個客戶端訪問。如果它們各自讀寫資料庫的不同部分，這是沒有問題的，但是如果它們訪問相同的資料庫記錄，則可能會遇到**併發**問題（**競爭條件（ ）
2020-10-06 09:25:46 +08:00
[圖7-1 ](../img/fig7-1.png )是這類問題的一個簡單例子。假設你有兩個客戶端同時在資料庫中增長一個計數器。（假設資料庫中沒有自增操作）每個客戶端需要讀取計數器的當前值，加 1 ，再回寫新值。[圖7-1](../img/fig7-1.png) 中， ， ； ，
2020-10-06 01:21:28 +08:00
ACID意義上的隔離性意味著， （ ） ， ， （ ） ，
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-1 兩個客戶之間的競爭狀態同時遞增計數器**
然而實踐中很少會使用可序列化隔離， ， ， （ ）
#### 永續性（ ）
資料庫系統的目的是，提供一個安全的地方儲存資料，而不用擔心丟失。**永續性** 是一個承諾，即一旦事務成功完成，即使發生硬體故障或資料庫崩潰，寫入的任何資料也不會丟失。
在單節點資料庫中， ， （
如“[可靠性](ch1.md#可靠性)”一節所述，**完美的永續性是不存在的** ：如果所有硬碟和所有備份同時被銷燬，那顯然沒有任何資料庫能救得了你。
> #### 複製和永續性
>
> 在歷史上， （ ） ？
>
> 真相是，沒有什麼是完美的：
>
> * 如果你寫入磁碟然後機器宕機，即使資料沒有丟失，在修復機器或將磁碟轉移到其他機器之前，也是無法訪問的。這種情況下，複製系統可以保持可用性。
> * 一個相關性故障（ ， ） （
> * 在非同步複製系統中，當主庫不可用時，最近的寫入操作可能會丟失（參閱「[處理節點宕機](ch5.md#處理節點宕機)」）。
> * 當電源突然斷電時， ， ： ，
> * 儲存引擎和檔案系統之間的微妙互動可能會導致難以追蹤的錯誤，
> * 磁碟上的資料可能會在沒有檢測到的情況下逐漸損壞【17】。如果資料已損壞一段時間， ，
> * 一項關於固態硬碟的研究發現， ， ％ ％ ， ，
> * 如果SSD斷電， ，
>
> 在實踐中，沒有一種技術可以提供絕對保證。只有各種降低風險的技術，包括寫入磁碟，複製到遠端機器和備份——它們可以且應該一起使用。與往常一樣，最好抱著懷疑的態度接受任何理論上的“保證”
### 單物件和多物件操作
回顧一下， ， ， ：
***原子性***
如果在一系列寫操作的中途發生錯誤，則應中止事務處理，並丟棄當前事務的所有寫入。換句話說，資料庫免去了使用者對部分失敗的擔憂——透過提供“**寧為玉碎， （ ）
***隔離性***
同時執行的事務不應該互相干擾。例如，如果一個事務進行多次寫入，則另一個事務要麼看到全部寫入結果，要麼什麼都看不到，但不應該是一些子集。
2020-10-06 09:25:46 +08:00
這些定義假設你想同時修改多個物件（行，文件，記錄）。通常需要**多物件事務（ ）
2020-10-06 01:21:28 +08:00
```sql
SELECT COUNT（ ）
```
但如果郵件太多，你可能會覺得這個查詢太慢，並決定用單獨的欄位儲存未讀郵件的數量（一種反規範化）。現在每當一個新訊息寫入時，必須也增長未讀計數器，每當一個訊息被標記為已讀時，也必須減少未讀計數器。
2020-10-06 09:25:46 +08:00
在[圖7-2](../img/fig7-2.png)中， ：
2020-10-06 01:21:28 +08:00
[^ii]: 可以說郵件應用中的錯誤計數器並不是什麼特別重要的問題。但換種方式來看，你可以把未讀計數器換成客戶賬戶餘額，把郵件收發看成支付交易。
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-2 違反隔離性：一個事務讀取另一個事務的未被執行的寫入（“髒讀”）。**
2020-10-06 09:25:46 +08:00
[圖7-3 ](../img/fig7-3.png )說明了對原子性的需求：如果在事務過程中發生錯誤，郵箱和未讀計數器的內容可能會失去同步。在原子事務中，如果對計數器的更新失敗，事務將被中止，並且插入的電子郵件將被回滾。
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-3 原子性確保發生錯誤時，事務先前的任何寫入都會被撤消，以避免狀態不一致**
多物件事務需要某種方式來確定哪些讀寫操作屬於同一個事務。在關係型資料庫中， ： ， `COMMIT` 語句之間的所有內容，被認為是同一事務的一部分.[^iii]
[^iii]: 這並不完美。如果TCP連線中斷， ， ， ， ，
另一方面， （ ， ） ， ： ， ，
#### 單物件寫入
當單個物件發生改變時，原子性和隔離也是適用的。例如，假設您正在向資料庫寫入一個 20 KB的 JSON文件：
- 如果在傳送第一個10 KB之後網路連線中斷， ？
- 如果在資料庫正在覆蓋磁碟上的前一個值的過程中電源發生故障，是否最終將新舊值拼接在一起？
- 如果另一個客戶端在寫入過程中讀取該文件，是否會看到部分更新的值？
這些問題非常讓人頭大，故儲存引擎一個幾乎普遍的目標是：對單節點上的單個物件（例如鍵值對）上提供原子性和隔離性。原子性可以透過使用日誌來實現崩潰恢復（參閱“[使B樹可靠]()”），並且可以使用每個物件上的鎖來實現隔離（每次只允許一個執行緒訪問物件） ）。
2020-10-06 09:25:46 +08:00
一些資料庫也提供更復雜的原子操作，例如自增操作，這樣就不再需要像 [圖7-1 ](../img/fig7-1.png ) 那樣的讀取-修改-寫入序列了。同樣流行的是 ** [比較和設定（ ） ](#比較並設定（ ） )** 操作，當值沒有被其他併發修改過時，才允許執行寫操作。
2020-10-06 01:21:28 +08:00
這些單物件操作很有用，因為它們可以防止在多個客戶端嘗試同時寫入同一個物件時丟失更新（參閱“[防止丟失更新](#防止丟失更新)”） ， ， ，
[^iv]: 嚴格地說，**原子自增（ ） ， **孤立（ ） 的或**可序列化（ ）
#### 多物件事務的需求
許多分散式資料儲存已經放棄了多物件事務，因為多物件事務很難跨分割槽實現，而且在需要高可用性或高效能的情況下，它們可能會礙事。但說到底，在分散式資料庫中實現事務，並沒有什麼根本性的障礙。[第9章](ch9.md) 將討論分散式事務的實現。
但是我們是否需要多物件事務？**是否有可能只用鍵值資料模型和單物件操作來實現任何應用程式？**
有一些場景中，單物件插入，更新和刪除是足夠的。但是許多其他場景需要協調寫入幾個不同的物件：
* 在關係資料模型中，一個表中的行通常具有對另一個表中的行的外來鍵引用。（類似的是，在一個圖資料模型中，一個頂點有著到其他頂點的邊）。多物件事務使你確信這些引用始終有效：當插入幾個相互引用的記錄時，外來鍵必須是正確的，最新的，不然資料就沒有意義。
2020-10-06 09:25:46 +08:00
* 在文件資料模型中，需要一起更新的欄位通常在同一個文件中，這被視為單個物件——更新單個文件時不需要多物件事務。但是，缺乏連線功能的文件資料庫會鼓勵非規範化（參閱“[關係型資料庫與文件資料庫在今日的對比](ch2.md#關係型資料庫與文件資料庫在今日的對比)”）。當需要更新非規範化的資訊時，如 [圖7-2 ](../img/fig7-2.png ) 所示，需要一次更新多個文件。事務在這種情況下非常有用，可以防止非規範化的資料不同步。
2020-10-06 01:21:28 +08:00
* 在具有二級索引的資料庫中（除了純粹的鍵值儲存以外幾乎都有），每次更改值時都需要更新索引。從事務角度來看，這些索引是不同的資料庫物件：例如，如果沒有事務隔離性，記錄可能出現在一個索引中，但沒有出現在另一個索引中，因為第二個索引的更新還沒有發生。
這些應用仍然可以在沒有事務的情況下實現。然而，**沒有原子性，錯誤處理就要複雜得多，缺乏隔離性，就會導致併發問題**。我們將在“[弱隔離級別](#弱隔離級別)”中討論這些問題，並在[第12章]()中探討其他方法。
#### 處理錯誤和中止
事務的一個關鍵特性是，如果發生錯誤，它可以中止並安全地重試。 ACID資料庫基於這樣的哲學： ， ， ，
然而並不是所有的系統都遵循這個哲學。特別是具有[無主複製](ch6.md#無主複製)的資料儲存，主要是在“盡力而為”的基礎上進行工作。可以概括為“資料庫將做盡可能多的事，執行遇到錯誤時，它不會撤消它已經完成的事情“ ——所以，從錯誤中恢復是應用程式的責任。
錯誤發生不可避免， ， ， （ ）
儘管重試一箇中止的事務是一個簡單而有效的錯誤處理機制，但它並不完美：
- 如果事務實際上成功了，但是在伺服器試圖向客戶端確認提交成功時網路發生故障（所以客戶端認為提交失敗了），那麼重試事務會導致事務被執行兩次——除非你有一個額外的應用級除重機制。
- 如果錯誤是由於負載過大造成的，則重試事務將使問題變得更糟，而不是更好。為了避免這種正反饋迴圈，可以限制重試次數，使用指數退避演算法，並單獨處理與過載相關的錯誤（如果允許）。
- 僅在臨時性錯誤（例如，由於死鎖，異常情況，臨時性網路中斷和故障切換）後才值得重試。在發生永久性錯誤（例如，違反約束）之後重試是毫無意義的。
- 如果事務在資料庫之外也有副作用，即使事務被中止，也可能發生這些副作用。例如，如果你正在傳送電子郵件，那你肯定不希望每次重試事務時都重新發送電子郵件。如果你想確保幾個不同的系統一起提交或放棄，**二階段提交（ ） （ ） （ ）
- 如果客戶端程序在重試中失效，任何試圖寫入資料庫的資料都將丟失。
## 弱隔離級別
如果兩個事務不觸及相同的資料，它們可以安全地**並行（ ）
併發BUG很難透過測試找到， ，
[^譯註i]: 軼事：偶然出現的瞬時錯誤有時稱為***Heisenbug***，而確定性的問題對應地稱為***Bohrbugs***
出於這個原因，資料庫一直試圖透過提供**事務隔離（ ） （ ）
實際上不幸的是：隔離並沒有那麼簡單。**可序列化** 會有效能損失， ， ， ， ，
弱事務隔離級別導致的併發性錯誤不僅僅是一個理論問題。它們造成了很多的資金損失【24,25】， ， ， ！ （ ） ，
比起盲目地依賴工具，我們應該對存在的併發問題的種類，以及如何防止這些問題有深入的理解。然後就可以使用我們所掌握的工具來構建可靠和正確的應用程式。
在本節中，我們將看幾個在實踐中使用的弱（**不可序列化（ ）
### 讀已提交
最基本的事務隔離級別是**讀已提交（ ）
1. 從資料庫讀時，只能看到已提交的資料（沒有**髒讀（ ）
2. 寫入資料庫時，只會覆蓋已經寫入的資料（沒有**髒寫（ ）
我們來更詳細地討論這兩個保證。
[^v]: 某些資料庫支援甚至更弱的隔離級別，稱為**讀未提交（ ）
#### 沒有髒讀
設想一個事務已經將一些資料寫入資料庫，但事務還沒有提交或中止。另一個事務可以看到未提交的資料嗎？如果是的話，那就叫做**髒讀（ ）
在**讀已提交**隔離級別執行的事務必須防止髒讀。這意味著事務的任何寫入操作只有在該事務提交時才能被其他人看到（然後所有的寫入操作都會立即變得可見）。如[圖7-4]()所示， ， `get x ` 仍舊返回舊值2 ，
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-4 沒有髒讀：
為什麼要防止髒讀，有幾個原因：
2020-10-06 09:25:46 +08:00
- 如果事務需要更新多個物件，髒讀取意味著另一個事務可能會只看到一部分更新。例如，在[圖7-2](../img/fig7-2.png)中，使用者看到新的未讀電子郵件，但看不到更新的計數器。這就是電子郵件的髒讀。看到處於部分更新狀態的資料庫會讓使用者感到困惑，並可能導致其他事務做出錯誤的決定。
- 如果事務中止，則所有寫入操作都需要回滾（如[圖7-3](../img/fig7-3.png)所示）。如果資料庫允許髒讀，那就意味著一個事務可能會看到稍後需要回滾的資料，即從未實際提交給資料庫的資料。想想後果就讓人頭大。
2020-10-06 01:21:28 +08:00
#### 沒有髒寫
如果兩個事務同時嘗試更新資料庫中的相同物件，會發生什麼情況？我們不知道寫入的順序是怎樣的，但是我們通常認為後面的寫入會覆蓋前面的寫入。
但是，如果先前的寫入是尚未提交事務的一部分，又會發生什麼情況，後面的寫入會覆蓋一個尚未提交的值？這被稱作**髒寫（ ）
透過防止髒寫，這個隔離級別避免了一些併發問題：
2020-10-06 09:25:46 +08:00
- 如果事務更新多個物件，髒寫會導致不好的結果。例如，考慮 [圖7-5 ](../img/fig7-5.png )， ， ： ， ， ， （ ） ， （ ）
2020-10-06 01:21:28 +08:00
- 但是，提交讀取並不能防止[圖7-1]()中兩個計數器增量之間的競爭狀態。在這種情況下，第二次寫入發生在第一個事務提交後，所以它不是一個髒寫。這仍然是不正確的，但是出於不同的原因，在“[防止更新丟失](#防止丟失更新)”中將討論如何使這種計數器增量安全。
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-5 如果存在髒寫，來自不同事務的衝突寫入可能會混淆在一起**
#### 實現讀已提交
**讀已提交**是一個非常流行的隔離級別。這是Oracle 11g， ， ，
最常見的情況是，資料庫透過使用**行鎖（ ）
如何防止髒讀？一種選擇是使用相同的鎖，並要求任何想要讀取物件的事務來簡單地獲取該鎖，然後在讀取之後立即再次釋放該鎖。這能確保不會讀取進行時，物件不會在髒的狀態，有未提交的值（因為在那段時間鎖會被寫入該物件的事務持有）。
但是要求讀鎖的辦法在實踐中效果並不好。因為一個長時間執行的寫入事務會迫使許多隻讀事務等到這個慢寫入事務完成。這會損失只讀事務的響應時間，並且不利於可操作性：因為等待鎖，應用某個部分的遲緩可能由於連鎖效應，導致其他部分出現問題。
出於這個原因，大多數資料庫[^vi]使用[圖7-4]()的方式防止髒讀：對於寫入的每個物件，資料庫都會記住舊的已提交值，和由當前持有寫入鎖的事務設定的新值。當事務正在進行時，任何其他讀取物件的事務都會拿到舊值。 只有當新值提交後，事務才會切換到讀取新值。
[^vi]: 在撰寫本文時，唯一在讀已提交隔離級別使用讀鎖的主流資料庫是使用`read_committed_snapshot = off`配置的IBM DB2和Microsoft SQL Server [23,36]。
### 快照隔離和可重複讀
如果只從表面上看讀已提交隔離級別你就認為它完成了事務所需的一切，那是可以原諒的。它允許**中止**（原子性的要求）；它防止讀取不完整的事務結果，並且防止併發寫入造成的混合。事實上這些功能非常有用，比起沒有事務的系統來，可以提供更多的保證。
2020-10-06 09:25:46 +08:00
但是在使用此隔離級別時，仍然有很多地方可能會產生併發錯誤。例如[圖7-6](../img/fig7-6.png)說明了讀已提交時可能發生的問題。
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-6 讀取偏差：
愛麗絲在銀行有1000美元的儲蓄， ， ， （ ） ， （ ， ） ，
這種異常被稱為**不可重複讀（ ） （ ） ： ， （ ） ， ：
> 不幸的是，術語**偏差（ ）
對於Alice的情況， ， ， ：
***備份***
***分析查詢和完整性檢查***
**快照隔離（ ） ， （ ）
快照隔離對長時間執行的只讀查詢（如備份和分析）非常有用。如果查詢的資料在查詢執行的同時發生變化，則很難理解查詢的含義。當一個事務可以看到資料庫在某個特定時間點凍結時的一致快照，理解起來就很容易了。
快照隔離是一個流行的功能： ， ， ，
#### 實現快照隔離
與讀取提交的隔離類似，快照隔離的實現通常使用寫鎖來防止髒寫（請參閱“[讀已提交](#讀已提交)”），這意味著進行寫入的事務會阻止另一個事務修改同一個物件。但是讀取不需要任何鎖定。從效能的角度來看，快照隔離的一個關鍵原則是：**讀不阻塞寫，寫不阻塞讀**。這允許資料庫在處理一致性快照上的長時間查詢時，可以正常地同時處理寫入操作。且兩者間沒有任何鎖定爭用。
2021-01-04 11:25:37 +08:00
為了實現快照隔離，資料庫使用了我們看到的用於防止[圖7-4]()中的髒讀的機制的一般化。資料庫必須可能保留一個物件的幾個不同的提交版本，因為各種正在進行的事務可能需要看到資料庫在不同的時間點的狀態。因為它並排維護著多個版本的物件，所以這種技術被稱為**多版本併發控制（ ）
2020-10-06 01:21:28 +08:00
如果一個數據庫只需要提供**讀已提交**的隔離級別，而不提供**快照隔離**， ：
[圖7-7]()說明了如何在PostgreSQL中實現基於MVCC的快照隔離【31】（ ） ， ， （ ） ，
[^vii]: 事實上， ， ， （ ）
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-7 使用多版本物件實現快照隔離**
表中的每一行都有一個 `created_by` 欄位， ， `deleted_by` 欄位，最初是空的。如果某個事務刪除了一行，那麼該行實際上並未從資料庫中刪除，而是透過將 `deleted_by` 欄位設定為請求刪除的事務的ID來標記為刪除。在稍後的時間， ， ，
[^譯註ii]: 在PostgreSQL中， ，
`UPDATE` 操作在內部翻譯為 `DELETE` 和 `INSERT` 。例如，在[圖7-7]()中， ，
#### 觀察一致性快照的可見性規則
當一個事務從資料庫中讀取時， ， ， ：
1. 在每次事務開始時，資料庫列出當時所有其他（尚未提交或尚未中止）的事務清單，即使之後提交了，這些事務已執行的任何寫入也都會被忽略。
2. 被中止事務所執行的任何寫入都將被忽略。
3. 由具有較晚事務ID（ ， ） ，
4. 所有其他寫入，對應用都是可見的。
這些規則適用於建立和刪除物件。在[圖7-7]()中， （ ， ） ， （ ）
換句話說，如果以下兩個條件都成立，則可見一個物件：
- 讀事務開始時，建立該物件的事務已經提交。
- 物件未被標記為刪除，或如果被標記為刪除，請求刪除的事務在讀事務開始時尚未提交。
長時間執行的事務可能會長時間使用快照，並繼續讀取（從其他事務的角度來看）早已被覆蓋或刪除的值。由於從來不原地更新值，而是每次值改變時建立一個新的版本，資料庫可以在提供一致快照的同時只產生很小的額外開銷。
#### 索引和快照隔離
索引如何在多版本資料庫中工作？一種選擇是使索引簡單地指向物件的所有版本，並且需要索引查詢來過濾掉當前事務不可見的任何物件版本。當垃圾收集刪除任何事務不再可見的舊物件版本時，相應的索引條目也可以被刪除。
在實踐中， ， ，
在CouchDB， （ ） ， ， ， ，
使用僅追加的B樹， （ ） ， ， ， ；
#### 可重複讀與命名混淆
快照隔離是一個有用的隔離級別， ， ， （ ） ， （ ）
這種命名混淆的原因是SQL標準沒有**快照隔離**的概念， ， （ ）
不幸的是， ， ， ， ， ， ，
結果，沒有人真正知道**可重複讀**的意思。
### 防止丟失更新
到目前為止已經討論的**讀已提交**和**快照隔離**級別，主要保證了**只讀事務在併發寫入時**可以看到什麼。卻忽略了兩個事務併發寫入的問題——我們只討論了[髒寫](#髒寫)，一種特定型別的寫-寫衝突是可能出現的。
併發的寫入事務之間還有其他幾種有趣的衝突。其中最著名的是**丟失更新（ ）
如果應用從資料庫中讀取一些值，修改它並寫回修改的值（讀取-修改-寫入序列），則可能會發生丟失更新的問題。如果兩個事務同時執行，則其中一個的修改可能會丟失，因為第二個寫入的內容並沒有包括第一個事務的修改（有時會說後面寫入**狠揍（ ）
- 增加計數器或更新賬戶餘額（需要讀取當前值，計算新值並寫回更新後的值）
- 在複雜值中進行本地修改： ， （ ， ）
- 兩個使用者同時編輯wiki頁面， ，
這是一個普遍的問題，所以已經開發了各種解決方案。
#### 原子寫
許多資料庫提供了原子更新操作，從而消除了在應用程式程式碼中執行讀取-修改-寫入序列的需要。如果你的程式碼可以用這些操作來表達，那這通常是最好的解決方案。例如，下面的指令在大多數關係資料庫中是併發安全的：
```sql
UPDATE counters SET value = value + 1 WHERE key = 'foo';
```
類似地， ， （ ） ，
[^viii]: 將文字文件的編輯表示為原子的變化流是可能的，儘管相當複雜。參閱“[自動衝突解決](ch5.md#題外話：自動衝突解決)”。
原子操作通常透過在讀取物件時，獲取其上的排它鎖來實現。以便更新完成之前沒有其他事務可以讀取它。這種技術有時被稱為**遊標穩定性（ ）
不幸的是， ， ，
#### 顯式鎖定
如果資料庫的內建原子操作沒有提供必要的功能，防止丟失更新的另一個選擇是讓應用程式顯式地鎖定將要更新的物件。然後應用程式可以執行讀取-修改-寫入序列，如果任何其他事務嘗試同時讀取同一個物件，則強制等待，直到第一個**讀取-修改-寫入序列**完成。
例如， ， ， ， ， ，
**例7-1 顯式鎖定行以防止丟失更新**
```plsql
BEGIN TRANSACTION;
SELECT * FROM figures
WHERE name = 'robot' AND game_id = 222
FOR UPDATE;
-- 檢查玩家的操作是否有效，
UPDATE figures SET position = 'c4' WHERE id = 1234;
COMMIT;
```
- `FOR UPDATE` 子句告訴資料庫應該對該查詢返回的所有行加鎖。
這是有效的，但要做對，你需要仔細考慮應用邏輯。忘記在程式碼某處加鎖很容易引入競爭條件。
#### 自動檢測丟失的更新
原子操作和鎖是透過強制**讀取-修改-寫入序列**按順序發生，來防止丟失更新的方法。另一種方法是允許它們並行執行，如果事務管理器檢測到丟失更新，則中止事務並強制它們重試其**讀取-修改-寫入序列**。
這種方法的一個優點是， ， ， ， ， ， ， ， ，
丟失更新檢測是一個很好的功能，因為它不需要應用程式碼使用任何特殊的資料庫功能，你可能會忘記使用鎖或原子操作，從而引入錯誤；但丟失更新的檢測是自動發生的，因此不太容易出錯。
#### 比較並設定（ ）
在不提供事務的資料庫中，有時會發現一種原子操作：**比較並設定（ ）
例如， ， ， ， ：
```sql
-- 根據資料庫的實現情況，這可能也可能不安全
UPDATE wiki_pages SET content = '新內容'
WHERE id = 1234 AND content = '舊內容';
```
如果內容已經更改並且不再與“舊內容”相匹配，則此更新將不起作用，因此您需要檢查更新是否生效，必要時重試。但是，如果資料庫允許`WHERE`子句從舊快照中讀取，則此語句可能無法防止丟失更新，因為即使發生了另一個併發寫入，`WHERE`條件也可能為真。在依賴資料庫的CAS操作前要檢查其是否安全。
#### 衝突解決和複製
在複製資料庫中（參見[第5章](ch5.md)），防止丟失的更新需要考慮另一個維度：由於在多個節點上存在資料副本，並且在不同節點上的資料可能被併發地修改，因此需要採取一些額外的步驟來防止丟失更新。
鎖和CAS操作假定只有一個最新的資料副本。但是多主或無主複製的資料庫通常允許多個寫入併發執行， ，
相反，如“[檢測併發寫入](ch5.md#檢測併發寫入)”一節所述，這種複製資料庫中的一種常見方法是允許併發寫入建立多個衝突版本的值（也稱為兄弟），並使用應用程式碼或特殊資料結構在事實發生之後解決和合並這些版本。
原子操作可以在複製的上下文中很好地工作， （ ， ， ） ， ， ， ，
另一方面， （ ） ， ，
#### 寫入偏差與幻讀
前面的章節中，我們看到了**髒寫**和**丟失更新**，當不同的事務併發地嘗試寫入相同的物件時，會出現這兩種競爭條件。為了避免資料損壞，這些競爭條件需要被阻止——既可以由資料庫自動執行，也可以透過鎖和原子寫操作這類手動安全措施來防止。
但是，併發寫入間可能發生的競爭條件還沒有完。在本節中，我們將看到一些更微妙的衝突例子。
首先， ： ， （ ， ） ，
2020-10-06 09:25:46 +08:00
現在想象一下， ， ，
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-8 寫入偏差導致應用程式錯誤的示例**
在兩個事務中，應用首先檢查是否有兩個或以上的醫生正在值班；如果是的話，它就假定一名醫生可以安全地休班。由於資料庫使用快照隔離，兩次檢查都返回 2 ， ， ，
#### 寫偏差的特徵
這種異常稱為**寫偏差**【28】。它既不是**髒寫**，也不是**丟失更新**， （ ） ， ： ，
可以將寫入偏差視為丟失更新問題的一般化。如果兩個事務讀取相同的物件，然後更新其中一些物件（不同的事務可能更新不同的物件），則可能發生寫入偏差。在多個事務更新同一個物件的特殊情況下，就會發生髒寫或丟失更新（取決於時機）。
我們看到，有各種不同的方法來防止丟失的更新。隨著寫偏差，我們的選擇更受限制：
* 由於涉及多個物件，單物件的原子操作不起作用。
* 不幸的是， ， ， ， ， （
* 某些資料庫允許配置約束， （ ， ， ） ， ， ， ，
* 如果無法使用可序列化的隔離級別，則此情況下的次優選項可能是顯式鎖定事務所依賴的行。在例子中，你可以寫下如下的程式碼：
```sql
BEGIN TRANSACTION;
SELECT * FROM doctors
WHERE on_call = TRUE
AND shift_id = 1234 FOR UPDATE;
UPDATE doctors
SET on_call = FALSE
WHERE name = 'Alice'
AND shift_id = 1234;
COMMIT;
```
* 和以前一樣，`FOR UPDATE`告訴資料庫鎖定返回的所有行用於更新。
#### 寫偏差的更多例子
寫偏差乍看像是一個深奧的問題，但一旦意識到這一點，很容易會注意到更多可能的情況。以下是一些例子：
***會議室預訂系統***
假設你想強制執行， ， （ ） ， ， （ ）
[^ix]: 在PostgreSQL中， ，
**例7-2 會議室預訂系統試圖避免重複預訂（在快照隔離下不安全）**
```sql
BEGIN TRANSACTION;
-- 檢查所有現存的與12:00~13:00重疊的預定
SELECT COUNT(*) FROM bookings
WHERE room_id = 123 AND
end_time > '2015-01-01 12:00' AND start_time < '2015-01-01 13:00';
-- 如果之前的查詢返回0
INSERT INTO bookings(room_id, start_time, end_time, user_id)
VALUES (123, '2015-01-01 12:00', '2015-01-01 13:00', 666);
COMMIT;
```
不幸的是，快照隔離並不能防止另一個使用者同時插入衝突的會議。為了確保不會遇到排程衝突，你又需要可序列化的隔離級別了。
***多人遊戲***
在[例7-1]()中，我們使用一個鎖來防止丟失更新（也就是確保兩個玩家不能同時移動同一個棋子）。但是鎖定並不妨礙玩家將兩個不同的棋子移動到棋盤上的相同位置，或者採取其他違反遊戲規則的行為。按照您正在執行的規則型別，也許可以使用唯一約束，否則您很容易發生寫入偏差。
***搶注使用者名稱***
在每個使用者擁有唯一使用者名稱的網站上，兩個使用者可能會嘗試同時建立具有相同使用者名稱的帳戶。可以在事務檢查名稱是否被搶佔，如果沒有則使用該名稱建立賬戶。但是像在前面的例子中那樣，在快照隔離下這是不安全的。幸運的是，唯一約束是一個簡單的解決辦法（第二個事務在提交時會因為違反使用者名稱唯一約束而被中止）。
***防止雙重開支***
允許使用者花錢或積分的服務， ， ， ， ， ，
#### 導致寫入偏差的幻讀
所有這些例子都遵循類似的模式：
1. 一個`SELECT`查詢找出符合條件的行，並檢查是否符合一些要求。（例如：至少有兩名醫生在值班；不存在對該會議室同一時段的預定；棋盤上的位置沒有被其他棋子佔據；使用者名稱還沒有被搶注；賬戶裡還有足夠餘額）
2. 按照第一個查詢的結果，應用程式碼決定是否繼續。（可能會繼續操作，也可能中止並報錯）
3. 如果應用決定繼續操作，就執行寫入（插入、更新或刪除），並提交事務。
這個寫入的效果改變了步驟2 中的先決條件。換句話說， ， ， （ ， ， ， ， ）
這些步驟可能以不同的順序發生。例如可以首先進行寫入， ，
在醫生值班的例子中， ， ， ，
這種效應：一個事務中的寫入改變另一個事務的搜尋查詢的結果，被稱為**幻讀**【3】。快照隔離避免了只讀查詢中幻讀， ，
#### 物化衝突
如果幻讀的問題是沒有物件可以加鎖，也許可以人為地在資料庫中引入一個鎖物件？
例如， ， （ ） （ ）
現在，要建立預訂的事務可以鎖定（`SELECT FOR UPDATE`）表中與所需房間和時間段對應的行。在獲得鎖定之後，它可以檢查重疊的預訂並像以前一樣插入新的預訂。請注意，這個表並不是用來儲存預訂相關的資訊——它完全就是一組鎖，用於防止同時修改同一房間和時間範圍內的預訂。
這種方法被稱為**物化衝突（ ） ， ， ， ， ， ， （ ）
## 可序列化
在本章中，已經看到了幾個易於出現競爭條件的事務例子。**讀已提交**和**快照隔離**級別會阻止某些競爭條件，但不會阻止另一些。我們遇到了一些特別棘手的例子，**寫入偏差**和**幻讀**。這是一個可悲的情況：
- 隔離級別難以理解，並且在不同的資料庫中實現的不一致（例如，“可重複讀”的含義天差地別）。
- 光檢查應用程式碼很難判斷在特定的隔離級別執行是否安全。 特別是在大型應用程式中，您可能並不知道併發發生的所有事情。
- 沒有檢測競爭條件的好工具。原則上來說， ， ，
這不是一個新問題， ， ， ： （ ）
**可序列化（ ）
但如果可序列化隔離級別比弱隔離級別的爛攤子要好得多，那為什麼沒有人見人愛？為了回答這個問題，我們需要看看實現可序列化的選項，以及它們如何執行。目前大多數提供可序列化的資料庫都使用了三種技術之一，本章的剩餘部分將會介紹這些技術。
- 字面意義上地序列順序執行事務（參見“[真的序列執行](#真的序列執行)”）
- **兩相鎖定（ ） （ ） （ ）
- 樂觀併發控制技術，例如**可序列化的快照隔離（ ） （ ） （ ）
現在將主要在單節點資料庫的背景下討論這些技術；在[第9章](ch9.md)中，我們將研究如何將它們推廣到涉及分散式系統中多個節點的事務。
#### 真的序列執行
避免併發問題的最簡單方法就是完全不要併發：在單個執行緒上按順序一次只執行一個事務。這樣做就完全繞開了檢測/防止事務間衝突的問題，由此產生的隔離，正是可序列化的定義。
儘管這似乎是一個明顯的主意， ， ， ？
兩個進展引發了這個反思：
- RAM足夠便宜了， （
- 資料庫設計人員意識到OLTP事務通常很短， （
序列執行事務的方法在VoltDB/H-Store， ， ，
#### 在儲存過程中封裝事務
， ， ， ， ， ，
2020-10-06 09:25:46 +08:00
， ，
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-9 互動式事務和儲存過程之間的區別（ ）
#### 儲存過程的優點和缺點
儲存過程在關係型資料庫中已經存在了一段時間了， （ ） ， ：
- 每個資料庫廠商都有自己的儲存過程語言（ ， ， ） ， ， ，
- 與應用伺服器相，比在資料庫中執行的管理困難，除錯困難，版本控制和部署起來也更為尷尬，更難測試，更難和用於監控的指標收集系統相整合。
- 資料庫通常比應用伺服器對效能敏感的多， （ ， ）
但是這些問題都是可以克服的。現代的儲存過程實現放棄了PL/SQL， ： ， ，
**儲存過程與記憶體儲存**， ， ，
VoltDB還使用儲存過程進行復制： ， （ ， ） ， ，
#### 分割槽
順序執行所有事務使併發控制簡單多了，但資料庫的事務吞吐量被限制為單機單核的速度。只讀事務可以使用快照隔離在其它地方執行，但對於寫入吞吐量較高的應用，單執行緒事務處理器可能成為一個嚴重的瓶頸。
為了擴充套件到多個CPU核心和多個節點， （ ） ， ， ， ，
但是，對於需要訪問多個分割槽的任何事務，資料庫必須在觸及的所有分割槽之間協調事務。儲存過程需要跨越所有分割槽鎖定執行，以確保整個系統的可序列性。
由於跨分割槽事務具有額外的協調開銷，所以它們比單分割槽事務慢得多。 VoltDB報告的吞吐量大約是每秒1000個跨分割槽寫入， ，
事務是否可以是劃分至單個分割槽很大程度上取決於應用資料的結構。簡單的鍵值資料通常可以非常容易地進行分割槽，但是具有多個二級索引的資料可能需要大量的跨分割槽協調（參閱“[分片與次級索引](ch6.md#分片與次級索引)”）。
#### 序列執行小結
在特定約束條件下，真的序列執行事務，已經成為一種實現可序列化隔離等級的可行辦法。
- 每個事務都必須小而快，只要有一個緩慢的事務，就會拖慢所有事務處理。
- 僅限於活躍資料集可以放入記憶體的情況。很少訪問的資料可能會被移動到磁碟，但如果需要在單執行緒執行的事務中訪問，系統就會變得非常慢[^x]。
- 寫入吞吐量必須低到能在單個CPU核上處理， ， ，
- 跨分割槽事務是可能的，但是它們的使用程度有很大的限制。
[^x]: 如果事務需要訪問不在記憶體中的資料，最好的解決方案可能是中止事務，非同步地將資料提取到記憶體中，同時繼續處理其他事務，然後在資料載入完畢時重新啟動事務。這種方法被稱為**反快取（ ） ，
### 兩階段鎖定（ ）
大約30年來， ： （ ， ）
[^xi]: 有時也稱為**嚴格兩階段鎖定（ ） ，
> #### 2PL不是2PC
>
> 請注意， （ ） （ ） ，
之前我們看到鎖通常用於防止髒寫（參閱“[沒有髒寫](沒有髒寫)”一節）：如果兩個事務同時嘗試寫入同一個物件，則鎖可確保第二個寫入必須等到第一個寫入完成事務（中止或提交），然後才能繼續。
兩階段鎖定定類似，但使鎖的要求更強。只要沒有寫入，就允許多個事務同時讀取同一個物件。但物件只要有寫入（修改或刪除），就需要**獨佔訪問（ ）
- 如果事務A讀取了一個物件， ， （ ）
- 如果事務A寫入了一個物件， ， ）
在2PL中， ， ， ） ， ， ， ，
#### 實現兩階段鎖
2PL用於MySQL（ ） ，
讀與寫的阻塞是透過為資料庫中每個物件新增鎖來實現的。鎖可以處於**共享模式（ ） （ ）
- 若事務要讀取物件，則須先以共享模式獲取鎖。允許多個事務同時持有共享鎖。但如果另一個事務已經在物件上持有排它鎖，則這些事務必須等待。
- 若事務要寫入一個物件，它必須首先以獨佔模式獲取該鎖。沒有其他事務可以同時持有鎖（無論是共享模式還是獨佔模式），所以如果物件上存在任何鎖，該事務必須等待。
- 如果事務先讀取再寫入物件，則它可能會將其共享鎖升級為獨佔鎖。升級鎖的工作與直接獲得排他鎖相同。
- 事務獲得鎖之後，必須繼續持有鎖直到事務結束（提交或中止）。這就是“兩階段”這個名字的來源：第一階段（當事務正在執行時）獲取鎖，第二階段（在事務結束時）釋放所有的鎖。
由於使用了這麼多的鎖， ： ， （ ）
#### 兩階段鎖定的效能
兩階段鎖定的巨大缺點， ，
這一部分是由於獲取和釋放所有這些鎖的開銷，但更重要的是由於併發性的降低。按照設計，如果兩個併發事務試圖做任何可能導致競爭條件的事情，那麼必須等待另一個完成。
傳統的關係資料庫不限制事務的持續時間，因為它們是為等待人類輸入的互動式應用而設計的。因此，當一個事務需要等待另一個事務時，等待的時長並沒有限制。即使你保證所有的事務都很短，如果有多個事務想要訪問同一個物件，那麼可能會形成一個佇列，所以事務可能需要等待幾個其他事務才能完成。
因此， ， ， （
基於鎖實現的讀已提交隔離級別可能發生死鎖， ， （ ） ： ， ，
#### 謂詞鎖
在前面關於鎖的描述中，我們掩蓋了一個微妙而重要的細節。在“[導致寫入偏差的幻讀](#導致寫入偏差的幻讀)”中，我們討論了**幻讀（ ）
在會議室預訂的例子中，這意味著如果一個事務在某個時間視窗內搜尋了一個房間的現有預訂（見[例7-2]()），則另一個事務不能同時插入或更新同一時間視窗與同一房間的另一個預訂 （可以同時插入其他房間的預訂，或在不影響另一個預定的條件下預定同一房間的其他時間段）。
如何實現這一點？從概念上講，我們需要一個**謂詞鎖（ ）
```sql
SELECT * FROM bookings
WHERE room_id = 123 AND
end_time > '2018-01-01 12:00' AND
start_time < '2018-01-01 13:00';
```
謂詞鎖限制訪問，如下所示：
- 如果事務A想要讀取匹配某些條件的物件， `SELECT` 查詢中那樣，它必須獲取查詢條件上的**共享謂詞鎖（ ） ，
- 如果事務A想要插入， ， ，
這裡的關鍵思想是，謂詞鎖甚至適用於資料庫中尚不存在，但將來可能會新增的物件（幻象）。如果兩階段鎖定包含謂詞鎖，則資料庫將阻止所有形式的寫入偏差和其他競爭條件，因此其隔離實現了可序列化。
#### 索引範圍鎖
不幸的是謂詞鎖效能不佳：**如果活躍事務持有很多鎖，檢查匹配的鎖會非常耗時。**因此， （ （ ） ） ，
透過使謂詞匹配到一個更大的集合來簡化謂詞鎖是安全的。例如， ， ， （ ） ，
在房間預訂資料庫中，您可能會在`room_id`列上有一個索引，並且/或者在`start_time` 和 `end_time` 上有索引（否則前面的查詢在大型資料庫上的速度會非常慢）：
- 假設您的索引位於`room_id`上， ，
- 或者， ， ，
無論哪種方式，搜尋條件的近似值都附加到其中一個索引上。現在，如果另一個事務想要插入，更新或刪除同一個房間和/或重疊時間段的預訂，則它將不得不更新索引的相同部分。在這樣做的過程中，它會遇到共享鎖，它將被迫等到鎖被釋放。
這種方法能夠有效防止幻讀和寫入偏差。索引範圍鎖並不像謂詞鎖那樣精確（它們可能會鎖定更大範圍的物件，而不是維持可序列化所必需的範圍），但是由於它們的開銷較低，所以是一個很好的折衷。
如果沒有可以掛載間隙鎖的索引，資料庫可以退化到使用整個表上的共享鎖。這對效能不利，因為它會阻止所有其他事務寫入表格，但這是一個安全的回退位置。
### 序列化快照隔離（ ）
本章描繪了資料庫中併發控制的黯淡畫面。一方面， （ ） （ ） ， ， （ ， ， ） ？
也許不是：一個稱為**可序列化快照隔離（ ） ： ，
今天， （ ） （ ） ，
#### 悲觀與樂觀的併發控制
兩階段鎖是一種所謂的**悲觀併發控制機制（ ）
從某種意義上說，序列執行可以稱為悲觀到了極致：在事務持續期間，每個事務對整個資料庫（或資料庫的一個分割槽）具有排它鎖，作為對悲觀的補償，我們讓每筆事務執行得非常快，所以只需要短時間持有“鎖”。
相比之下，**序列化快照隔離**是一種**樂觀（ ）
樂觀併發控制是一個古老的想法【52】， （ ）
但是，如果有足夠的備用容量，並且事務之間的爭用不是太高，樂觀的併發控制技術往往比悲觀的要好。可交換的原子操作可以減少爭用：例如，如果多個事務同時要增加一個計數器，那麼應用增量的順序（只要計數器不在同一個事務中讀取）就無關緊要了，所以併發增量可以全部應用且無需衝突。
顧名思義， ， （ ） ， ，
#### 基於過時前提的決策
先前討論了快照隔離中的寫入偏差（參閱“[寫入偏差和幻像](#寫入偏差與幻讀)”）時，我們觀察到一個迴圈模式：事務從資料庫讀取一些資料，檢查查詢的結果，並根據它看到的結果決定採取一些操作（寫入資料庫）。但是，在快照隔離的情況下，原始查詢的結果在事務提交時可能不再是最新的，因為資料可能在同一時間被修改。
換句話說，事務基於一個**前提（ ）
當應用程式進行查詢時（例如，“當前有多少醫生正在值班？”），資料庫不知道應用邏輯如何使用該查詢結果。在這種情況下為了安全，資料庫需要假設任何對該結果集的變更都可能會使該事務中的寫入變得無效。 換而言之，事務中的查詢與寫入可能存在因果依賴。為了提供可序列化的隔離級別，如果事務在過時的前提下執行操作，資料庫必須能檢測到這種情況，並中止事務。
資料庫如何知道查詢結果是否可能已經改變？有兩種情況需要考慮：
- 檢測對舊MVCC物件版本的讀取（ ）
- 檢測影響先前讀取的寫入（讀之後發生寫入）
#### 檢測舊MVCC讀取
回想一下， （ ； ） ， ， `on_call = true` ， （ ） ， ， ，
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-10 檢測事務何時從MVCC快照讀取過時的值**
為了防止這種異常， ， ，
為什麼要等到提交？ ， ？ ， ， ， ， ， ，
#### 檢測影響之前讀取的寫入
2020-10-06 09:25:46 +08:00
第二種情況要考慮的是另一個事務在讀取資料之後修改資料。這種情況如[圖7-11](../img/fig7-11.png)所示。
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖7-11 在可序列化快照隔離中，檢測一個事務何時修改另一個事務的讀取。**
在兩階段鎖定的上下文中，我們討論了[索引範圍鎖]()（請參閱“[索引範圍鎖]()”），它允許資料庫鎖定與某個搜尋查詢匹配的所有行的訪問權，例如 `WHERE shift_id = 1234` 。可以在這裡使用類似的技術，
在[圖7-11]()中， ，
當事務寫入資料庫時，它必須在索引中查詢最近曾讀取受影響資料的其他事務。這個過程類似於在受影響的鍵範圍上獲取寫鎖，但鎖並不會阻塞事務指導其他讀事務完成，而是像警戒線一樣只是簡單通知其他事務：你們讀過的資料可能不是最新的啦。
在[圖7-11]()中， ， ， ， ， ， ，
#### 可序列化的快照隔離的效能
與往常一樣，許多工程細節會影響演算法的實際表現。例如一個權衡是跟蹤事務的讀取和寫入的**粒度（ ）
在某些情況下，事務可以讀取被另一個事務覆蓋的資訊：這取決於發生了什麼，有時可以證明執行結果無論如何都是可序列化的。 PostgreSQL使用這個理論來減少不必要的中止次數【11,41】。
與兩階段鎖定相比，可序列化快照隔離的最大優點是一個事務不需要阻塞等待另一個事務所持有的鎖。就像在快照隔離下一樣，寫不會阻塞讀，反之亦然。這種設計原則使得查詢延遲更可預測，變數更少。特別是，只讀查詢可以執行在一致的快照上，而不需要任何鎖定，這對於讀取繁重的工作負載非常有吸引力。
與序列執行相比， ： ， ，
中止率顯著影響SSI的整體表現。例如， ， （ ） ，
## 本章小結
事務是一個抽象層，允許應用程式假裝某些併發問題和某些型別的硬體和軟體故障不存在。各式各樣的錯誤被簡化為一種簡單情況：**事務中止（ ）
在本章中介紹了很多問題，事務有助於防止這些問題發生。並非所有應用都易受此類問題影響：具有非常簡單訪問模式的應用（例如每次讀寫單條記錄）可能無需事務管理。但是對於更復雜的訪問模式，事務可以大大減少需要考慮的潛在錯誤情景數量。
如果沒有事務處理，各種錯誤情況（程序崩潰，網路中斷，停電，磁碟已滿，意外併發等）意味著資料可能以各種方式變得不一致。例如，非規範化的資料可能很容易與源資料不同步。如果沒有事務處理，就很難推斷複雜的互動訪問可能對資料庫造成的影響。
本章深入討論了**併發控制**的話題。我們討論了幾個廣泛使用的隔離級別，特別是**讀已提交**，
***髒讀***
***髒寫***
***讀取偏差（不可重複讀）***
（ ）
***更新丟失***
***寫偏差***
***幻讀***
弱隔離級別可以防止其中一些異常情況，此外讓應用程式開發人員手動處理剩餘那些（例如，使用顯式鎖定）。只有可序列化的隔離才能防範所有這些問題。我們討論了實現可序列化事務的三種不同方法：
***字面意義上的序列執行***
， ， ，
***兩階段鎖定***
***可序列化快照隔離（ ）
## 參考文獻
1. Donald D. Chamberlin, Morton M. Astrahan, Michael W. Blasgen, et al.: “[A History and Evaluation of System R](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.348& rep=rep1& type=pdf),” *Communications of the ACM* , volume 24, number 10, pages 632–
[doi:10.1145/358769.358784 ](http://dx.doi.org/10.1145/358769.358784 )
2. Jim N. Gray, Raymond A. Lorie, Gianfranco R. Putzolu, and Irving L. Traiger: “[Granularity of Locks and Degrees of Consistency in a Shared Data Base](http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.92.8248& rep=rep1& type=pdf),” in *Modelling in Data Base Management Systems: Proceedings of the IFIP Working Conference on Modelling in Data Base Management Systems* , edited by G. M. Nijssen, pages 364– *Readings in Database Systems* , 4th edition, edited by Joseph M. Hellerstein and Michael Stonebraker, MIT Press, 2005. ISBN: 978-0-262-69314-1
3. Kapali P. Eswaran, Jim N. Gray, Raymond A. Lorie, and Irving L. Traiger: “[The Notions of Consistency and Predicate Locks in a Database System](http://research.microsoft.com/en-us/um/people/gray/papers/On%20the%20Notions%20of%20Consistency%20and%20Predicate%20Locks%20in%20a%20Database%20System%20CACM.pdf),” *Communications of the ACM* , volume 19, number 11, pages 624–
4. “[ACID Transactions Are Incredibly Helpful](http://web.archive.org/web/20150320053809/https://foundationdb.com/acid-claims),” FoundationDB, LLC, 2013.
5. John D. Cook: “[ACID Versus BASE for Database Transactions](http://www.johndcook.com/blog/2009/07/06/brewer-cap-theorem-base/),” *johndcook.com* , July 6, 2009.
6. Gavin Clarke: “[NoSQL's CAP Theorem Busters: We Don't Drop ACID](http://www.theregister.co.uk/2012/11/22/foundationdb_fear_of_cap_theorem/),” *theregister.co.uk* , November 22, 2012.
7. Theo Härder and Andreas Reuter: “[Principles of Transaction-Oriented Database Recovery](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.2812& rep=rep1& type=pdf),” *ACM Computing Surveys* , volume 15, number 4, pages 287– doi:10.1145/289.291 ](http://dx.doi.org/10.1145/289.291 )
8. Peter Bailis, Alan Fekete, Ali Ghodsi, et al.: “[HAT, not CAP: Towards Highly Available Transactions](http://www.bailis.org/papers/hat-hotos2013.pdf),”
at *14th USENIX Workshop on Hot Topics in Operating Systems* (HotOS), May 2013.
9. Armando Fox, Steven D. Gribble, Yatin Chawathe, et al.: “[Cluster-Based Scalable Network Services](http://www.cs.berkeley.edu/~brewer/cs262b/TACC.pdf),” at
*16th ACM Symposium on Operating Systems Principles* (SOSP), October 1997.
10. Philip A. Bernstein, Vassos Hadzilacos, and Nathan Goodman: [*Concurrency Control and Recovery in Database Systems* ](http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx ). Addison-Wesley, 1987. ISBN: 978-0-201-10715-9, available online at *research.microsoft.com* .
11. Alan Fekete, Dimitrios Liarokapis, Elizabeth O'Neil, et al.: “[Making Snapshot Isolation Serializable](https://www.cse.iitb.ac.in/infolab/Data/Courses/CS632/2009/Papers/p492-fekete.pdf),” *ACM Transactions on Database Systems* , volume 30, number 2, pages 492–
[doi:10.1145/1071610.1071615 ](http://dx.doi.org/10.1145/1071610.1071615 )
12. Mai Zheng, Joseph Tucek, Feng Qin, and Mark Lillibridge: “[Understanding the Robustness of SSDs Under Power Fault](https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf),” at *11th USENIX Conference on File and Storage Technologies* (FAST), February 2013.
13. Laurie Denness: “[SSDs: A Gift and a Curse](https://laur.ie/blog/2015/06/ssds-a-gift-and-a-curse/),” *laur.ie* , June 2, 2015.
14. Adam Surak: “[When Solid State Drives Are Not That Solid](https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/),” *blog.algolia.com* , June 15, 2015.
15. Thanumalayan Sankaranarayana Pillai, Vijay Chidambaram, Ramnatthan Alagappan, et al.: “[All File Systems Are Not Created Equal: On the Complexity of Crafting Crash-Consistent Applications](http://research.cs.wisc.edu/wind/Publications/alice-osdi14.pdf),” at *11th USENIX Symposium on Operating Systems Design and Implementation* (OSDI),
October 2014.
16. Chris Siebenmann: “[Unix's File Durability Problem](https://utcc.utoronto.ca/~cks/space/blog/unix/FileSyncProblem),” *utcc.utoronto.ca* , April 14, 2016.
17. Lakshmi N. Bairavasundaram, Garth R. Goodson, Bianca Schroeder, et al.: “[An Analysis of Data Corruption in the Storage Stack](http://research.cs.wisc.edu/adsl/Publications/corruption-fast08.pdf),” at *6th USENIX Conference on File and Storage Technologies* (FAST), February 2008.
18. Bianca Schroeder, Raghav Lagisetty, and Arif Merchant: “[Flash Reliability in Production: The Expected and the Unexpected](https://www.usenix.org/conference/fast16/technical-sessions/presentation/schroeder),” at *14th USENIX Conference on File and Storage Technologies* (FAST), February 2016.
19. Don Allison: “[SSD Storage – *blog.korelogic.com* , March 24, 2015.
20. Dave Scherer: “[Those Are Not Transactions (Cassandra 2.0)](http://web.archive.org/web/20150526065247/http://blog.foundationdb.com/those-are-not-transactions-cassandra-2-0),” *blog.foundationdb.com* , September 6, 2013.
21. Kyle Kingsbury: “[Call Me Maybe: Cassandra](http://aphyr.com/posts/294-call-me-maybe-cassandra/),” *aphyr.com* , September 24, 2013.
22. “[ACID Support in Aerospike](http://www.aerospike.com/docs/architecture/assets/AerospikeACIDSupport.pdf),” Aerospike, Inc., June 2014.
23. Martin Kleppmann: “[Hermitage: Testing the 'I' in ACID](http://martin.kleppmann.com/2014/11/25/hermitage-testing-the-i-in-acid.html),” *martin.kleppmann.com* , November 25, 2014.
24. Tristan D'Agosta: “[BTC Stolen from Poloniex](https://bitcointalk.org/index.php?topic=499580),” *bitcointalk.org* , March 4, 2014.
25. bitcointhief2: “[How I Stole Roughly 100 BTC from an Exchange and How I Could Have Stolen More!](http://www.reddit.com/r/Bitcoin/comments/1wtbiu/how_i_stole_roughly_100_btc_from_an_exchange_and/),” *reddit.com* , February 2, 2014.
26. Sudhir Jorwekar, Alan Fekete, Krithi Ramamritham, and S. Sudarshan: “[Automating the Detection of Snapshot Isolation Anomalies](http://www.vldb.org/conf/2007/papers/industrial/p1263-jorwekar.pdf),” at *33rd International Conference on Very Large Data Bases* (VLDB), September 2007.
27. Michael Melanson: “[Transactions: The Limits of Isolation](http://www.michaelmelanson.net/2014/03/20/transactions/),” *michaelmelanson.net* , March 20, 2014.
28. Hal Berenson, Philip A. Bernstein, Jim N. Gray, et al.: “[A Critique of ANSI SQL Isolation Levels](http://research.microsoft.com/pubs/69541/tr-95-51.pdf),”
at *ACM International Conference on Management of Data* (SIGMOD), May 1995.
29. Atul Adya: “[Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions](http://pmg.csail.mit.edu/papers/adya-phd.pdf),” PhD Thesis, Massachusetts Institute of Technology, March 1999.
30. Peter Bailis, Aaron Davidson, Alan Fekete, et al.: “[Highly Available Transactions: Virtues and Limitations (Extended Version)](http://arxiv.org/pdf/1302.0309.pdf),” at *40th International Conference on Very Large Data Bases* (VLDB), September 2014.
31. Bruce Momjian: “[MVCC Unmasked](http://momjian.us/main/presentations/internals.html#mvcc),” *momjian.us* , July 2014.
32. Annamalai Gurusami: “[Repeatable Read Isolation Level in InnoDB – *blogs.oracle.com* , January 15, 2013.
33. Nikita Prokopov: “[Unofficial Guide to Datomic Internals](http://tonsky.me/blog/unofficial-guide-to-datomic-internals/),” *tonsky.me* , May 6, 2014.
34. Baron Schwartz: “[Immutability, MVCC, and Garbage Collection](http://www.xaprb.com/blog/2013/12/28/immutability-mvcc-and-garbage-collection/),” *xaprb.com* , December 28, 2013.
35. J. Chris Anderson, Jan Lehnardt, and Noah Slater: *CouchDB: The Definitive Guide* . O'Reilly Media, 2010.
ISBN: 978-0-596-15589-6 Rikdeb Mukherjee: “[Isolation in DB2 (Repeatable Read, Read Stability, Cursor Stability, Uncommitted Read) with Examples](http://mframes.blogspot.co.uk/2013/07/isolation-in-cursor.html),” *mframes.blogspot.co.uk* , July 4, 2013.
36. Steve Hilker: “[Cursor Stability (CS) – *toadworld.com* , March 14, 2013.
37. Nate Wiger: “[An Atomic Rant](http://www.nateware.com/an-atomic-rant.html),” *nateware.com* , February 18, 2010.
38. Joel Jacobson: “[Riak 2.0: Data Types](http://blog.joeljacobson.com/riak-2-0-data-types/),” *blog.joeljacobson.com* , March 23, 2014.
39. Michael J. Cahill, Uwe Röhm, and Alan Fekete: “[Serializable Isolation for Snapshot Databases](http://www.cs.nyu.edu/courses/fall12/CSCI-GA.2434-001/p729-cahill.pdf),” at *ACM International Conference on Management of Data* (SIGMOD), June 2008. [doi:10.1145/1376616.1376690 ](http://dx.doi.org/10.1145/1376616.1376690 )
40. Dan R. K. Ports and Kevin Grittner: “[Serializable Snapshot Isolation in PostgreSQL](http://drkp.net/papers/ssi-vldb12.pdf),” at *38th International Conference on Very Large Databases* (VLDB), August 2012.
41. Tony Andrews: “[Enforcing Complex Constraints in Oracle](http://tonyandrews.blogspot.co.uk/2004/10/enforcing-complex-constraints-in.html),” *tonyandrews.blogspot.co.uk* , October 15, 2004.
42. Douglas B. Terry, Marvin M. Theimer, Karin Petersen, et al.: “[Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.141.7889& rep=rep1& type=pdf),” at *15th ACM Symposium on Operating Systems Principles* (SOSP), December 1995. [doi:10.1145/224056.224070 ](http://dx.doi.org/10.1145/224056.224070 )
43. Gary Fredericks: “[Postgres Serializability Bug](https://github.com/gfredericks/pg-serializability-bug),” *github.com* , September 2015.
44. Michael Stonebraker, Samuel Madden, Daniel J. Abadi, et al.: “[The End of an Architectural Era (It’ & rep=rep1& type=pdf),” at *33rd International Conference on Very Large Data Bases* (VLDB), September 2007.
45. John Hugg: “[H-Store/VoltDB Architecture vs. CEP Systems and Newer Streaming Architectures](https://www.youtube.com/watch?v=hD5M4a1UVz8),” at *Data @Scale Boston* , November 2014.
46. Robert Kallman, Hideaki Kimura, Jonathan Natkins, et al.: “[H-Store: A High-Performance, Distributed Main Memory Transaction Processing System](http://www.vldb.org/pvldb/1/1454211.pdf),” *Proceedings of the VLDB Endowment* , volume 1, number 2, pages 1496–
47. Rich Hickey: “[The Architecture of Datomic](http://www.infoq.com/articles/Architecture-Datomic),” *infoq.com* , November 2, 2012.
48. John Hugg: “[Debunking Myths About the VoltDB In-Memory Database](http://voltdb.com/blog/debunking-myths-about-voltdb-memory-database),” *voltdb.com* , May 12, 2014.
49. Joseph M. Hellerstein, Michael Stonebraker, and James Hamilton: “[Architecture of a Database System](http://db.cs.berkeley.edu/papers/fntdb07-architecture.pdf),”
*Foundations and Trends in Databases* , volume 1, number 2, pages 141–
[doi:10.1561/1900000002 ](http://dx.doi.org/10.1561/1900000002 )
50. Michael J. Cahill: “[Serializable Isolation for Snapshot Databases](http://cahill.net.au/wp-content/uploads/2010/02/cahill-thesis.pdf),” PhD Thesis, University of Sydney, July 2009.
51. D. Z. Badal: “[Correctness of Concurrency Control and Implications in Distributed Databases](http://ieeexplore.ieee.org/abstract/document/762563/),” at *3rd International IEEE Computer Software and Applications Conference* (COMPSAC), November 1979.
52. Rakesh Agrawal, Michael J. Carey, and Miron Livny: “[Concurrency Control Performance Modeling: Alternatives and Implications](http://www.eecs.berkeley.edu/~brewer/cs262/ConcControl.pdf),” *ACM Transactions on Database Systems* (TODS), volume 12, number 4, pages 609– doi:10.1145/32204.32220 ](http://dx.doi.org/10.1145/32204.32220 )
53. Dave Rosenthal: “[Databases at 14.4MHz](http://web.archive.org/web/20150427041746/http://blog.foundationdb.com/databases-at-14.4mhz),” *blog.foundationdb.com* , December 10, 2014.
------
| 上一章 | 目錄 | 下一章 |
| ---------------------- | ------------------------------- | ---------------------------------- |
| [第六章：分割槽 ](ch6.md ) | [設計資料密集型應用 ](README.md ) | [第八章：分散式系統的麻煩 ](ch8.md ) |
