OceanBase0的分布式事務(wù)講解

1、OceanBase 1.0的分布式事務(wù)數(shù)據(jù)庫的功能強大而繁雜，其中，“事務(wù)(Transaction) 是使用者不自覺就會用到的功 能。作為開發(fā)數(shù)據(jù)庫的工程師，我們是傾注了大量的精力和時間在事務(wù)這個功能上，并 且深知數(shù)據(jù)庫系統(tǒng)實現(xiàn)事務(wù)是付出了很大代價的。這代價不僅包括數(shù)據(jù)庫軟件開發(fā)的工 作，而且還包括數(shù)據(jù)庫運行過程中的代價。換句話說，在其他情況不變的時候，如果數(shù) 據(jù)庫放棄事務(wù)功能，能獲得更好的性能。在數(shù)據(jù)庫軟件剛出現(xiàn)時，并沒有事務(wù)這個功能， 但這種情況下，使用數(shù)據(jù)庫開發(fā)軟件很多時候無法保證數(shù)據(jù)的正確性和一致性，或者把 軟件搞得很復(fù)雜。所以，數(shù)據(jù)庫支持了事務(wù)功能，提供給使用者一個將許多數(shù)據(jù)庫的操

2、作打包在一起的功能，例如Atomic (原子性)，保證事務(wù)內(nèi)對數(shù)據(jù)的多次修改操作， 要么全部完成要么全部回滾。雖然付出了很多代價，但是用戶的應(yīng)用程序會因此大大簡 化。而且，用戶操作數(shù)據(jù)的流程越來越復(fù)雜，如果沒有事務(wù)特性的保證，使用者更加無 法確切知道數(shù)據(jù)在數(shù)據(jù)庫中是否保持正確。事務(wù)重要的4個特性ACID分別代表Atomicity (原子性)、Consistency (一致性)、 Isolation (隔離性)、Durability (持久性)。Atomicity (原子性)表示事務(wù)中的多個操作要么全部完成，要么全部沒有生效， 不會出現(xiàn)中間狀態(tài)；Consistency (一致性)表示事務(wù)操作不會

3、違反數(shù)據(jù)庫的一致性約束；Isolation (隔離性)表示多個并發(fā)事務(wù)之間不互相影響；Durability (持久性)表示事務(wù)一旦成功就不會丟失。數(shù)據(jù)庫系統(tǒng)有很多工程化方法來實現(xiàn)這些事務(wù)特性。其中，保證所有數(shù)據(jù)都存儲在持久 化設(shè)備中，就可以保證數(shù)據(jù)的Durability (持久性)。常用的持久化設(shè)備有磁盤和SSD， 這種設(shè)備保證在斷電的時候數(shù)據(jù)都不會丟失。事務(wù)的一致性是數(shù)據(jù)庫系統(tǒng)對于數(shù)據(jù)的約 束，常見的約束有數(shù)據(jù)庫的外鍵(Foreign Key)，數(shù)據(jù)庫系統(tǒng)保證事務(wù)執(zhí)行后這些約束 都不會被破環(huán)。這兩個功能點，在有原子性(Atomicity)和隔離性(Isolation)的基礎(chǔ) 上，系統(tǒng)實現(xiàn)起來

4、相對簡單。所以，在這篇文章中，我們只詳細描述原子性(Atomicity) 和隔離性(Isolation)兩個特性。原子性(Atomicity)原子性(Atomicity)是事務(wù)中最重要的特性，如果一切操作正常，保證原子性(Atomicity) 并不復(fù)雜。保證事務(wù)原子性(Atomicity)的復(fù)雜性多出自異常處理，例如宕機恢復(fù)、主 備切換等。以一個事務(wù)修改兩行數(shù)據(jù)為例，如果在修改完第一行之后、修改第二行之前 機器宕機了，如果沒有其他機制保證，待機器重新恢復(fù)服務(wù)，就只有第一行的修改存留 在系統(tǒng)中，違反了原子性(Atomicity)的要求。什么是原子性(Atomicity)實現(xiàn)原子性(Atomici

5、ty)的一種方法是將多個操作的生效時機放在一個原子操作上。計 算機系統(tǒng)在內(nèi)存操作上可以做到原子性的操作有給一個內(nèi)存變量賦值、CAS操作等。硬 盤的原子性操作和硬件本身有關(guān)，磁盤一般是一個512字節(jié)的塊寫入是原子的，SSD 一 般是4KB的塊寫入是原子的。用一個數(shù)據(jù)結(jié)構(gòu)的例子說明這種原子性實現(xiàn)機制。struct Balance int accountA;int accountB;);Balance * x = new HYPERLINK Balance();上面是C+的結(jié)構(gòu)體，表示了兩個賬戶A和B的余額。如果從A轉(zhuǎn)賬5元給B,對應(yīng)的C+代碼如下：x-accountA -= 5;x-account

