分布式數(shù)據(jù)庫系統(tǒng)面臨的問題和挑戰(zhàn)

作者：李海翔 2021-10-26 00:33:00
運維
數(shù)據(jù)庫運維
分布式 分布式數(shù)據(jù)庫系統(tǒng)在邏輯上可以看作一個完整的系統(tǒng)，用戶如同在使用單機數(shù)據(jù)庫系統(tǒng)；但是，從物理角度看，其為一個網(wǎng)絡(luò)系統(tǒng)，包含若干個物理意義上的分散的節(jié)點，而節(jié)點之間通過網(wǎng)絡(luò)進行連接，通過網(wǎng)絡(luò)協(xié)議進行數(shù)據(jù)交換。

成都創(chuàng)新互聯(lián)專注于鄞州網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供鄞州營銷型網(wǎng)站建設(shè)，鄞州網(wǎng)站制作、鄞州網(wǎng)頁設(shè)計、鄞州網(wǎng)站官網(wǎng)定制、微信小程序定制開發(fā)服務(wù)，打造鄞州網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供鄞州網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

分布式數(shù)據(jù)庫系統(tǒng)在邏輯上可以看作一個完整的系統(tǒng)，用戶如同在使用單機數(shù)據(jù)庫系統(tǒng);但是，從物理角度看，其為一個網(wǎng)絡(luò)系統(tǒng)，包含若干個物理意義上的分散的節(jié)點，而節(jié)點之間通過網(wǎng)絡(luò)進行連接，通過網(wǎng)絡(luò)協(xié)議進行數(shù)據(jù)交換。

分布式數(shù)據(jù)系統(tǒng)需要應(yīng)對網(wǎng)絡(luò)故障、節(jié)點故障。網(wǎng)絡(luò)故障會直接導(dǎo)致分區(qū)事件(CAP

原理中的P，即網(wǎng)絡(luò)發(fā)生故障使得網(wǎng)絡(luò)被分為多個子部分)發(fā)生，系統(tǒng)的可用性會受到影響;節(jié)點故障可能會引發(fā)單點故障，也就是在數(shù)據(jù)為單副本的情況下節(jié)點故障會直接導(dǎo)致部分數(shù)據(jù)不能被訪問。為避免單點故障，數(shù)據(jù)需要有多個副本，從而使系統(tǒng)的可用性得到較大提高。節(jié)點故障也可能引發(fā)分區(qū)事件。

除了上述問題外，分布式數(shù)據(jù)庫系統(tǒng)還可能帶來不一致問題。比如舊讀(stale read)問題，即讀操作發(fā)生于數(shù)據(jù)項更新之后，此時本應(yīng)該讀取到的是該數(shù)據(jù)項的最新值，但是卻讀到了舊值。產(chǎn)生該問題的原因是，分布式數(shù)據(jù)庫系統(tǒng)沒有一個統(tǒng)一的時鐘，這會導(dǎo)致反序讀取數(shù)據(jù)的情況出現(xiàn)。這種情況在單機系統(tǒng)中是不存在的。這里所說的不一致現(xiàn)象，以及與其類似的不一致性現(xiàn)象，在這里稱為數(shù)據(jù)讀取序不符合數(shù)據(jù)生成序，簡稱分布式不一致。

為了解決分布式不一致問題，諸多學(xué)者經(jīng)過大量的研究提出了多種分布式一致性的概念，如線性一致性(linearizability)、順序一致性(sequential consistency)、因果一致性(causal consistency)，以及Google Spanner的外部一致性(external consistency)等。

分布式數(shù)據(jù)庫系統(tǒng)需要解決分布式不一致問題，使觀察者能讀取到滿足一致性的數(shù)據(jù)，以確保數(shù)據(jù)之間的邏輯一直是有序的。本節(jié)后續(xù)內(nèi)容將針對這個問題展開討論：首先討論通用的分布式系統(tǒng)所面臨的問題，然后討論因數(shù)據(jù)異常引發(fā)的一致性問題，最后討論與分布式數(shù)據(jù)庫相關(guān)的其他問題。

分布式數(shù)據(jù)庫系統(tǒng)面臨的問題

