掃二維碼與項(xiàng)目經(jīng)理溝通
我們在微信上24小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
作者:竹翁 2018-03-19 09:50:50
存儲
存儲軟件
分布式 在分布式存儲系統(tǒng)(包括OceanBase這樣的分布式數(shù)據(jù)庫)的使用中,我們經(jīng)常會提到“一致性”這個(gè)詞,但是這個(gè)術(shù)語1在不同的系統(tǒng)、不同人的心目中有不同的內(nèi)涵,很容易造成混淆。

網(wǎng)站建設(shè)哪家好,找成都創(chuàng)新互聯(lián)!專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、小程序制作、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了文安免費(fèi)建站歡迎大家使用!
“一致性”這個(gè)詞經(jīng)常出現(xiàn)在分布式系統(tǒng)相關(guān)的描述中,究竟指的是什么呢?
寫在前面
在分布式存儲系統(tǒng)(包括OceanBase這樣的分布式數(shù)據(jù)庫)的使用中,我們經(jīng)常會提到“一致性”這個(gè)詞,但是這個(gè)術(shù)語1在不同的系統(tǒng)、不同人的心目中有不同的內(nèi)涵,很容易造成混淆。
想象一個(gè)最簡單的存儲系統(tǒng),只有一個(gè)客戶端(單進(jìn)程)和一個(gè)服務(wù)端(單進(jìn)程服務(wù))??蛻舳隧樞虬l(fā)起讀寫操作,服務(wù)端也順序處理每個(gè)請求,那么無論從服務(wù)器視角還是從客戶端視角,后一個(gè)操作都可以看到前一個(gè)操作的結(jié)果。
然后,系統(tǒng)變的復(fù)雜一些,系統(tǒng)還是單個(gè)服務(wù)進(jìn)程(單副本),但是有多個(gè)客戶端并發(fā)進(jìn)行操作。這個(gè)模型下,多個(gè)客戶端的操作會互相影響,比如一個(gè)客戶端會讀到不是自己寫的數(shù)據(jù)(另一個(gè)客戶端寫入的)。一般單機(jī)并發(fā)程序就是這樣的模型,比如多個(gè)線程共享內(nèi)存的程序中。
然后,系統(tǒng)向另外一個(gè)方向變的復(fù)雜一些,為了讓后端存儲系統(tǒng)更健壯(目的不僅如此),我們可以讓兩個(gè)不同的服務(wù)進(jìn)程(位于不同的機(jī)器上)同時(shí)存儲同一份數(shù)據(jù)的拷貝,然后,通過某種同步機(jī)制讓這兩個(gè)拷貝的數(shù)據(jù)保持一致。這就是我們所說的“多副本”。假設(shè)還是一個(gè)客戶端進(jìn)程順序發(fā)起讀寫操作,每個(gè)操作理論上可以發(fā)給兩個(gè)副本所在的任意一個(gè)服務(wù)。那么,如果副本之間是數(shù)據(jù)同步不及時(shí),就可能發(fā)生前面寫入的數(shù)據(jù)讀不到,或者前面讀到的數(shù)據(jù)后面讀不到等情況。
結(jié)合前兩種模型,在一類真實(shí)的系統(tǒng)中,實(shí)際存在多個(gè)同時(shí)執(zhí)行讀寫操作的客戶端同時(shí)讀寫多個(gè)副本的后端存儲服務(wù)。如果這些不同客戶端的讀寫操作涉及到同一個(gè)數(shù)據(jù)項(xiàng)(比如,文件系統(tǒng)中,同一個(gè)文件的同一個(gè)位置范圍;或者數(shù)據(jù)庫系統(tǒng)中同一個(gè)表的同一行),那么他們的操作會互相影響。比如,A、B兩個(gè)客戶端,操作同一行數(shù)據(jù),A修改這行,是不是要求B立即能夠讀到這個(gè)最新數(shù)據(jù)呢?在多副本的系統(tǒng)中,如果不要求上述保證,那么可能可以允許A和B分別操作不同的副本。
更進(jìn)一步,前面的系統(tǒng)模型中,假設(shè)每個(gè)服務(wù)進(jìn)程擁有和管理著一份“全量”的數(shù)據(jù)。而更復(fù)雜的系統(tǒng)中,每個(gè)服務(wù)進(jìn)程中,只服務(wù)整個(gè)數(shù)據(jù)集的一個(gè)子集。例如在OceanBase類似的系統(tǒng)中,單機(jī)往往是無法容納全部數(shù)據(jù)的一份副本的,所以,數(shù)據(jù)庫表和表的分區(qū)是分散在多機(jī)上提供服務(wù),每個(gè)服務(wù)進(jìn)程只負(fù)責(zé)某些表分區(qū)的一個(gè)副本。在這樣的系統(tǒng)中,如果一個(gè)讀寫操作涉及到的多個(gè)分區(qū)位于多個(gè)服務(wù)進(jìn)程中,可能出現(xiàn)更復(fù)雜的讀寫語義的異常情況。比如,一個(gè)寫操作W中修改了兩個(gè)不同服務(wù)進(jìn)程的兩個(gè)不同的分區(qū)的副本上的兩個(gè)不同的數(shù)據(jù)項(xiàng),隨后的一個(gè)讀取這兩個(gè)數(shù)據(jù)項(xiàng)的讀操作,是否允許讀到W對一個(gè)數(shù)據(jù)項(xiàng)的修改,而讀不到對另一個(gè)數(shù)據(jù)項(xiàng)的修改?
綜上,我們要討論的通用的分布式存儲系統(tǒng)具有如下特性:
數(shù)據(jù)分為多個(gè)分片存儲在多臺服務(wù)節(jié)點(diǎn)上
每個(gè)分片有多個(gè)副本,存儲在不同的服務(wù)節(jié)點(diǎn)上
許多客戶端并發(fā)訪問系統(tǒng),執(zhí)行讀寫操作,每個(gè)讀寫操作在系統(tǒng)中需要花費(fèi)不等的時(shí)間
除非下文中特別注明和討論,讀寫操作是原子的
與數(shù)據(jù)庫事務(wù)一致性的差異
數(shù)據(jù)庫事務(wù)的ACID的中也有一個(gè)一致性(consistency),但彼一致性非此一致性。ACID中的一致性是指,數(shù)據(jù)庫的事務(wù)的執(zhí)行,或者說事務(wù)觀察到的數(shù)據(jù),總是要滿足某些全局的 一致性 約束條件,如唯一性約束,外鍵約束等。這個(gè)概念和數(shù)據(jù)庫的數(shù)據(jù)是否多副本沒關(guān)系。而本文的一致性在多副本的語境下才有意義。所以,數(shù)據(jù)庫事務(wù)的一致性,是指數(shù)據(jù)項(xiàng)之間總是滿足某些約束條件,或者說整個(gè)數(shù)據(jù)庫在滿足約束條件的意義上是 正確 的。
更讓人崩潰的是,事務(wù)的隔離性也容易和這里的一致性混淆,因?yàn)樗鸵恢滦阅P皖愃?,限定了某種并發(fā)操作的執(zhí)行順序。事務(wù)的隔離性是指并發(fā)執(zhí)行的事務(wù),能以多大的程度看到看到彼此。這個(gè)概念也和數(shù)據(jù)是否多副本沒有關(guān)系,單副本的單機(jī)數(shù)據(jù)庫也需要支持不同的隔離級別。比如,如果數(shù)據(jù)庫設(shè)定為可串行化(serializable)隔離級別,那么并發(fā)事務(wù)的執(zhí)行結(jié)果,必須等價(jià)為讓這些事務(wù)以某種順序串行執(zhí)行的結(jié)果。事務(wù)的隔離性,是為了并發(fā)程序(客戶端程序)正確性而生的一種編程抽象,可以類比多線程程序訪問共享數(shù)據(jù)時(shí)候需要解決的競爭。在實(shí)際系統(tǒng)中,事務(wù)是由一系列讀寫操作組成的,原子的事務(wù)的中間狀態(tài)是可能被并發(fā)的其他事務(wù)“觀察”到的。而在一致性模型的討論中,我們假設(shè)讀寫操作在服務(wù)端是“瞬時(shí)”完成的,也就是說,讀寫操作本身是原子的。
客戶端視角一致性模型
在多副本的存儲系統(tǒng)中,無論采用什么樣的多副本同步協(xié)議,為了保證多個(gè)副本能夠一致,本質(zhì)上都要求做到:
客戶視角的一致性模型定義了下面4種不同的保證。
系統(tǒng)對外提供的不同的一致性級別,實(shí)際上提供了這其中某幾個(gè)保證。不同的一致性級別,限定了系統(tǒng)允許的操作執(zhí)行順序,以及允許讀到多舊的數(shù)據(jù)。
為什么要定義不同的一致性級別呢?對用戶來說,當(dāng)然越嚴(yán)格的一致性越好,在異常和復(fù)雜場景下,嚴(yán)格的一致性級別可以極大地簡化應(yīng)用的復(fù)雜度。但是天下沒有免費(fèi)的午餐,一般來說,越嚴(yán)格的一致性模型,意味著性能(延遲)、可用性或者擴(kuò)展性(能夠提供服務(wù)的節(jié)點(diǎn)數(shù))等要有所損失。
CosmosDB 的一致性級別
Azure Cosmos DB2是一個(gè)支持多地部署的分布式NoSQL數(shù)據(jù)庫服務(wù)。它提供了豐富的可配置的一致性級別。以下五種一致性級別,從前向后可以提供更低的讀寫延遲,更高的可用性,更好的讀擴(kuò)展性。
1.強(qiáng)一致性
2.有界舊一致性(bounded staleness)
3.會話一致性
會話一致性的讀寫延遲都很低
4.前綴一致性
5.最終一致性.
Cosmos DB的文檔中提到了一個(gè)有趣的數(shù)字。大約有73%的用戶使用會話一致性級別,有20%的用戶使用有界舊一致性級別。
Cassandra的一致性級別
Cassandra 是一個(gè)使用多數(shù)派協(xié)議的NoSQL存儲系統(tǒng),通過控制讀寫操作訪問的副本數(shù)和副本的位置,可以實(shí)現(xiàn)不同的一致性級別。注意,作為NoSQL系統(tǒng),Cassandra只提供單行操作的原子性,多行操作不是原子的。下面的讀寫操作,都是指單行操作。
對于NoSQL系統(tǒng),一般支持的寫操作叫做PUT(有些系統(tǒng)叫做UPSERT)。這個(gè)操作的含義是,如果這行存在(通過唯一主鍵查找),則修改它;如果這行不存在,則插入。這個(gè)語義,可以近似(在不考慮二級索引的時(shí)候)等價(jià)于關(guān)系數(shù)據(jù)庫的INSERT ON DUPLICATE KEY UPDATE語句。本文前面所講的“寫操作”也是泛指這種語義。這個(gè)語義有什么特殊之處呢? 第一, 它是冪等的 。所以PUT操作可以重復(fù)執(zhí)行,不怕消息重傳。第二, 它是覆蓋(overwrite)語義 。所以,NoSQL系統(tǒng)的最終一致性,允許對于同一行數(shù)據(jù)的寫操作可以亂序,只要寫操作不斷,最終各個(gè)副本會一致。而關(guān)系數(shù)據(jù)庫的insert和update等修改語句,內(nèi)部實(shí)現(xiàn)都是即需要讀也需要寫。所以,關(guān)系數(shù)據(jù)庫的多副本一致性,假設(shè)簡單地把SQL修改語句同步到多個(gè)副本的方式來實(shí)現(xiàn),必須要以相同的順序執(zhí)行才能保證結(jié)果一致(當(dāng)然,實(shí)際系統(tǒng)不能這么實(shí)現(xiàn))。
寫操作配置
寫操作一致性配置定義了對于寫操作在哪些副本上成功之后,才能返回給客戶端。
讀操作配置
系統(tǒng)一致性級別
從系統(tǒng)層面來看,Cassandra提供了強(qiáng)一致性和最終一致性兩種一致性級別。不考慮多機(jī)房因素,通過設(shè)置上述讀寫操作的一致性配置,當(dāng)寫入副本數(shù)與讀取副本數(shù)之和大于總副本數(shù)的時(shí)候,可以保證讀操作總是可以讀取最新被寫入的數(shù)據(jù),即強(qiáng)一致性保證。如果寫入副本數(shù)與讀取副本數(shù)之和小于總副本數(shù)的時(shí)候,讀操作可能無法讀到最新的數(shù)據(jù),而且讀操作可能讀到比之前發(fā)生的讀操作更舊的數(shù)據(jù),所以這種情況下是最終一致性。
而副本位置是選擇整個(gè)集群、每個(gè)機(jī)房還是本地機(jī)房等因素,是為了在不同的容災(zāi)場景下,對跨機(jī)房通訊引入的高延遲進(jìn)行優(yōu)化,固有的一致性級別并不受影響。例如,寫操作用EACH_QUORUM,讀操作用LOCAL_QUORUM,還是提供了強(qiáng)一致性保證,但是不同機(jī)房的讀操作都變成本地的了,讀延遲較低。但是,和寫操作用QUORUM模式相比,某個(gè)機(jī)房發(fā)生了多數(shù)派宕機(jī)(總副本數(shù)還是少數(shù)派),就會導(dǎo)致寫操作失敗。再如,讀寫操作都用LOCAL_QUORUM,那么協(xié)調(diào)者節(jié)點(diǎn)所在機(jī)房內(nèi)是強(qiáng)一致性的,與協(xié)調(diào)者節(jié)點(diǎn)不在一個(gè)機(jī)房的讀操作則可能讀到舊數(shù)據(jù)。
OceanBase的一致性級別
一般來說,NoSQL類數(shù)據(jù)庫,比如HBase, Cassandra4等,僅提供單行操作的原子性保證。而關(guān)系數(shù)據(jù)庫的基本操作是一條SQL語句,SQL語句天生是多行操作,而且支持多語句事務(wù)和事務(wù)的回滾等,在SQL語句級和事務(wù)級還都需要提供原子性保證??梢岳斫?,實(shí)現(xiàn)相同的一致性級別,分布式關(guān)系數(shù)據(jù)庫比NoSQL類系統(tǒng)的復(fù)雜度和代價(jià)都要高。
OceanBase使用Multi-Paxos分布式共識算法在多個(gè)數(shù)據(jù)副本之間同步事務(wù)提交日志,每個(gè)修改事務(wù),要在多數(shù)派副本應(yīng)答以后才認(rèn)為提交成功。多個(gè)副本之間,通過自主投票的機(jī)制,選出其中一個(gè)副本為主副本(leader),它負(fù)責(zé)所有修改語句的執(zhí)行,特別的,達(dá)成多數(shù)派的事務(wù)提交日志要求包含主副本自己。在通常情況下,數(shù)據(jù)庫需要保證強(qiáng)一致性語義(和單機(jī)數(shù)據(jù)庫類比),我們的做法是,讀寫語句都在主副本上執(zhí)行。當(dāng)主副本宕機(jī)的時(shí)候,其余的多數(shù)派副本會選出新的主副本。此時(shí),已經(jīng)完成的每一個(gè)事務(wù)一定有至少一個(gè)副本記錄了提交日志的。新的主副本通過和其他副本的通信可以獲得所有已提交事務(wù)的日志,進(jìn)而完成恢復(fù),恢復(fù)以后繼續(xù)提供服務(wù)。通過這種機(jī)制,OceanBase可以保證在少數(shù)派宕機(jī)的情況下不會丟失任何數(shù)據(jù),而強(qiáng)一致性讀寫服務(wù)的宕機(jī)恢復(fù)時(shí)間小于一分鐘。
如果一個(gè)語句的執(zhí)行涉及到多個(gè)表的分區(qū),在OceanBase中這些分區(qū)的主副本可能位于不同的服務(wù)節(jié)點(diǎn)上。嚴(yán)格的數(shù)據(jù)庫隔離級別要求涉及多個(gè)分區(qū)的讀請求看到的是一個(gè)“快照”,也就是說,不允許看到部分事務(wù)。這要求維護(hù)某種形式的全局讀版本號,開銷較大。如果應(yīng)用允許,可以調(diào)整讀一致性級別,系統(tǒng)保證讀到最新寫入的數(shù)據(jù),但是不同分區(qū)上的數(shù)據(jù)不是一個(gè)快照。從一致性級別來看,這也是強(qiáng)一致性級別,但是打破了數(shù)據(jù)庫事務(wù)的ACID屬性。
在使用數(shù)據(jù)庫的互聯(lián)網(wǎng)業(yè)務(wù)中,有很多情況下業(yè)務(wù)組件還允許讀到稍舊的數(shù)據(jù),OceanBase提供兩種更弱的一致性級別。在最弱的級別下,我們可以利用所有副本提供讀服務(wù)。在OceanBase的實(shí)現(xiàn)中,多副本同步協(xié)議只保證日志落盤,并不要求日志在多數(shù)派副本上完成回放(寫入存儲引擎的memtable中)。所以,利用任意副本提供讀服務(wù)時(shí),即使對于同一個(gè)分區(qū)的多個(gè)副本,每個(gè)副本完成回放的數(shù)據(jù)版本也是不同的,這樣可能會導(dǎo)致讀操作讀到比之前發(fā)生的讀更舊的數(shù)據(jù)。也就是說,這種情況下提供的是最終一致性。當(dāng)任意副本宕機(jī)的時(shí)候,客戶端可以迅速重試其他副本,甚至當(dāng)多數(shù)派副本宕機(jī)的時(shí)候還可以提供這種讀服務(wù)。
但是,實(shí)際上,使用關(guān)系數(shù)據(jù)庫的應(yīng)用,大多數(shù)還是不能容忍亂序讀的。通過在數(shù)據(jù)庫連接內(nèi)記錄讀版本號,我們還提供了比最終一致性更嚴(yán)格的前綴一致性。它可以在每個(gè)數(shù)據(jù)庫連接內(nèi),保證單調(diào)讀。這種模式,一般用于OceanBase集群內(nèi)讀庫的訪問,業(yè)務(wù)本身是讀寫分離的架構(gòu)。
此外,對于這兩種弱一致性級別,用戶可以通過配置,控制允許讀到多舊的數(shù)據(jù)。在多地部署OceanBase的時(shí)候,跨地域副本數(shù)據(jù)之間的延遲是固有的。比如,用戶配置允許讀到30秒內(nèi)的數(shù)據(jù),那么只要本地副本的延遲小于30秒,則讀操作可以讀取本地副本。如果不能滿足要求,則讀取主副本所在地的其他副本。如果還不能滿足,則會讀取主副本。這樣的方式可以獲得最小的讀延遲,以及比強(qiáng)一致性讀更好的可用性。這樣,在同時(shí)保證會話級單調(diào)讀的條件下,我們提供了有界舊一致性級別。
注意,這些弱一致性級別都是放松了讀操作的語義,而所有的寫操作都需要寫入主副本節(jié)點(diǎn)。所以,單調(diào)寫和讀后寫總是保證的,但是讀自己所寫是不保證的。理論上,對于后幾種弱一致性級別中的每一種,我們也可以提供讀到的數(shù)據(jù)是不是保證“快照”的兩種不同語義,但是這違反了ACID語義,所以并沒有提供。
綜上所述,OceanBase在保證關(guān)系數(shù)據(jù)庫完備的ACID事務(wù)語義前提下,提供了強(qiáng)一致性、有界舊一致性、前綴一致性和最終一致性這幾種一致性級別。
最后,特別感謝 @楊蘇立 閱讀本文,并提出寶貴的修改意見。
參考資料
1 Consistency model in Wikipedia. https://en.wikipedia.org/wiki/Consistency_model
2 Tunable data consistency levels in Azure Cosmos DB. https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels
3 Configuring data consistency in Apache Cassandra. https://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html
4 Cassandra 2.0提供了一種輕量級事務(wù),詳見其文檔。

我們在微信上24小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流