6、B += 5;上面的代碼不是原子的，在兩條語句中間，如果另一個線程讀取accountA和accountB 的值，會發(fā)現(xiàn)轉(zhuǎn)賬操作只執(zhí)行了一半。如果使用下面的代碼，就可以保證無論什么時候 讀取，都不會讀到轉(zhuǎn)賬執(zhí)行了一半的情況：Balance * tmp = new Balance();tmp-accountA = x-accountA - 5;tmp-accountB = x-accountB + 5;x = tmp;操作的生效時間是x = tmp;語句，單一變量的賦值操作是原子的，保證了整個轉(zhuǎn)賬操作 是原子的。使用日志實現(xiàn)原子性(Atomicity)上面基于原子性操作的實現(xiàn)方法在數(shù)據(jù)結(jié)構(gòu)中很常用

7、，但是現(xiàn)在數(shù)據(jù)庫系統(tǒng)都是使用日 志技術(shù)(log)實現(xiàn)原子性(Atomicity),因為日志技術(shù)解決原子性的方法更靈活，還能 同時解決了事務(wù)的持久性(Durability)需求，而且比直接持久化數(shù)據(jù)有更好的性能，所 以幾乎所有的數(shù)據(jù)庫系統(tǒng)都采用了日志技術(shù)(log),甚至還包括文件系統(tǒng)、隊列系統(tǒng)等。使用10g時，先把整個事務(wù)的操作編碼成連續(xù)的日志信息，再把日志信息寫入持久化設(shè) 備，當(dāng)日志成功寫入后，就是保證事務(wù)原子性成功的時機。以上面的轉(zhuǎn)賬操作為例，編 碼出的日志信息如下：, 當(dāng)上面的信息持久化成功后，數(shù)據(jù)庫系統(tǒng)再會修改兩個帳戶的數(shù)據(jù)，而且?guī)魯?shù)據(jù)本身 持久化到硬盤的時機可以延后到任意時刻，因為即

8、使數(shù)據(jù)沒有持久化前就宕機了，系統(tǒng) 重啟后還是可以從log中將上面的轉(zhuǎn)賬操作恢復(fù)出來。所以，轉(zhuǎn)賬事務(wù)的原子性（Atomicity）成功的時機就是log持久化成功的時間點。對于一次數(shù)據(jù)庫事務(wù)，如果只有這么一條日志并且長度小于硬盤的一次原子寫入操作， 例如磁盤的512字節(jié)，那么原子性很容易保證，這次寫入成功了，事務(wù)就成功了；如 果寫入失敗了，那么事務(wù)就沒有完成。如果事務(wù)只需要寫一條日志但是日志長度大于一 次原子寫入的大小，就需要附加的手段來保證log寫入的原子性。一種常見方法是用長 度加上校驗值（checksum），在這條日志的頭部包含整條日志的長度和校驗值（checksum）。從日志文件里讀取日志

9、時，首先讀到日志頭部，獲取日志長度和校驗值 （checksum），然后根據(jù)日志長度將整條日志內(nèi)容讀取出，并且和校驗值（checksum）比對，如果一致，那么既認為日志時完整的，對應(yīng)的事務(wù)也是成功提交的；如果校驗值 （checksum）不一致，那么認為事務(wù)失敗。如果事務(wù)的信息會分成多次寫入硬盤，即事務(wù)包含多條日志。在這多條日志中，每條日志的處理方法都與前面描述的一樣，但是事 務(wù)最終是否保證了原子性需要依賴這多條日志都持久化成功，所以數(shù)據(jù)庫系統(tǒng)會在所有 日志都持久化成功后再寫最后一條確認日志，只有最后一條日志寫成功了，事務(wù)才算成 功，否則，事務(wù)還是會被回滾。分布式事務(wù)原理上面這種方法適用的前提是事

