建站
咨詢
售后
建站咨詢
新聞中心
Spanner是Google支持高可用的全球關(guān)系型數(shù)據(jù)庫(kù)[CDE+12]。Spanner可以管理大規(guī)模的復(fù)制數(shù)據(jù)，這種大規(guī)模不僅體現(xiàn)數(shù)據(jù)量方面，還體現(xiàn)在事務(wù)數(shù)量方面。 Spanner為寫入其中的每條數(shù)據(jù)分配全局一致的“真時(shí)”時(shí)間戳，客戶端可以在整個(gè)數(shù)據(jù)庫(kù)上無需鎖定的執(zhí)行全局一致性讀取。
CAP理論[Bre12]指出，在C，A，P三個(gè)期望的屬性中，你只能選擇兩個(gè)：
- C：一致性，本文中我們可以認(rèn)為是可串行性;
- A：可用性，指讀取和更新的100%可用;
- P：網(wǎng)絡(luò)分區(qū)，指對(duì)網(wǎng)絡(luò)分片的容忍。
基于CAP理論，選擇要拋棄的字母，將會(huì)得到三種系統(tǒng)：CA，CP和AP。需要注意的是，你不是必須選擇3個(gè)屬性中的2個(gè)，許多系統(tǒng)具有零個(gè)或一個(gè)CAP屬性。
對(duì)于“全球規(guī)?！钡姆植际较到y(tǒng)，分區(qū)通常被認(rèn)為是不可避免的——盡管這并不是共識(shí)[BK14]。一旦你認(rèn)為分區(qū)是不可避免的，任何分布式系統(tǒng)都必須準(zhǔn)備放棄一致性(AP)或放棄可用性(CP)，這不是任何人都想要的選擇結(jié)果。實(shí)際上，CAP理論的出發(fā)點(diǎn)是讓設(shè)計(jì)者認(rèn)真對(duì)待這種權(quán)衡。這里給出兩個(gè)重要的警告：首先，在真正發(fā)生分區(qū)的時(shí)候，你只需要喪失系統(tǒng)的部分功能而不是全部——當(dāng)然你必須付出一些代價(jià)[Bre12]。其次，CAP理論申明的是100%可用性，而本文討論的有趣之處是真實(shí)生產(chǎn)環(huán)境中涉及可用性本身的折中和權(quán)衡。
Spanner是CA系統(tǒng)
作為一個(gè)全球規(guī)模分布式系統(tǒng)，Spanner聲稱同時(shí)具有一致性和高可用性，這意味著Spanner系統(tǒng)不會(huì)發(fā)生分區(qū)，這很讓人懷疑。這是否意味著Spanner就是CAP定義的CA系統(tǒng)?從技術(shù)上來說，直接的答案是“否”，但從效果上來說，答案可以是“是”——即從用戶的角度，可以認(rèn)為Spanner是一個(gè)CA系統(tǒng)。
純粹主義者從技術(shù)上來看，答案當(dāng)然是“否”。因?yàn)榉謪^(qū)確實(shí)可能發(fā)生，并且實(shí)際上在谷歌也發(fā)生過。特別是在發(fā)生分區(qū)的時(shí)候，Spanner的策略是選擇C而放棄A。所以，技術(shù)上Spanner是一個(gè)CP系統(tǒng)。下面我們將具體展開對(duì)分區(qū)的探討。
考慮到Spanner永遠(yuǎn)提供一致性，Spanner宣稱是CA系統(tǒng)存在的真正問題是用戶對(duì)可用性的態(tài)度——即用戶是否會(huì)對(duì)可用性吹毛求疵。如果Spanner的實(shí)際可用性很高，宕機(jī)事件對(duì)用戶來說可以忽略，則Spanner可以證明“實(shí)際上是CA系統(tǒng)”聲明的正當(dāng)性。宣稱CA系統(tǒng)并不意味著100%的可用性(Spanner沒有提供也不會(huì)提供)，而是類似5個(gè)或更多“9”的可用性(1/106的故障或更少)。反過來，數(shù)據(jù)庫(kù)可用性的真正石蕊試紙是用戶(希望自己的服務(wù)高可用)——即用戶是否需要編寫額外的代碼來處理宕機(jī)異常。如果用戶沒有編寫額外代碼，也就是說用戶是假設(shè)數(shù)據(jù)庫(kù)高可用的。而基于Spanner內(nèi)部已有的大量用戶，我們可以知道用戶認(rèn)為Spanner是高可用數(shù)據(jù)庫(kù)。
關(guān)于可用性的數(shù)據(jù)
在我們深入研究Spanner之前，重新回顧C(jī)hubby的演進(jìn)歷程是值得的。Chubby也是一個(gè)提供一致性和可用性的全球規(guī)模(廣域網(wǎng)絡(luò))系統(tǒng)。原始的Chubby論文[Bur06]提到在700天內(nèi)出現(xiàn)了30秒或更長(zhǎng)時(shí)間的9次宕機(jī)，其中6次與網(wǎng)絡(luò)相關(guān)(如[BK14]中所討論的)。這樣的可用性低于最好的5個(gè)9可用性，現(xiàn)實(shí)一點(diǎn)說，如果我們假設(shè)每次宕機(jī)的平均值為10分鐘，這樣的可用性低于4個(gè)9，更有甚者，如果宕機(jī)時(shí)間是小時(shí)級(jí)的，則可用性將會(huì)低于3個(gè)9。?
對(duì)于鎖定和一致的讀/寫操作，得益于網(wǎng)絡(luò)，架構(gòu)和運(yùn)維的各種改進(jìn)，現(xiàn)在全球地理分布的Chubby單元提供99.99958%的平均可用性(30s+的宕機(jī)時(shí)間)。從2009年開始，由于“卓越”的可用性，Chubby的SRE工程師開始強(qiáng)制定期停機(jī)，以確保我們繼續(xù)了解Chubby對(duì)故障的依賴和影響。
在Google內(nèi)部，Spanner提供與Chubby類似的可用性水平。也就是說，好于5個(gè)9。云版本的Spanner具有相同的基礎(chǔ)，但添加了一些新的功能，所以在實(shí)際生產(chǎn)環(huán)境中可能會(huì)稍微低一點(diǎn)。
上面的餅圖揭示了Spanner事故的內(nèi)部原因分類。事故可能是一個(gè)意外事件，但并非所有事故都是宕機(jī)，一些事故可以很容易地掩蔽。圖表中的權(quán)重是事故出現(xiàn)的頻率而不是事故的影響。頻率最高的事故類別(User)是用戶錯(cuò)誤導(dǎo)致的，例如負(fù)載過高或者配置錯(cuò)誤，并且這些事故大多數(shù)只會(huì)影響到該特定用戶，而其余類別則可能會(huì)影響到區(qū)域中的所有用戶。Cluster類別的事故反映底層基礎(chǔ)架構(gòu)中的非網(wǎng)絡(luò)問題，包括服務(wù)器和電源的問題。Spanner通過使用多副本機(jī)制來自動(dòng)規(guī)避這些事件。然而，有時(shí)SRE也需要介入以修復(fù)損壞的副本。Operator類別的事故是由SRE引起的事故，例如配置錯(cuò)誤。Bug類別的事故則是導(dǎo)致一些問題的軟件錯(cuò)誤。這些事故都可能導(dǎo)致或大或小的宕機(jī)，曾經(jīng)兩起最大的宕機(jī)事故都是軟件錯(cuò)誤，并且同時(shí)影響到特定數(shù)據(jù)庫(kù)的所有副本。其他一麻袋的各種問題大多數(shù)只發(fā)生一次。
Network類別的事故(8%以下)是由網(wǎng)絡(luò)分區(qū)和網(wǎng)絡(luò)配置問題造成的。一部分集群節(jié)點(diǎn)和另外一部分集群節(jié)點(diǎn)分開的情況從來沒有發(fā)生過，也沒有發(fā)生過Spanner的法定數(shù)節(jié)點(diǎn)出現(xiàn)在分區(qū)中集群數(shù)量較少一邊的情況。但我們確實(shí)遇到過個(gè)別數(shù)據(jù)中心或區(qū)域與其他網(wǎng)絡(luò)斷開的情況。還有就是一些配置錯(cuò)誤導(dǎo)致臨時(shí)預(yù)留帶寬不足和一些與硬件故障相關(guān)的延遲。我們?cè)?jīng)遇到一個(gè)問題：其中單方向的通信失敗導(dǎo)致一個(gè)奇怪的分區(qū)發(fā)生，然后必須通過關(guān)閉一些節(jié)點(diǎn)來解決。到目前為止，網(wǎng)絡(luò)事件沒有引起大的宕機(jī)事故。
總而言之，要聲明“實(shí)際上是CA”系統(tǒng)，那么，這個(gè)系統(tǒng)必須處于這種相對(duì)概率狀態(tài)：1)系統(tǒng)必須在生產(chǎn)環(huán)境中具有非常高的可用性(以便用戶可以忽略異常)，以及2)系統(tǒng)由于分區(qū)引起的宕機(jī)故障次數(shù)應(yīng)該處于一個(gè)比較低的份額。Spanner滿足兩者。
網(wǎng)絡(luò)才是根本
許多人認(rèn)為，Spanner通過使用真時(shí)(TrueTime)可以繞過CAP理論。真時(shí)(TrueTime)是一種能夠使用全局同步時(shí)鐘的服務(wù)。雖然真時(shí)(TrueTime)很棒，卻對(duì)于實(shí)現(xiàn)CA系統(tǒng)沒有太大貢獻(xiàn)，它的實(shí)際價(jià)值會(huì)在下文討論。如果說Spanner真有什么特別之處，那就是谷歌的廣域網(wǎng)。在多年的運(yùn)營(yíng)改進(jìn)的基礎(chǔ)上，在生產(chǎn)環(huán)境中可以最大程度的減少分區(qū)發(fā)生，從而實(shí)現(xiàn)高可用性。
首先，Google的系統(tǒng)運(yùn)行在自己的私有全球網(wǎng)絡(luò)之上。Spanner不在公共互聯(lián)網(wǎng)上運(yùn)行——實(shí)際上，Spanner的每個(gè)數(shù)據(jù)包只流過Google控制的路由器和鏈路(不包括到遠(yuǎn)程客戶端的邊緣鏈路)。此外，每個(gè)數(shù)據(jù)中心通常具有至少三個(gè)將其連接到私有全球網(wǎng)絡(luò)的獨(dú)立光纖，以確保每對(duì)數(shù)據(jù)中心的路徑分集(路徑多樣性)。同樣，在數(shù)據(jù)中心內(nèi)部存在設(shè)備和路徑的冗余。因此，通常災(zāi)難性事件，例如切斷光纜，不會(huì)導(dǎo)致分區(qū)或宕機(jī)。
因此，帶來分區(qū)的真正風(fēng)險(xiǎn)不是網(wǎng)絡(luò)路徑斷開，而是某種類型的廣泛配置或軟件升級(jí)，這些配置或升級(jí)會(huì)同時(shí)切斷多個(gè)網(wǎng)絡(luò)路徑。這才是真正的風(fēng)險(xiǎn)，Google一直在努力防止和減輕這種風(fēng)險(xiǎn)。一般的策略是限制任何特定更新的影響范圍(“爆炸半徑”)，以便當(dāng)我們需要不可避免地推送一個(gè)錯(cuò)誤的更改時(shí)，只影響部分路徑或副本，然后我們必須在其他任何更改之前修復(fù)這些問題。
雖然Google的基礎(chǔ)網(wǎng)絡(luò)可以大大減少分區(qū)的風(fēng)險(xiǎn)，但它不能提高光速?？缭綇V域網(wǎng)的一致操作具有顯著的最小往返時(shí)間，這個(gè)時(shí)間可以達(dá)到幾十毫秒，當(dāng)跨越大陸時(shí)則更長(zhǎng)(1000英里的距離約為5百萬英尺，每納秒?英尺，因此最小值為10毫秒)。為了平衡區(qū)域內(nèi)延遲和容災(zāi)的需求，Google定義“區(qū)域”的范圍只具有2ms往返時(shí)間。Spanner通過事務(wù)流水線管理來緩解延遲，但這并不能減少單事務(wù)延遲。對(duì)于讀操作來說，由于能夠使用全局時(shí)間戳和本地副本(如下所述)，延遲通常較低。
具有弱一致性的模型具有較低的更新延遲。然而，沒有長(zhǎng)程往返，弱一致性的模型也有一個(gè)較低的持久性窗口，因?yàn)樵跀?shù)據(jù)復(fù)制到另一個(gè)區(qū)域之前，災(zāi)難可以同時(shí)摧毀本地和遠(yuǎn)程多個(gè)副本。
網(wǎng)絡(luò)分區(qū)期間發(fā)生什么
為了理解分區(qū)，我們需要更多地了解Spanner的工作原理。與大多數(shù)ACID數(shù)據(jù)庫(kù)一樣，Spanner使用兩階段提交(2PC)和嚴(yán)格的兩階段鎖定，以確保隔離和強(qiáng)一致性。2PC已經(jīng)被稱為“反可用性”協(xié)議[Hel16]，因?yàn)?PC要求所有成員節(jié)點(diǎn)必須參與工作(即必須可用)。為了緩解這個(gè)問題，Spanner為每個(gè)2PC成員節(jié)點(diǎn)建立Paxos組，這樣就算部分Paxos組成員宕機(jī)，2PC的“成員”還是高可用的。同時(shí)，數(shù)據(jù)也被分成組，形成放置和復(fù)制的基本單元。
如上所述，一般來說，當(dāng)發(fā)生分區(qū)時(shí)，Spanner會(huì)選擇C而放棄A。在實(shí)際生產(chǎn)環(huán)境中，這是基于以下考慮：
- 使用Paxos組來實(shí)現(xiàn)更新的共識(shí)。如果領(lǐng)導(dǎo)節(jié)點(diǎn)由于分區(qū)而不能維持仲裁(法定數(shù))，則更新被停止，并且系統(tǒng)不可用(通過CAP定義)。最終，在多數(shù)節(jié)點(diǎn)的分區(qū)，會(huì)重新選舉新的領(lǐng)導(dǎo)節(jié)點(diǎn)。
- 對(duì)跨組事務(wù)使用2PC意味著分區(qū)成員可以阻止事務(wù)提交。
分區(qū)在生產(chǎn)環(huán)境中最可能的結(jié)果是，有法定數(shù)節(jié)點(diǎn)的分區(qū)在選舉新的領(lǐng)導(dǎo)節(jié)點(diǎn)之后繼續(xù)工作，即服務(wù)繼續(xù)可用，但是少數(shù)節(jié)點(diǎn)分區(qū)一方的用戶則無法訪問服務(wù)。這是差別可用性的一個(gè)案例：少數(shù)節(jié)點(diǎn)分區(qū)一方的用戶可能有其他重大問題，比如失去連接，或已經(jīng)宕機(jī)。這意味著構(gòu)建在Spanner之上的多區(qū)域服務(wù)即使在分區(qū)期間也能夠良好工作。一些Paxos組完全不可用的可能性也是有的，但是不大。
只要所有已經(jīng)建立聯(lián)系的組都具有基于法定數(shù)選舉的領(lǐng)導(dǎo)節(jié)點(diǎn)，并都位于分區(qū)的一側(cè)，則Spanner中的“事務(wù)”可以工作。這意味著有些事務(wù)會(huì)完美工作，有些事務(wù)會(huì)超時(shí)，但系統(tǒng)總是一致的。Spanner的實(shí)現(xiàn)屬性是，任何讀取的返回都是一致的，即使事務(wù)稍后中止(包括超時(shí)等任何原因)。
除了常規(guī)事務(wù)之外，Spanner還支持快照讀取——從過去的特定時(shí)間讀取。 Spanner隨時(shí)間維護(hù)數(shù)據(jù)的多個(gè)版本，每個(gè)版本都有一個(gè)時(shí)間戳，因此可以使用正確版本準(zhǔn)確地回答快照讀取。特別地，每個(gè)副本知道它被寫入的時(shí)間(必須的)，并且任何副本可以在該時(shí)間戳之前單方面地回答讀取(除非它太舊了，并且已經(jīng)被垃圾收集)。類似地，很容易在同一時(shí)間跨多個(gè)組讀取(異步)。快照讀取根本不需要鎖。事實(shí)上，只讀事務(wù)被實(shí)現(xiàn)為在當(dāng)前時(shí)間(在任何最新的副本)的快照上讀取。
因此，快照讀取使分區(qū)更加健壯。特別地，快照讀取將會(huì)在下列條件下起作用：
- 正在初始化的分區(qū)中每個(gè)組至少存在一個(gè)副本，以及
- 這些副本的時(shí)間戳是過時(shí)的。
如果領(lǐng)導(dǎo)節(jié)點(diǎn)由于分區(qū)而失效，并且持續(xù)與分區(qū)同時(shí)失效，則第二條可能不成立，因?yàn)椴豢赡茉诜謪^(qū)的這一側(cè)上選舉新的領(lǐng)導(dǎo)節(jié)點(diǎn)。在發(fā)生分區(qū)期間，讀取在分區(qū)開始之前時(shí)間戳處的數(shù)據(jù)，很可能在分區(qū)的兩側(cè)上都成功，因?yàn)槿魏慰蛇_(dá)副本的數(shù)據(jù)都滿足需求(譯者注：看來可用性還要看用是否需要最新的數(shù)據(jù))。
關(guān)于真時(shí)(TrueTime)
一般來說，同步時(shí)鐘可以避免分布式系統(tǒng)中的通信。Barbara Liskov提供了帶有許多示例的詳細(xì)概述[Lis91]。對(duì)于我們的目標(biāo)來說，真時(shí)(TrueTime)是一個(gè)有界非零誤差的全局同步時(shí)鐘：它返回一個(gè)時(shí)間間隔，這個(gè)時(shí)間間隔包含了調(diào)用執(zhí)行的實(shí)際時(shí)間。因此，如果兩個(gè)間隔不重疊，則我們知道調(diào)用一定是實(shí)時(shí)排序的。如果間隔重疊，我們將無法知道調(diào)用的實(shí)際順序。
Spanner的一個(gè)精妙之處在于它從分布式鎖獲得串行性，從真時(shí)(TrueTime)獲得外部一致性(類似于線性化)。Spanner的外部一致性不變量是指，對(duì)任何兩個(gè)事務(wù)，T1和T2(即使在地球的兩側(cè))：
如果T2在T1提交后開始提交，則T2的時(shí)間戳大于T1的時(shí)間戳。
借用Liskov[Lis91，第7節(jié)]的話：
可以使用同步時(shí)鐘可以降低違反外部一致性的概率。本質(zhì)上來說，主服務(wù)器保存租約，對(duì)象是整個(gè)備份副本組。備份節(jié)點(diǎn)發(fā)送到主服務(wù)器的每條消息將授予主服務(wù)器租約。如果主存儲(chǔ)器保存有來自多數(shù)備份節(jié)點(diǎn)的未到期租約，則主數(shù)據(jù)庫(kù)可以單方面進(jìn)行讀取操作。......
該系統(tǒng)中的不變量是：每當(dāng)主服務(wù)器節(jié)點(diǎn)執(zhí)行讀取時(shí)，它必須保存有來自大多數(shù)備份節(jié)點(diǎn)的有效租約。如果時(shí)鐘不同步，這個(gè)不變量將不會(huì)成立。
Spanner使用真時(shí)(TrueTime)作為時(shí)鐘，可以確保不變量成立。特別地，在事務(wù)提交期間，領(lǐng)導(dǎo)節(jié)點(diǎn)必須等待，直到確認(rèn)提交時(shí)間是過去的(基于誤差范圍)。這種“提交等待”在生產(chǎn)環(huán)境中不是長(zhǎng)時(shí)間的等待，并且與(內(nèi)部)事務(wù)通信并行地進(jìn)行。一般來說，外部一致性需要單調(diào)增加時(shí)間戳，而“等待不確定性”是一種常見的模式。
Spanner通過更新租約，延長(zhǎng)領(lǐng)導(dǎo)節(jié)點(diǎn)的選舉時(shí)間，通常為10秒。就像Liskov所討論的，每當(dāng)法定數(shù)節(jié)點(diǎn)同意一項(xiàng)決定時(shí)，租約被延長(zhǎng)，因?yàn)閰⑴c節(jié)點(diǎn)剛剛驗(yàn)證了領(lǐng)導(dǎo)節(jié)點(diǎn)是有效的。當(dāng)領(lǐng)導(dǎo)節(jié)點(diǎn)故障時(shí)，有兩個(gè)選項(xiàng)：1)等待租約過期，然后選擇新的領(lǐng)導(dǎo)節(jié)點(diǎn)，或2)重啟舊領(lǐng)導(dǎo)節(jié)點(diǎn)，這可能更快。對(duì)于一些故障，我們可以發(fā)出“最后一個(gè)”UDP數(shù)據(jù)包來釋放租約，這是用來加速租約的到期。由于計(jì)劃外的故障在Google數(shù)據(jù)中心中很少見，所以長(zhǎng)期租約很有意義(譯者注：樂觀方法)。租約還確保領(lǐng)導(dǎo)節(jié)點(diǎn)之間的時(shí)間單調(diào)性，并且使得群組參與節(jié)點(diǎn)能夠在租約時(shí)間內(nèi)提供讀取(即使沒有領(lǐng)導(dǎo)節(jié)點(diǎn))。
然而，真時(shí)(TrueTime)的真正價(jià)值在于它在一致性快照方面的能力?；赝^去，多版本并發(fā)控制系統(tǒng)(MVCC)[Ree78]的歷史已經(jīng)很悠久了——單獨(dú)保存舊版本，讀取操作從舊的版本中讀取數(shù)據(jù)，而不需要考慮當(dāng)前的事務(wù)操作。這是一個(gè)非常有用和被低估的屬性：特別是，Spanner快照是一致的(對(duì)于快照時(shí)間)，因此無論系統(tǒng)保存什么樣的不變量，快照也將會(huì)保存。這是真的，盡管你不知道什么是不變量!本質(zhì)上來說，快照來自于連續(xù)事務(wù)之間，并且反映了快照時(shí)間之前的所有內(nèi)容(更多的就沒有了)。如果沒有事務(wù)一致的快照，系統(tǒng)很難從過去的某個(gè)時(shí)間點(diǎn)重新啟動(dòng)，因?yàn)槭聞?wù)部分提交的內(nèi)容可能違反了一些不變量或完整性約束。正是缺乏一致性，有時(shí)系統(tǒng)很難從備份中還原——沖突的數(shù)據(jù)需要手動(dòng)恢復(fù)。
例如，考慮使用MapReduce在數(shù)據(jù)庫(kù)上執(zhí)行大型分析查詢。如果使用Bigtable作為數(shù)據(jù)庫(kù)，盡管Bigtable也存儲(chǔ)數(shù)據(jù)過去的版本，但數(shù)據(jù)分片的時(shí)間標(biāo)簽是“鋸齒狀”的，這使得結(jié)果不可預(yù)測(cè)，有時(shí)還會(huì)導(dǎo)致不一致(特別是對(duì)于最近的數(shù)據(jù))。如果使用Spanner作為數(shù)據(jù)庫(kù)，同一個(gè)MapReduce操作可以選擇精確的時(shí)間戳，并獲得可重復(fù)和一致的結(jié)果。
真時(shí)(TrueTime)還使跨多個(gè)獨(dú)立系統(tǒng)記錄快照成為可能——只要使用(單調(diào)遞增)真時(shí)(TrueTime)時(shí)間戳提交，與快照時(shí)間達(dá)成一致，并隨時(shí)間存儲(chǔ)多個(gè)版本(通常在日志中)。這不僅限于Spanner：您可以制作自己的事務(wù)系統(tǒng)，并且兩個(gè)系統(tǒng)(甚至k系統(tǒng))上的快照是一致的。一般來說，在這些系統(tǒng)上你需要一個(gè)2PC(同時(shí)持有鎖)來與快照時(shí)間達(dá)成一致并確認(rèn)成功，但系統(tǒng)不需要就其他事項(xiàng)達(dá)成一致，可以完全不同。
你還可以使用時(shí)間戳作為令牌在工作流中傳遞。例如，如果對(duì)系統(tǒng)進(jìn)行更新，你可以將更新的時(shí)間戳傳遞到工作流的下一個(gè)階段，以便確定系統(tǒng)是否反映該事件后的時(shí)間。在發(fā)生分區(qū)的情況下，就不一定了。在這種情況下，下一個(gè)階段實(shí)際上應(yīng)該等待保持一致性(或繼續(xù)工作保持可用性)。如果沒有時(shí)間戳令牌，很難知道你需要等待什么。當(dāng)然，傳遞時(shí)間戳不是解決這個(gè)問題的唯一方法，但這是一種優(yōu)雅的，魯棒的方式，同時(shí)確保最終一致性。當(dāng)不同的階段不共享代碼且具有不同的管理員時(shí)，這特別有用——兩者可以在沒有通信的情況下對(duì)時(shí)間達(dá)成一致。
快照是關(guān)于過去的，Spanner也可以對(duì)未來時(shí)間達(dá)成共識(shí)。Spanner的一項(xiàng)功能是，你可以對(duì)未來schema變更的時(shí)間達(dá)成一致。這允許你暫停應(yīng)用新schema的更改，以便能夠同時(shí)服務(wù)兩個(gè)版本。一旦你準(zhǔn)備好了，你可以選擇一個(gè)時(shí)間點(diǎn)，在所有副本上以原子方式同時(shí)切換到新的schema(你也可以選擇之前的時(shí)間點(diǎn)，但你不可能在目標(biāo)時(shí)間之前準(zhǔn)備好)。至少在理論上，你可以進(jìn)行未來的操作，例如可見性計(jì)劃的刪除或更改。
真時(shí)(TrueTime)本身可能受到分區(qū)的阻礙。真時(shí)(TrueTime)的來源是GPS接收器和原子鐘的組合，兩者都可以通過它們自身的微小漂移來保持精確的時(shí)間。由于每個(gè)數(shù)據(jù)中心都有“主時(shí)間服務(wù)器”(冗余)，因此分區(qū)的兩側(cè)很可能繼續(xù)享有準(zhǔn)確的時(shí)間。然而，獨(dú)立的節(jié)點(diǎn)需要到通過網(wǎng)絡(luò)連接到時(shí)間服務(wù)器，否則它們的時(shí)鐘將會(huì)漂移。因此，在分區(qū)期間，基于本地時(shí)鐘漂移的速率，獨(dú)立節(jié)點(diǎn)的間隔隨著時(shí)間緩慢地增長(zhǎng)?；谡鏁r(shí)(TrueTime)的操作，如Paxos領(lǐng)導(dǎo)節(jié)點(diǎn)選舉或事務(wù)提交，因此必須多等待一段時(shí)間，但操作仍能夠完成(假設(shè)2PC和法定數(shù)仲裁的通信工作良好)。
Eric Brewer
VP, Infrastructure at Google
Professor, UC Berkeley
結(jié)論
作為一個(gè)全球規(guī)模的分布式系統(tǒng)，Spanner只是提供了一致性和大于5個(gè)9的可用性，但Spanner宣稱是一個(gè)“實(shí)際上是CA”系統(tǒng)是合理的。與Chubby一樣，如果你能夠控制整個(gè)網(wǎng)絡(luò)(盡管全球范圍內(nèi)不常見)，CA組合在實(shí)際生產(chǎn)環(huán)境中是可能的。即使這樣，仍舊需要網(wǎng)絡(luò)路徑的大量冗余，處理相關(guān)故障的架構(gòu)規(guī)劃，以及計(jì)劃周密的運(yùn)維，特別是系統(tǒng)升級(jí)的時(shí)候。在發(fā)生宕機(jī)的情況時(shí)，Spanner選擇一致性而不是可用性。
Spanner使用2PC來實(shí)現(xiàn)串行化，使用真時(shí)(TrueTime)實(shí)現(xiàn)外部一致性，無鎖一致性讀取，以及一致的快照。
【本文是專欄作者石頭的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)通過作者微信公眾號(hào)補(bǔ)天遺石(butianys)獲取授權(quán)】
文章題目：Spanner,真時(shí)和CAP理論
地址分享：http://m.fisionsoft.com.cn/article/dheoiej.html