單機數(shù)據(jù)庫系統(tǒng)為了應(yīng)對事務(wù)故障和對事務(wù)進行管理，專門提供了UNDO日志、回滾段等措施，目的就是實現(xiàn)事務(wù)的回滾;為了應(yīng)對系統(tǒng)故障，采用了WAL技術(shù)做日志，目的是先于事務(wù)進行持久化存儲;為了應(yīng)對介質(zhì)故障，專門提供了邏輯備份、物理備份等多種手段，目的是在數(shù)據(jù)層面、日志層面和物理數(shù)據(jù)塊層面實現(xiàn)數(shù)據(jù)冗余存儲。

相對于單機數(shù)據(jù)庫系統(tǒng)而言，除了上述問題外，分布式數(shù)據(jù)庫系統(tǒng)面臨著更多的挑戰(zhàn)。這些挑戰(zhàn)源自分布式數(shù)據(jù)庫系統(tǒng)的架構(gòu)，其和單機數(shù)據(jù)庫系統(tǒng)不同，因而在技術(shù)層面上存在差異。

1. 架構(gòu)異常

架構(gòu)異常是指用戶因數(shù)據(jù)庫的架構(gòu)而產(chǎn)生的數(shù)據(jù)異常，嚴格地講，這不屬于數(shù)據(jù)庫系統(tǒng)領(lǐng)域的數(shù)據(jù)異常。從用戶的角度看，事務(wù)一直在執(zhí)行中，但是讀寫數(shù)據(jù)時產(chǎn)生了類似前述的順序問題、數(shù)據(jù)異常等，本書統(tǒng)稱這種異常為架構(gòu)異常。架構(gòu)異常和分布式架構(gòu)相關(guān)，分布式架構(gòu)包括一主一備架構(gòu)、一主多備架構(gòu)、多主多備架構(gòu)等。在分布式架構(gòu)中，前端可能都有一個類似代理(proxy)的組件面向用戶提供透明的高可用服務(wù)，代理組件屏蔽了后端多個單機系統(tǒng)故障，所以在用戶看來，分布式架構(gòu)上的所有操作都是在一個事務(wù)中進行的，而因架構(gòu)引發(fā)的異常也是數(shù)據(jù)異常。

如下討論一種已知的架構(gòu)異常，該架構(gòu)異常會導(dǎo)致讀取到的數(shù)據(jù)不一致。我們以MySQL的主備架構(gòu)Master-Slave為例進行說明(其他數(shù)據(jù)庫的同類架構(gòu)存在類似隱患)。此類不一致是這樣產(chǎn)生的。MySQL支持Master-Slave架構(gòu)。假設(shè)在Master上執(zhí)行事務(wù)T，此時先按條件“score>90”進行查詢，發(fā)現(xiàn)沒有符合條件的事務(wù)，故成功寫入Binlog File的數(shù)據(jù)，假設(shè)其為95(事務(wù)提交)，然后在復(fù)制的過程中宕機，導(dǎo)致復(fù)制失敗。Master重啟時，會直接對數(shù)據(jù)95進行提交操作，之后Master會將數(shù)據(jù)95異步復(fù)制到Slave。但是，此時原來的Slave可能已經(jīng)切換為主機并開始提供服務(wù)，比如新事務(wù)寫入數(shù)據(jù)98，而原來Master上的95沒有被復(fù)制到新Master上，這就會造成兩臺MySQL主機的數(shù)據(jù)不一致。

如果在主備MySQL服務(wù)前端還有一個代理服務(wù)器，對用戶而言，這會屏蔽后臺的主備服務(wù)，用戶就會認為“只有一個MySQL”提供服務(wù)，因此數(shù)據(jù)95丟失對用戶而言是不可接受的。

還有一種情況，如果代理服務(wù)器在原始的Master宕機后沒有結(jié)束用戶的事務(wù)T，而是把事務(wù)T連接到原備機，并將原備機變更為新Master。這時，對于新Master而言，會發(fā)生兩個事務(wù)，一個新事務(wù)T1在一定WHERE條件下寫入98，另一個是繼續(xù)執(zhí)行的原事務(wù)T，若此時原事務(wù)T再次發(fā)起讀操作(邏輯上還在同一個事務(wù)內(nèi))，就會發(fā)現(xiàn)自己寫過的數(shù)據(jù)95消失了，這對于用戶而言是不可接受的。從分布式一致性的角度看，這違背了“Read-your-writes”(讀你所寫)原則。從事務(wù)的角度看，可能出現(xiàn)“幻讀”，即再次按條件“score>90”查詢，額外讀到事務(wù)T1寫入的98，所以出現(xiàn)了事務(wù)的數(shù)據(jù)異常。