10、務(wù)的所有日志都在一個日志序列中。當(dāng)數(shù)據(jù)庫是由多臺機 器組成時，每臺機器都會有自己的日志，一個事務(wù)如果涉及多臺機器，那么就會將日志 寫到多臺機器上，我們稱這種事務(wù)為分布式事務(wù)。理論上，即使事務(wù)的日志分散在多臺 機器上，事務(wù)提交時，如果所有機器都持久化日志成功，那么事務(wù)就算提交成功，并且 可以保證原子性（Atomicity）。比較麻煩的是，如果機器重啟，從日志中恢復(fù)事務(wù)狀態(tài)1 時，同樣需要詢問所有機器來確認是否事務(wù)的所有日志都持久化成功了。但是實際的系 統(tǒng)中無法承受每次需要恢復(fù)事務(wù)狀態(tài)時，都要對每個事務(wù)進行多機通訊。所以，分布式 事務(wù)采用兩階段提交的方式，對于單機寫日志的流程進行擴展，來適應(yīng)分布式

11、事務(wù)。左側(cè) 是協(xié)調(diào)者狀態(tài)機，右側(cè)（b）是參與者狀態(tài)機。協(xié)調(diào)者是驅(qū)動整個事務(wù)提交流程 的主體，實現(xiàn)中它可以在任意機器上，當(dāng)然也可以和其中一個參與者在一臺機器上。參 與者是真正做事務(wù)操作的執(zhí)行者。協(xié)調(diào)者首先通知所有的參與者持久化（圖中的prepare 命令），當(dāng)參與者將事務(wù)的日志持久化成功后會回復(fù)prepare ok，當(dāng)所有參與者都回復(fù) prepare ok后，意味著整個事務(wù)完成了，然后協(xié)調(diào)者會寫下事務(wù)commit的日志，并且 發(fā)送commit給所有參與者，如果其中任何一個參與者返回失?。碼bort ok），那么 協(xié)調(diào)者就會認為事務(wù)是失敗的，記下事務(wù)回滾的日志，并且發(fā)送abort給所有參與者。在

12、這個流程下，分布式事務(wù)提交的延遲是2次寫日志（參與者寫prepare日志+協(xié)調(diào) 者寫commit日志）的延遲和2次通訊（協(xié)調(diào)者通知參與者prepare +協(xié)調(diào)者通知參 與者commit）的延遲。OceanBase對于分布式事務(wù)的優(yōu)化OceanBase的兩階段提交協(xié)議對這個流程做了優(yōu)化，事務(wù)是否提交本質(zhì)上取決于是否事 務(wù)的所有日志都持久化到硬盤中，不依賴協(xié)調(diào)者的日志，日志全部持久化的狀態(tài)也是確 定的。所以，OceanBase的兩階段提交流程取消了協(xié)調(diào)者寫日志的過程，將協(xié)調(diào)者變成 一個無持久化狀態(tài)的狀態(tài)機，狀態(tài)機如下：看起來很復(fù)雜，是因為實際的工程項目中還需要處理各種異常情況，還有各種優(yōu)化。參 與

13、者狀態(tài)機如下：SbOiLie5pDCrie abcrl piDpsnanfqoDnM p呼;SbOiLie5pDCrie abcrl piDpsnanfqoDnM p呼;tgEDinniVrMporE* Emmr ok 曲bUm軍iM鴕。配H Ck儂簞 m* arsfEre MK/wn在上面的協(xié)調(diào)者和參與者的狀態(tài)機中，與經(jīng)典狀態(tài)機除了多了很多異常和優(yōu)化的處理， 還有一個最大的不同是多了一個CLEAR階段，理論上協(xié)調(diào)者完成commit操作后整個 事務(wù)流程就結(jié)束了，但是在實際實現(xiàn)中，雖然事務(wù)狀態(tài)確定了，但是協(xié)調(diào)者和參與者之 間還可能因為網(wǎng)絡(luò)丟包或者機器異常等導(dǎo)致信息傳輸不確定的狀況，需要互相查詢狀

14、態(tài) 或者重試，這時CLEAR狀態(tài)的意義就是保證所有狀態(tài)機都達到確定狀態(tài)了，才對狀態(tài) 機對應(yīng)的數(shù)據(jù)結(jié)構(gòu)進行清理。OceanBase對于協(xié)調(diào)者的優(yōu)化 前文描述過，在單機事務(wù)的場景中，如果一個事務(wù)需要寫多條日志，在確認所有日志寫 成功后，會寫下最后一條日志表示整個事務(wù)確認完成提交。這最后一條日志的信息是可 以和正常事務(wù)日志的最后一條合并在一起的。但是在分布式事務(wù)中，兩階段提交的協(xié)調(diào) 者在確認所有參與者上的日志都寫成功后寫下的commit日志是無法從工程上與任何 參與者的日志合并在一起的。但是，事務(wù)是否提交本身是在所有參與者的日志都成功持 久化的時候就確定了的。所以，OceanBase做的一個重大優(yōu)化

15、就是省去協(xié)調(diào)者的commit 日志。調(diào)者接收到所有參與者的prepare ok消息后，不寫本地的commit日志，直接 給所有參與者發(fā)送commit請求。當(dāng)參與者收到commit請求后會寫下commit日志， 這條日志是原始的協(xié)議中也會有的操作。在這個模式下，極端的情況是當(dāng)所有參與者都成功寫下prepare日志，但是在協(xié)調(diào)者發(fā) 送commit消息之前，系統(tǒng)出現(xiàn)宕機，如何恢復(fù)這個本應(yīng)該成功的事務(wù)。宕機重啟后， 參與者發(fā)現(xiàn)事務(wù)處于PREPARED狀態(tài)，則會詢問協(xié)調(diào)者事務(wù)的狀態(tài)。因為協(xié)調(diào)者也是 宕機重啟了并且協(xié)調(diào)者不持久化任何信息，所以并沒有任何協(xié)調(diào)者的狀態(tài)。但是協(xié)調(diào)者 會在收到參與者的詢問請求后，

16、構(gòu)建出協(xié)調(diào)者狀態(tài)機，并詢問其他所有參與者的事務(wù)狀 態(tài)，當(dāng)發(fā)現(xiàn)所有參與者都是PREPARED狀態(tài)，就能確定這個事務(wù)是最終成功commit 的，然后會給所有參與者發(fā)送commit請求，狀態(tài)機就正常運轉(zhuǎn)下去了。OceanBase對于單機多partition事務(wù)的優(yōu)化OceanBase的部署是以partition為單位，一臺機器上的多個partition分別有各自獨立 的paxos group，所以即使是一臺機器上的事務(wù)，如果涉及多個partition，也是分布式 事務(wù)。多機的分布式事務(wù)應(yīng)答用戶的時機是在所有參與者應(yīng)答協(xié)調(diào)者commit ok之后， OceanBase使用了 MVCC機制進行并發(fā)控制，

17、參與者在事務(wù)提交時需要進行修改全局 版本號的操作(下面章節(jié)會描述)，所以參與者在收到commit請求時，可以先修改全 局版本號并且回復(fù)協(xié)調(diào)者，再持久化commit日志。但是commit操作在網(wǎng)絡(luò)上的 round trip時間還是需要消耗的。對于單機多partition事務(wù)，多個partition需要修改的全局版本號其實是一個，所以協(xié) 調(diào)者在收到所有參與者回復(fù)的prepare ok請求后，認為事務(wù)可以提交時，就可以幫助 參與者修改全局版本號，因為單機多partition事務(wù)的協(xié)調(diào)者也一定是在這同一臺機器 上。所以，協(xié)調(diào)者在收到參與者prepare ok時即可應(yīng)答用戶事務(wù)提交成功，減少了一 次 c