與上述相似，官方對MySQL上出現(xiàn)Master-Slave之間數(shù)據(jù)不一致的情況，也進行了描述。

如下圖1所示，如果把數(shù)據(jù)擴展到多副本，把讀操作擴展到允許從任何副本讀取數(shù)據(jù)，把寫操作擴展到允許向任何副本寫入數(shù)據(jù)，如果是去中心化的架構(gòu)(即沒有單一的全局事務(wù)管理機制)且發(fā)生了網(wǎng)絡(luò)分區(qū)或延，則在事務(wù)一致性視角、分布式一致性視角下去觀察數(shù)據(jù)的讀或?qū)懖僮?，會發(fā)現(xiàn)存在更為復(fù)雜的問題。

圖1 多副本異常圖

Distributed algorithms and protocols討論了一種在多副本情況下，副本間數(shù)據(jù)同步與數(shù)據(jù)可見性的異常情況，其所用的示例如圖1所示：足球世界杯比賽結(jié)果出爐，比賽結(jié)果經(jīng)過Leader節(jié)點記錄到數(shù)據(jù)庫。事實結(jié)果是德國贏得了世界杯冠軍。但是，數(shù)據(jù)從Leader節(jié)點同步到兩個不同的Follower節(jié)點的時候，Alice和Bob同處一室，從不同的Follower節(jié)點上查詢世界杯的比賽消息，結(jié)果Alice得知德國奪冠，而Bob卻得到比賽還沒有結(jié)束的消息。二人得到了不同的消息，產(chǎn)生了不一致。這也是分布式架構(gòu)下因多副本支持Follower讀帶來的不一致的問題。

2. 分布式一致性和事務(wù)一致性

為了幫助大家充分理解分布式系統(tǒng)中存在的問題，我們不妨做一個類比。

若是世界上只有一個人，那么這個世界的關(guān)系是非常簡單的，但是一旦有多個人，“社會”就會形成。其中，社會關(guān)系指的就是人與人之間建立的關(guān)系，這種關(guān)系會隨著人的數(shù)量的增加而不斷復(fù)雜化。這種復(fù)雜的社會關(guān)系與數(shù)據(jù)庫結(jié)合到一起得到的就是分布式數(shù)據(jù)庫系統(tǒng)，社會中的人就相當(dāng)于分布式數(shù)據(jù)庫系統(tǒng)中的一個物理節(jié)點或者一個物理節(jié)點中的一份數(shù)據(jù)副本。圖2以一個NewSQL系統(tǒng)的架構(gòu)為例描述分布式數(shù)據(jù)庫中存在的多個問題。

因為分布式數(shù)據(jù)庫要存儲海量數(shù)據(jù)，要對數(shù)據(jù)分而治之，所以引入了數(shù)據(jù)分片的概念。從邏輯的角度看，每個節(jié)點的數(shù)據(jù)都是一個或多個數(shù)據(jù)分片，但是數(shù)據(jù)庫要滿足“高可用、高可靠”以及在線實時提供服務(wù)的特性，因此每個數(shù)據(jù)分片就有了多個副本。數(shù)據(jù)多副本使得分布式數(shù)據(jù)庫的“一致性”問題變得更為復(fù)雜。

我們從讀和寫兩個不同的角度來感性了解一下分布式數(shù)據(jù)庫中存在哪些不一致的問題。

首先，圖2所示的分布式數(shù)據(jù)庫系統(tǒng)存在4個數(shù)據(jù)分片—A、B、C、D，每個分片又存在3個副本，且每個分片的3個副本中有一個是Leader，另外兩個是Follower(比如Raft分布式協(xié)議中的Leader和Follower)。

圖2　分布式數(shù)據(jù)庫的一致性問題關(guān)系圖

其次，對于寫操作，圖2所示有如下兩種情況。

1)寫單個數(shù)據(jù)分片—W1：在這種情況下，一個事務(wù)不能針對多個節(jié)點進行操作，所以這樣的事務(wù)是典型的單節(jié)點事務(wù)，類似于單機數(shù)據(jù)庫系統(tǒng)中的事務(wù)。寫單個數(shù)據(jù)分片可以由單個節(jié)點上的事務(wù)處理機制來確保其具有ACID特性。為了實現(xiàn)寫單個數(shù)據(jù)分片的數(shù)據(jù)一致性，可只使用數(shù)據(jù)庫系統(tǒng)中的并發(fā)訪問控制技術(shù)，如2PL(Two-phase Locking，兩階段封鎖)、TO(Timestamp Ordering，時間戳排序)、MVCC(Multi Version Concurrency Control，多版本并發(fā)控制)等。

2)寫多個數(shù)據(jù)分片—W2：通過一個事務(wù)寫多個數(shù)據(jù)分片，這就是典型的分布式事務(wù)了，此時需要借助諸如分布式并發(fā)訪問控制等技術(shù)來保證分布式事務(wù)的一致性，需要借助2PC(Two-phase Commit，兩階段提交)技術(shù)保證跨節(jié)點寫操作的原子性。另外，如果需要實現(xiàn)強一致性(詳見5.6節(jié))，還需要考慮在分布式數(shù)據(jù)庫范圍內(nèi)，確保ACID中的C和CAP中的C的強一致性相結(jié)合(即可串行化和線性一致性、順序一致性的結(jié)合)。諸如Spanner等很多數(shù)據(jù)庫系統(tǒng)，都使用線性一致性、SS2PL(Strong Strict 2PL)技術(shù)和2PC技術(shù)來實現(xiàn)分布式寫事務(wù)的強一致性。CockroachDB、Percolator等分布式數(shù)據(jù)庫則使用了OCC類的技術(shù)做并發(fā)訪問控制來確保事務(wù)一致性(可串行化)，并使用2PC來確保分布式提交的原子性，但它們沒有實現(xiàn)強一致性，其中CockroachDB只實現(xiàn)了順序可串行化。保證分布式事務(wù)一致性的技術(shù)還有很多，第4章將詳細討論。

對于寫多個數(shù)據(jù)分片的情況來說，因為在每個數(shù)據(jù)分片內(nèi)部存在多個副本，所以如何保證副本之間的數(shù)據(jù)一致性，也是一個典型的分布式系統(tǒng)一致性問題(第2章會詳細討論分布式系統(tǒng)的一致性問題，第3章會詳細討論多副本在共識算法加持下的一致性問題)，著名的Paxos、Raft等協(xié)議就是用來解決分布式系統(tǒng)的多副本共識問題的。此種情況下，通常沒有寫操作會發(fā)生在圖1-6所示的A的Leader和B的Follower這樣的組合中。

如果一個系統(tǒng)支持多寫操作，則多寫會同時發(fā)生在多個數(shù)據(jù)分片的Leader上。

對于讀操作，圖2所示也有如下兩種情況。

1)讀單個數(shù)據(jù)分片—R1：如果一個事務(wù)只涉及單個節(jié)點，則這個事務(wù)讀取操作的數(shù)據(jù)一致性一定能保障(通過節(jié)點上的事務(wù)機制來保障)。如果涉及多個節(jié)點，那么此時的R1就會被分為R11和R12兩種讀取方式。

R11方式用于讀取Leader：因為進行寫操作時首先寫的是Leader，所以如果寫事務(wù)已經(jīng)提交，那么一定能夠保證R11讀取的數(shù)據(jù)是已經(jīng)提交了的最新數(shù)據(jù)。如果寫事務(wù)沒有提交，那么此時Leader上若是采用MVCC技術(shù)，則R11讀取的會是一個舊數(shù)據(jù)，這樣的讀取機制可以保證R11讀數(shù)據(jù)的一致性;Leader上若是采用封鎖并發(fā)訪問控制機制，則讀操作會被阻塞直至寫事務(wù)提交，因而在這種機制下R11讀取的是提交后的值，從而保證讀數(shù)據(jù)的一致性，換句話說，這種情況下，保證數(shù)據(jù)一致性依賴的是單節(jié)點上的事務(wù)并發(fā)訪問控制機制。同時，這也意味著一個分布式數(shù)據(jù)庫系統(tǒng)中單個節(jié)點的事務(wù)處理機制應(yīng)該具備完備的事務(wù)處理功能。

R12的方式用于讀取Follower：讀取Follower時又分為如下兩種情況。

在一個分片內(nèi)部，主副本和從副本(即Leader和Follower)之間是強同步的(Leader向所有Follower同步數(shù)據(jù)并在應(yīng)用成功之后向客戶端返回結(jié)果)。這種情況下不管是讀Leader還是讀Follower，數(shù)據(jù)一定是完全相同的，讀取的數(shù)據(jù)一定是一致的。