18、ommit round trip 的消耗。隔離性(Isolation)數(shù)據(jù)庫系統(tǒng)不能只服務(wù)一個用戶，需要允許多個用戶同時訪問數(shù)據(jù)。所以在保證事務(wù)原 子性的同時，還需要保證當(dāng)多用戶同時訪問時數(shù)據(jù)的正確性，這是非常挑戰(zhàn)的事情。數(shù) 據(jù)庫使用一種并發(fā)控制技術(shù)(Concurrency Control)來控制和協(xié)調(diào)同時在數(shù)據(jù)庫系統(tǒng)中 操作的事務(wù)。常見的并發(fā)控制算法有Lock-based Concurrency Control和Multiple Version Concurrency Control 0Lock-based Concurrency Control 這種方法類似于數(shù)據(jù)結(jié)構(gòu)設(shè)計中常用的鎖機制。數(shù)

19、據(jù)庫系統(tǒng)對用戶在事務(wù)過程中操作的 每一行數(shù)據(jù)進行加鎖操作，如果是讀操作就加上讀鎖，如果是寫操作就加上寫鎖。如果 兩個不同的事務(wù)試圖修改同一行數(shù)據(jù)，第一個對這個數(shù)據(jù)加上寫鎖的事務(wù)是正常執(zhí)行。 第二個事務(wù)為了保證數(shù)據(jù)的正確性，會等待第一個事務(wù)執(zhí)行。待第一個事務(wù)執(zhí)行結(jié)束后 釋放行鎖，第二個事務(wù)才恢復(fù)繼續(xù)執(zhí)行。A 100B 200還以轉(zhuǎn)賬操作為例，上面標(biāo)示A B兩個帳戶分別有100塊和200塊。如果事務(wù)1執(zhí) 行從A帳戶轉(zhuǎn)10塊到B帳戶的操作，那么在事務(wù)一執(zhí)行過程中，A B兩行數(shù)據(jù)都會 被加上寫鎖。如果第二個事務(wù)執(zhí)行另一次轉(zhuǎn)賬操作，從A帳戶轉(zhuǎn)50塊到B帳戶，那 么給行A加寫鎖的時候會加不上，事務(wù)二會一直

20、等待直到鎖加上。在上面的場景中，如果在事務(wù)一、二執(zhí)行的過程中，另一個事務(wù)三查詢AB兩個帳戶 的信息，目的是統(tǒng)計AB兩個帳戶的余額總和。那么需要讀取AB兩行，讀取之前需 要先加讀鎖，但是在事務(wù)一、二操作時，A B兩行都是持有寫鎖的，所以事務(wù)三需要等 待事務(wù)一、二都結(jié)束了才能進行操作。Multiple Version Concurrency Control在上面的例子中，一個讀取帳戶余額總和的操作無論事務(wù)一、二是否執(zhí)行完，其結(jié)果都 是確定的，這里的結(jié)果一定是300塊。實際系統(tǒng)中，并行執(zhí)行的事務(wù)是可以由數(shù)據(jù)庫 系統(tǒng)來安排其先后順序的，所以出現(xiàn)了 Multiple Version Concurrenc

21、y Control(MVCC)的 方法，對于數(shù)據(jù)庫的數(shù)據(jù)的每次修改都留存版本，這樣讀取操作可以不受修改操作的影 響直接在歷史版本上執(zhí)行。繼續(xù)上面事務(wù)三的例子。在MVCC方法下，每一個事務(wù)都會有一個提交版本，假定事 務(wù)一是100，事務(wù)二是101。那么修改都完成后，數(shù)據(jù)庫中的數(shù)據(jù)狀態(tài)如下：101: A 40 - 100: A 90- 98: A 100101: B 260 - 100: B 210 - 98: B 200數(shù)據(jù)的初始版本是98。每次數(shù)據(jù)修改的記錄都會被串聯(lián)起來。另有一個全局變量Global Committed Version(GCV)標(biāo)示全局最后提交的版本號。在事務(wù)一執(zhí)行之前GCV是98， 事務(wù)一提交之后GCV變成10