Leader和Follower之間是弱同步的(Leader沒有等所有Follower同步數(shù)據(jù)并應(yīng)用成功之后，就向客戶端返回結(jié)果)，如采用多數(shù)派協(xié)議就可實現(xiàn)弱同步。此時Leader和Follower之間會存在寫數(shù)據(jù)延時，即從Follower上讀取到的可能是一個舊數(shù)據(jù)，但是因為事務(wù)的讀操作只涉及一個節(jié)點，所以也不會產(chǎn)生讀操作數(shù)據(jù)不一致的問題。這就如同MySQL的主備復(fù)制系統(tǒng)中備機可以提供只讀服務(wù)一樣。

2)讀多個數(shù)據(jù)分片—R2：注意這種情況下的讀操作會跨多個分片/節(jié)點，如果事務(wù)處理機制不妥當(dāng)，會產(chǎn)生不一致的問題。而這樣的不一致問題，既可能是事務(wù)的不一致，也可能是分布式系統(tǒng)的不一致。下面還是以圖1-6所示為例進行介紹。假設(shè)只讀取A、B兩個數(shù)據(jù)分片，這時有如下4種情況。

讀A的Leader和B的Leader，這種情況簡稱全L問題。

• 事務(wù)的一致性：如果存在全局的事務(wù)管理器，那么此時讀多個數(shù)據(jù)分片的操作如同在單機系統(tǒng)進行數(shù)據(jù)的讀操作，通過封鎖并發(fā)訪問控制協(xié)議或者MVCC(全局快照點)等技術(shù)，可以確保讀操作過程中不發(fā)生數(shù)據(jù)異常。因為其他事務(wù)的寫操作會為本事務(wù)的讀操作帶來數(shù)據(jù)不一致的問題，所以通過全局的并發(fā)訪問控制協(xié)議(如全局封鎖并發(fā)訪問控制協(xié)議等技術(shù))，能夠避免出現(xiàn)事務(wù)層面的數(shù)據(jù)不一致問題。但是，如果沒有全局的并發(fā)訪問控制協(xié)調(diào)者，則容易出現(xiàn)跨節(jié)點的數(shù)據(jù)異常，所以需要由特定的并發(fā)訪問控制協(xié)議加以控制。
• 分布式系統(tǒng)的一致性：這類問題只在“讀A的Leader和B的Leader”這種結(jié)構(gòu)中存在，分布式數(shù)據(jù)庫需要通過實現(xiàn)“強一致性”來規(guī)避因分布和并發(fā)帶來的分布式事務(wù)型數(shù)據(jù)系統(tǒng)的一致性問題。具體可能出現(xiàn)的問題會在第2章介紹。

讀A的Leader和B的Follower，這種情況簡稱LF問題。B的Leader和Follower之間存在時延，即傳輸存在時延，從而帶來主備復(fù)制之間的數(shù)據(jù)不一致問題。如果支持“讀A的Leader和B的Follower”這樣的方式，需要確保所讀取的節(jié)點(A的Leader節(jié)點、B的Follower節(jié)點)上存在共同的事務(wù)狀態(tài)。

讀A的Follower和B的Leader，這種情況簡稱FL問題。問題的分析和解決方法同上。

讀A的Follower和B的Follower，這種情況簡稱全F問題。問題的分析和解決方法同上。

若是在讀數(shù)據(jù)時，同時存在事務(wù)的一致性和分布式系統(tǒng)的一致性問題，那么就需要通過強一致性來解決。

總體來說，事務(wù)的一致性是因并發(fā)的事務(wù)間并發(fā)訪問(讀寫、寫讀、寫寫沖突)同一個數(shù)據(jù)項造成的，而分布式一致性是因多個節(jié)點分散、節(jié)點使用各自的時鐘，以及沒有對各個節(jié)點上發(fā)生的操作進行排序造成的。

本書摘編自《分布式數(shù)據(jù)庫原理、架構(gòu)與實踐》，經(jīng)出版方授權(quán)發(fā)布。

文章題目：分布式數(shù)據(jù)庫系統(tǒng)面臨的問題和挑戰(zhàn)
當(dāng)前URL：http://fisionsoft.com.cn/article/coeiscs.html