文章系列

1. 你為何需要關(guān)注？
2. 可能出現(xiàn)什么問題？
3. 采用的障礙是什么？
4. 新算法如何提供幫助？

之前的文章解釋了什么是數(shù)據(jù)一致性，“強(qiáng)一致性”和“最終一致性”的區(qū)別，以及為什么這種區(qū)別對現(xiàn)代應(yīng)用程序開發(fā)者比以往任何時(shí)候都更加重要。我們還介紹了“一致性稅”的概念：如果開發(fā)團(tuán)隊(duì)選擇僅具有最終一致性或有限一致性保證的系統(tǒng)，則需要額外投入的時(shí)間和精力。

許多現(xiàn)代數(shù)據(jù)庫使用最先進(jìn)的算法來消除一致性和性能之間的權(quán)衡。當(dāng)然，如果沒有適當(dāng)?shù)慕忉?，我們不希望您輕信我們的說法。因此，在本文的最后一部分，我們將深入探討其中一些數(shù)據(jù)庫背后的技術(shù)細(xì)節(jié)。通常，這些技術(shù)細(xì)節(jié)的唯一信息來源是研究論文，因此本文的目的是用更簡單的術(shù)語解釋這些系統(tǒng)。由于這些系統(tǒng)在現(xiàn)實(shí)中要復(fù)雜得多，因此如果您想了解更多信息并喜歡閱讀研究論文，我們將在文本中提供鏈接。

簡介

在本系列文章的第一部分和第二部分中，我們解釋了分布式數(shù)據(jù)庫如何使用不同的副本分發(fā)負(fù)載和/或?yàn)椴煌瑓^(qū)域的用戶提供服務(wù)。為了總結(jié)一下，對于新讀者來說，副本只是數(shù)據(jù)的副本。此副本可以位于同一位置以實(shí)現(xiàn)冗余，也可以位于另一個(gè)位置以向這些位置的用戶提供更低的延遲。擁有可以處理讀寫操作的多個(gè)副本具有強(qiáng)大的優(yōu)勢，因?yàn)閿?shù)據(jù)庫變得可擴(kuò)展并且可以為所有用戶提供更低的延遲，無論他們身在何處。但是，您不希望每個(gè)副本對數(shù)據(jù)都有自己的解釋。您需要對數(shù)據(jù)的唯一解釋，這通常被稱為單一事實(shí)來源，而不是每個(gè)副本之間存在細(xì)微的數(shù)據(jù)差異。為了實(shí)現(xiàn)這一點(diǎn)，您需要就數(shù)據(jù)更改達(dá)成某種共識(shí)。我們需要共識(shí)。

等待共識(shí)

每個(gè)旨在保持一致性的分布式數(shù)據(jù)庫都有多個(gè)副本，這些副本必須就事務(wù)的結(jié)果達(dá)成一致。如果發(fā)生沖突的數(shù)據(jù)更新，這些副本必須就哪個(gè)更新通過以及哪個(gè)更新不通過達(dá)成一致。這稱為“共識(shí)”。

讓我們回到我們的游戲中來說明為什么我們需要共識(shí)。假設(shè)我們的游戲玩家只剩下 3 個(gè)金幣，但試圖同時(shí)從兩家不同的商店購買兩件不同的物品，總預(yù)算超過剩余的 3 個(gè)金幣。這涉及兩個(gè)事務(wù)，每個(gè)事務(wù)對應(yīng)一個(gè)項(xiàng)目/商店，我們將其表示為 t1 和 t2。讓我們假設(shè)商店的老板彼此相隔千里，因此交易發(fā)生在兩個(gè)不同的副本上。如果接受兩個(gè)事務(wù)，用戶將能夠購買超出其承受能力的物品。我們?nèi)绾畏乐褂脩舫В?/p>

我們知道，這些副本需要進(jìn)行通信才能就這兩個(gè)事務(wù)的最終結(jié)果達(dá)成一致。我們不知道的是他們需要多少通信。為了就哪個(gè)事務(wù)獲得優(yōu)先權(quán)以及哪個(gè)事務(wù)被取消達(dá)成一致，副本 1 和副本 2 之間需要來回發(fā)送多少消息？

由于分布式數(shù)據(jù)庫中的副本旨在以低延遲為世界不同地區(qū)的用戶提供服務(wù)，因此它們本質(zhì)上相距甚遠(yuǎn)。通過將數(shù)據(jù)副本放置在更靠近最終用戶的服務(wù)器上，這些用戶可以以更低的延遲進(jìn)行讀取。但是，當(dāng)發(fā)生寫入操作時(shí)，副本需要相互發(fā)送消息以統(tǒng)一更新所有重復(fù)的數(shù)據(jù)——由于這些消息在全球范圍內(nèi)傳播時(shí)受到光速的限制，因此這些消息可能需要幾十毫秒的時(shí)間。很明顯，我們需要盡可能減少跨數(shù)據(jù)中心消息的數(shù)量，這樣最終用戶就不會(huì)因?yàn)槿蚋鞯氐倪@些副本達(dá)成共識(shí)而等待。

長期以來，人們一直認(rèn)為這樣做是不可能或不切實(shí)際的。但如今，已經(jīng)存在多種技術(shù)可以將往返次數(shù)保持在較低水平，并將延遲控制在正常范圍內(nèi)。

紐約和巴黎之間的距離為 5839 公里。光從紐約傳播到巴黎，然后再返回，需要 40 毫秒。

— 理論速度與現(xiàn)實(shí)世界速度

剩下的最重要的問題是：“我們需要執(zhí)行多少次事務(wù)往返？”這個(gè)問題的答案很大程度上取決于所使用的算法。

如何達(dá)成一致？

看來，為了就某事達(dá)成共識(shí)，您至少需要四個(gè)躍點(diǎn)（或兩輪通信）：一輪讓每個(gè)副本知道您即將執(zhí)行某些操作，然后第二輪在每個(gè)人都同意可以執(zhí)行此操作后實(shí)際執(zhí)行該操作。這是一種稱為分布式兩階段提交的方法，幾乎所有分布式數(shù)據(jù)庫都使用這種方法。讓我們來看一個(gè)比喻。假設(shè)您必須與一群人就派對的合適日期達(dá)成一致。這可能如下所示：

首先，Polly 詢問每個(gè)人是否可以在星期一參加派對；她現(xiàn)在知道每個(gè)人實(shí)際上都可以來參加派對。接下來，她需要讓每個(gè)人都知道派對確實(shí)將在星期一舉行，并且人們承認(rèn)他們會(huì)來。

這些與兩階段提交中的兩個(gè)階段非常相似。當(dāng)然，數(shù)據(jù)庫不會(huì)舉辦派對，因此這些階段具有不同的功能。在分布式系統(tǒng)的情況下，這些階段稱為：

• 準(zhǔn)備或請求提交：確保每個(gè)人都知道事務(wù)。在此階段，分布式數(shù)據(jù)庫中的副本將查詢存儲(chǔ)在磁盤上的某種待辦事項(xiàng)列表（事務(wù)日志）中，以確保服務(wù)器宕機(jī)時(shí)它們?nèi)匀恢涝撟鍪裁础?/li>
• 提交：實(shí)際計(jì)算結(jié)果并將其存儲(chǔ)

當(dāng)然，一如既往，事情并非那么簡單。此類算法有很多變體。例如，有兩階段提交的改進(jìn)版本，稱為 Paxos 和 Raft，甚至還有許多這些變體（多 Paxos/快速 Paxos/…）。這些替代方案旨在解決可用性或性能問題。要了解可用性問題，只需想象一下 Polly 生病或 Amber 的手機(jī)沒電了。在前一種情況下，她將無法繼續(xù)擔(dān)任派對協(xié)調(diào)員的工作；而在后一種情況下，Polly 將暫時(shí)無法知道 Amber 是否同意派對日期。Raft 和 Paxos 通過僅要求大多數(shù)人回答和/或在領(lǐng)導(dǎo)者或協(xié)調(diào)者宕機(jī)時(shí)自動(dòng)選擇新的協(xié)調(diào)者來改進(jìn)這一點(diǎn)。此處可以找到一個(gè)顯示 Raft 工作原理的良好動(dòng)畫。

就什么達(dá)成一致？

我們可以得出結(jié)論，每個(gè)分布式數(shù)據(jù)庫都需要 2 次往返來讀寫數(shù)據(jù)嗎？不，現(xiàn)實(shí)比這更復(fù)雜。一方面，有很多可能的優(yōu)化，另一方面，我們可能需要就多件事達(dá)成一致。

• 就事務(wù)的時(shí)間達(dá)成一致
• 就是否可以執(zhí)行讀取操作達(dá)成一致

最簡單的具有多個(gè)兩階段提交輪次的示例可能是 Cassandra 的輕量級事務(wù)。他們首先需要就讀取達(dá)成共識(shí)協(xié)議，然后就寫入達(dá)成共識(shí)。如果每條消息需要 40 毫秒才能傳播，這意味著整個(gè)事務(wù)需要 320 毫秒或更長時(shí)間——這取決于所需的“鎖”，我們將在后面解釋。

這很容易理解，但實(shí)現(xiàn)方面存在一些問題，因?yàn)?Cassandra 從未設(shè)計(jì)為強(qiáng)一致性。這是否意味著強(qiáng)一致性數(shù)據(jù)庫甚至更慢？一點(diǎn)也不！現(xiàn)代分布式數(shù)據(jù)庫使用多種有趣的特性來實(shí)現(xiàn)更好的性能。

等待鎖

我們不僅需要等待消息達(dá)成一致，而且?guī)缀趺總€(gè)分布式數(shù)據(jù)庫還將使用“鎖”。鎖保證事務(wù)即將更改的數(shù)據(jù)不會(huì)被另一個(gè)事務(wù)同時(shí)更改。當(dāng)數(shù)據(jù)被鎖定后，其他事務(wù)就無法更改它，這意味著這些事務(wù)必須等待。因此，此類鎖的持續(xù)時(shí)間對性能有很大影響。同樣，這種性能影響取決于數(shù)據(jù)庫實(shí)現(xiàn)的算法和優(yōu)化。某些數(shù)據(jù)庫持有的鎖比其他數(shù)據(jù)庫更長，而某些數(shù)據(jù)庫根本不使用鎖。

現(xiàn)在我們已經(jīng)了解了足夠的基礎(chǔ)知識(shí)，讓我們深入了解算法。

現(xiàn)代共識(shí)算法

我們現(xiàn)在知道，共識(shí)和鎖是我們需要優(yōu)化的主要瓶頸。因此，讓我們回到本文的主要問題：“新技術(shù)如何將這些延遲控制在可接受的范圍內(nèi)？”讓我們從這些現(xiàn)代算法中的第一個(gè)開始，它激發(fā)了數(shù)據(jù)庫世界其他領(lǐng)域的一些有趣的想法。

2010 年 – Percolator

Percolator 是一個(gè)基于 BigTable（谷歌構(gòu)建的早期 NoSQL 數(shù)據(jù)庫之一）的內(nèi)部系統(tǒng)，谷歌使用它來對搜索索引的頁面抓取速度進(jìn)行增量更新。關(guān)于 Percolator 的第一篇論文發(fā)表于 2010 年，它啟發(fā)了第一個(gè)受其啟發(fā)的分布式數(shù)據(jù)庫：2013 年的 FoundationDB。然后，F(xiàn)oundationDB 被 Apple 收購，最終在 2019 年發(fā)布了穩(wěn)定版本，以及 FoundationDB 論文。

盡管 Percolator 允許谷歌顯著加快頁面抓取速度，但它最初并非作為通用數(shù)據(jù)庫構(gòu)建的。它更旨在成為一個(gè)快速且可擴(kuò)展的增量處理引擎，以支持谷歌的搜索索引。由于搜索索引必須可擴(kuò)展，因此必須在許多機(jī)器上同時(shí)進(jìn)行許多計(jì)算，這需要一個(gè)分布式數(shù)據(jù)庫。正如我們在之前的文章中了解到的那樣，針對存儲(chǔ)數(shù)據(jù)的分布式系統(tǒng)進(jìn)行編程可能非常復(fù)雜，并且傳統(tǒng)上要求開發(fā)人員支付“一致性稅”以應(yīng)對不可預(yù)測的數(shù)據(jù)庫行為。為了避免支付如此高的一致性稅，谷歌在構(gòu)建 Percolator 時(shí)采用了強(qiáng)一致性模型。

Percolator 的一致性模型如果沒有兩個(gè)關(guān)鍵要素是無法存在的：版本控制和時(shí)間戳預(yù)言機(jī)

要素 1：版本控制

正如我們在之前的文章中提到的那樣，強(qiáng)一致性要求我們就事務(wù)的全局順序達(dá)成一致。版本控制是許多此類算法的關(guān)鍵要素之一，因?yàn)樗捎糜诠收匣謴?fù)、幫助復(fù)制數(shù)據(jù)以及支持稱為“快照隔離”的一致性模型。

當(dāng)節(jié)點(diǎn)發(fā)生故障或斷開連接時(shí)，版本控制有助于故障恢復(fù)。當(dāng)節(jié)點(diǎn)重新上線時(shí)，由于存在版本，它可以通過從能夠保存的最后一個(gè)快照開始，然后根據(jù)另一個(gè)節(jié)點(diǎn)中的版本重播事務(wù)來輕松恢復(fù)其狀態(tài)。它所要做的就是詢問另一個(gè)節(jié)點(diǎn)：“嘿，自從我不在以來發(fā)生了什么變化？”如果沒有版本控制，它將必須復(fù)制所有數(shù)據(jù)，這將給系統(tǒng)帶來巨大的壓力。

故障恢復(fù)很棒，但最大的優(yōu)勢在于此類版本控制系統(tǒng)可用于實(shí)現(xiàn)強(qiáng)一致性模型。如果版本控制系統(tǒng)保留每次數(shù)據(jù)更改的版本，我們實(shí)際上可以回到過去并針對我們數(shù)據(jù)的早期版本執(zhí)行查詢。

一些聰明的人發(fā)現(xiàn)，這種歷史查詢功能可用于提供稱為“快照一致性”的一致性模型?？煺找恢滦缘乃枷胧窃诓樵冮_始時(shí)選擇數(shù)據(jù)的版本，在查詢的其余部分使用該版本的數(shù)，然后在查詢結(jié)束時(shí)寫入新版本。

這里有一個(gè)可能的陷阱：在執(zhí)行此類查詢期間，另一個(gè)查詢可能會(huì)寫入與第一個(gè)查詢沖突的數(shù)據(jù)。例如，如果兩個(gè)寫入查詢都從銀行賬戶的相同快照（賬戶上有 1000 美元）開始，它們都可能花費(fèi)這筆錢，因?yàn)樗鼈儧]有看到另一個(gè)查詢的寫入。為了防止這種情況，將執(zhí)行一個(gè)附加事務(wù)以查看在任一查詢寫入結(jié)果之前快照的值是否已更改。如果確實(shí)發(fā)生了導(dǎo)致快照值更改的沖突，則事務(wù)將回滾并必須重新啟動(dòng)。

但是，Percolator 仍然需要解決一個(gè)問題。不同機(jī)器上的時(shí)鐘很容易相差幾百毫秒。如果查詢的數(shù)據(jù)分布在多臺(tái)機(jī)器上（如我們最初的示例中），您不能簡單地要求兩臺(tái)機(jī)器都以某個(gè)時(shí)間戳提供數(shù)據(jù)，因?yàn)樗鼈儗Ξ?dāng)前時(shí)間的理解略有不同。這是一個(gè)毫秒的問題，但是當(dāng)必須處理許多事務(wù)時(shí)，幾毫秒就足以從正確的數(shù)據(jù)變?yōu)殄e(cuò)誤的數(shù)據(jù)。

時(shí)間同步使我們想到了 Percolator 的第二個(gè)要素。

要素 2：時(shí)間戳預(yù)言機(jī)

Percolator 解決時(shí)間同步問題的方案稱為時(shí)間戳預(yù)言機(jī)。Percolator 沒有讓每個(gè)節(jié)點(diǎn)自己決定時(shí)間（這不夠準(zhǔn)確），而是使用一個(gè)中心系統(tǒng)公開 API 來提供時(shí)間戳。此系統(tǒng)所在的節(jié)點(diǎn)是時(shí)間戳預(yù)言機(jī)。當(dāng)我們保留數(shù)據(jù)的多個(gè)版本時(shí)，每個(gè)查詢至少需要兩個(gè)時(shí)間戳。首先，我們需要一個(gè)時(shí)間戳來查詢快照，我們將使用它來讀取數(shù)據(jù)。然后，當(dāng)我們準(zhǔn)備好寫入時(shí)，在事務(wù)結(jié)束時(shí)，我們需要第二個(gè)時(shí)間戳來標(biāo)記新數(shù)據(jù)版本。因此，Percolator 的缺點(diǎn)是它至少需要兩次調(diào)用時(shí)間戳預(yù)言機(jī)，如果預(yù)言機(jī)位于與調(diào)用源節(jié)點(diǎn)不同的區(qū)域，則會(huì)引入更多延遲。當(dāng)谷歌提出他們的分布式數(shù)據(jù)庫 Spanner 時(shí)，他們解決了這個(gè)問題。

2012 年 – Spanner

Spanner 是第一個(gè)提供強(qiáng)一致性的全球分布式數(shù)據(jù)庫，這基本上意味著您可以獲得低延遲讀取，而無需再擔(dān)心潛在的數(shù)據(jù)庫錯(cuò)誤。開發(fā)人員不再需要額外的工作來規(guī)避最終一致性造成的潛在錯(cuò)誤。該論文發(fā)表于 2012 年，并于 2017 年作為 Spanner Cloud 公開發(fā)布。

要素 1：版本控制

谷歌在使用 Percolator 的經(jīng)驗(yàn)后構(gòu)建了 Spanner。由于 Percolator 的版本控制系統(tǒng)被證明有效，因此他們在 Spanner 的設(shè)計(jì)中保留了這一點(diǎn)。此版本控制系統(tǒng)提供了在您愿意放棄一致性的情況下進(jìn)行非常快速讀?。煺兆x取）的能力。在這種情況下，您可以運(yùn)行查詢并為 Spanner 提供結(jié)果的最大年齡。例如：“請盡快返回我的當(dāng)前庫存，但數(shù)據(jù)只能是 15 秒前的”?；旧希梢詾槊總€(gè)查詢選擇適合您用例的一致性級別，而不是放棄一致性。

要素 2：TrueTime

為了消除同步機(jī)器之間時(shí)間的額外開銷，Spanner 放棄了時(shí)間戳預(yù)言機(jī)，轉(zhuǎn)而采用了一種稱為 TrueTime 的新概念。TrueTime 沒有使用一個(gè)中心系統(tǒng)來提供統(tǒng)一的時(shí)間視圖，而是試圖減少機(jī)器本身的時(shí)鐘漂移。谷歌的工程師通過實(shí)現(xiàn)基于 GPS 和原子鐘的時(shí)間同步協(xié)議來限制本地時(shí)鐘漂移。這種同步算法允許他們將時(shí)鐘漂移限制在 7 毫秒以內(nèi)，但這需要由 GPS 和原子鐘技術(shù)組合而成的特定硬件。

當(dāng)然，仍然存在 7 毫秒的潛在時(shí)鐘漂移，這意味著兩臺(tái)服務(wù)器仍然可以將時(shí)間戳解釋為兩個(gè)不同的快照。這由 Spanner 的第三個(gè)要素解決：提交等待。

要素 3：提交等待

事實(shí)上，TrueTime API 不返回一個(gè)時(shí)間戳，而是返回一個(gè)區(qū)間 n，它確定當(dāng)前時(shí)間戳應(yīng)該位于該區(qū)間內(nèi)。準(zhǔn)備提交后，它只需等待幾毫秒即可應(yīng)對潛在的漂移，這稱為“提交等待”。這確保了將分配給寫入的時(shí)間戳是已在所有節(jié)點(diǎn)上通過的時(shí)間戳。這也是在商品硬件上運(yùn)行 Spanner 無法提供相同保證的原因，因?yàn)榈却龝r(shí)間需要幾百毫秒。

2012 年 – Calvin

關(guān)于 Calvin 算法的第一篇論文發(fā)表于 2012 年，來自耶魯大學(xué)的研究。與之前的方案一樣，Calvin 也包含幾個(gè)要素。盡管版本控制也是其中一部分，但其余方法卻大相徑庭，這需要一些額外的要素才能發(fā)揮作用：確定性計(jì)算和將排序與鎖定分開。這些通常在具有傳統(tǒng)架構(gòu)的數(shù)據(jù)庫中找不到的要素。通過更改架構(gòu)并接受查詢必須是確定性的，Calvin 可以將跨數(shù)據(jù)中心消息的最壞情況數(shù)量減少到兩個(gè)。 這將全局事務(wù)的最壞情況延遲大大降低，并將其降低到 200 毫秒以下，或者理論上甚至低于 100 毫秒。當(dāng)然，為了相信這是可能的，您可能首先想知道它是如何工作的，所以讓我們來看一下該算法。

要素 1：版本控制

與 Percolator 和 Spanner 類似，Calvin 也依賴于版本化數(shù)據(jù)。Calvin 中的這些快照主要用于確保容錯(cuò)性。每個(gè)節(jié)點(diǎn)都存儲(chǔ)不同的快照，這些快照可以被視為檢查點(diǎn)。斷開的節(jié)點(diǎn)重新上線后，只需獲取它已見證的最后一個(gè)檢查點(diǎn)的時(shí)間戳，然后要求另一個(gè)節(jié)點(diǎn)通知它該檢查點(diǎn)之后的所有事務(wù)。

要素 2：確定性計(jì)算

許多前端開發(fā)人員都聽說過 Elm 前端框架，它實(shí)現(xiàn)了類似于 React Redux 的工作流程。Elm 比類似的基于 JavaScript 的框架具有更陡峭的學(xué)習(xí)曲線，因?yàn)樗竽鷮W(xué)習(xí)一種新語言。但是，由于該語言是函數(shù)式的（沒有副作用），因此 Elm 允許進(jìn)行一些令人印象深刻的優(yōu)化。關(guān)鍵在于 Elm 中的函數(shù)放棄了破壞性操作以成為確定性的。您可以使用相同的輸入兩次運(yùn)行相同的函數(shù)，它將始終產(chǎn)生相同的結(jié)果。由于它們是確定性的，因此 Elm 查詢現(xiàn)在可以更有效地決定如何更新視圖。

與 Elm 類似，Calvin 也放棄了一些東西來加快計(jì)算速度。在 Calvin 的情況下，我們基本上可以說，事務(wù)的結(jié)果將相同，無論是在機(jī)器 A 還是機(jī)器 B 上執(zhí)行。這似乎是顯而易見的，但數(shù)據(jù)庫通常并不保證這一點(diǎn)。請記住，SQL 允許您使用當(dāng)前時(shí)間或允許所謂的交互式事務(wù)（其中用戶輸入可以在事務(wù)中間插入），這兩者都可能違反 Calvin 提供的保證。

為了實(shí)現(xiàn)確定性計(jì)算，Calvin (1) 需要取出諸如當(dāng)前時(shí)間之類的計(jì)算并對其進(jìn)行預(yù)計(jì)算，以及 (2) 不允許交互式事務(wù)。交互式事務(wù)是指用戶啟動(dòng)事務(wù)、讀取一些數(shù)據(jù)、在中間提供一些額外的用戶輸入，然后最終進(jìn)行一些額外的計(jì)算以及一些寫入的事務(wù)。由于用戶是不可預(yù)測的，因此此類事務(wù)不是確定性的。本質(zhì)上，Calvin 用較小的便利性（交互式事務(wù)）換取了出色的性能。

將排序問題分開

數(shù)據(jù)庫花費(fèi)大量時(shí)間協(xié)商鎖，以使其看起來像系統(tǒng)正在以特定順序執(zhí)行”。如果所有需要的只是順序，也許我們可以將鎖定問題與排序問題分開。但這意味著您的事務(wù)必須是純凈的。

— Kyle Kingsbury

將事務(wù)排序問題與實(shí)際執(zhí)行分開在數(shù)據(jù)庫領(lǐng)域中已經(jīng)被考慮過很多次，但收效甚微。但是，當(dāng)您的事務(wù)是確定性時(shí)，將排序與算法的其余部分分開實(shí)際上變得可行。事實(shí)上，確定性計(jì)算和將排序與算法其余部分分開的組合非常強(qiáng)大，因?yàn)樗兄跍p少鎖的持續(xù)時(shí)間并大大減少遠(yuǎn)處節(jié)點(diǎn)之間的較慢通信（跨數(shù)據(jù)中心通信）。

更短的鎖持續(xù)時(shí)間

每當(dāng)對一部分?jǐn)?shù)據(jù)持有鎖時(shí)，這意味著使用該數(shù)據(jù)的其他查詢必須等待。因此，鎖的持續(xù)時(shí)間越短，性能就越好。下圖顯示了 Calvin 中的鎖定過程概述，以及傳統(tǒng)分布式數(shù)據(jù)庫可能如何執(zhí)行此操作。大多數(shù)數(shù)據(jù)庫會(huì)在至少就寫入內(nèi)容達(dá)成共識(shí)之前一直保持對數(shù)據(jù)的鎖定，而 Calvin 只會(huì)在所有節(jié)點(diǎn)就順序達(dá)成一致之前保持鎖定。由于計(jì)算是確定性的，并且它們都就順序達(dá)成一致，因此每個(gè)節(jié)點(diǎn)都將單獨(dú)計(jì)算并得出相同的最終結(jié)果。

減少遠(yuǎn)處節(jié)點(diǎn)之間的通信

除了鎖持續(xù)時(shí)間的優(yōu)勢外，將排序與算法的其余部分分開也需要更少的通信。正如前面使用 Cassandra 示例所解釋的那樣，分布式數(shù)據(jù)庫通常在其算法的許多階段都需要跨數(shù)據(jù)中心通信。在 Calvin 的情況下，我們唯一需要就某事達(dá)成一致的時(shí)刻是確定順序的時(shí)刻。使用 Raft 協(xié)議，這可以在兩個(gè)躍點(diǎn)內(nèi)完成，這使得能夠?yàn)樽x寫查詢實(shí)現(xiàn)低于 100 毫秒的延遲。

再加上減少的鎖定時(shí)間，這也帶來了極高的吞吐量。最初的 Calvin 論文還進(jìn)行了實(shí)驗(yàn)，表明這種方法在高爭用工作負(fù)載下顯著優(yōu)于傳統(tǒng)的分布式數(shù)據(jù)庫設(shè)計(jì)。他們在商品機(jī)器集群上每秒進(jìn)行 50 萬次事務(wù)的結(jié)果與在高端硬件上獲得的當(dāng)前世界紀(jì)錄結(jié)果相競爭。

在任何硬件上運(yùn)行

除此之外，Calvin 還具有另一個(gè)優(yōu)勢：它不再需要特定硬件才能獲得此類結(jié)果。由于 Calvin 可以在商品機(jī)器上運(yùn)行，因此它可以在任何云提供商上運(yùn)行。

2014 年 – FaunaDB 的共識(shí)風(fēng)格

要素 1：版本控制

FaunaDB 擁有自己的分布式事務(wù)協(xié)議，與 Calvin 有一些相似之處。與前一種方法一樣，F(xiàn)aunaDB 的數(shù)據(jù)也是版本化的。由于版本控制不僅對一致性模型有用，而且還具有業(yè)務(wù)價(jià)值，因此 FaunaDB 已將其機(jī)制升級為一等公民，最終用戶可以使用它。此功能實(shí)際上允許進(jìn)行時(shí)間旅行查詢。最終用戶可以在歷史數(shù)據(jù)上執(zhí)行查詢以回答以下問題：“20 天前此查詢的結(jié)果是什么？”。這對于恢復(fù)意外覆蓋的數(shù)據(jù)、審核數(shù)據(jù)更改或只是在應(yīng)用程序的功能中加入時(shí)間旅行很有用。

要素 2 和 3：確定性計(jì)算和分離

與 Calvin 一樣，F(xiàn)aunaDB 也具有確定性計(jì)算，并將排序問題與算法的其余部分分開。盡管存在相似之處，但在 FaunaDB 中計(jì)算事務(wù)發(fā)生在與 Calvin 不同的階段。Calvin 利用確定性特性在設(shè)置順序后多次執(zhí)行相同的事務(wù)，而 FaunaDB 則在就事務(wù)順序達(dá)成共識(shí)之前只計(jì)算一次。這使我們想到了第四個(gè)要素。

要素 4：樂觀計(jì)算

FaunaDB 添加了第四個(gè)要素，我們在討論快照隔離時(shí)已經(jīng)看到過：樂觀計(jì)算而不是鎖定。

FaunaDB 不會(huì)鎖定，而是會(huì)在接收事務(wù)的節(jié)點(diǎn)中樂觀地計(jì)算事務(wù)的結(jié)果一次，然后將結(jié)果和原始輸入值添加到日志中。Calvin 會(huì)將需要在事務(wù)日志中執(zhí)行的查詢保存下來，而 FaunaDB 會(huì)將計(jì)算結(jié)果和原始輸入值都保存在日志中。一旦就應(yīng)用結(jié)果的順序達(dá)成共識(shí)，F(xiàn)aunaDB 將驗(yàn)證該計(jì)算的輸入數(shù)據(jù)是否已更改（感謝版本控制）。如果輸入值已更改，則事務(wù)將中止并重新啟動(dòng)；如果輸入值保持不變，則結(jié)果將在所有節(jié)點(diǎn)上應(yīng)用，無需任何額外計(jì)算。

FaunaDB 的算法具有與 Calvin 相似的優(yōu)點(diǎn)，但減少了集群中所需的計(jì)算量。

結(jié)論

在本系列文章中，我們解釋了強(qiáng)一致性如何幫助您更有效地構(gòu)建無錯(cuò)誤的應(yīng)用程序。在本文的最后一部分，我們進(jìn)一步解釋了革命性的想法如何為新一代分布式數(shù)據(jù)庫提供動(dòng)力，這些數(shù)據(jù)庫既一致又高效。在之前的文章中，要點(diǎn)是：“一致性很重要”。在本文的最后，要點(diǎn)包含在以下內(nèi)容中：

在不久的將來，如果您閱讀到諸如以下短語：

“許多 NoSQL 數(shù)據(jù)庫不提供多個(gè)文檔的原子寫入，而反過來提供更好的性能。雖然一致性是 SQL 數(shù)據(jù)庫的另一個(gè)強(qiáng)大功能，但它會(huì)妨礙跨多個(gè)節(jié)點(diǎn)擴(kuò)展數(shù)據(jù)庫的能力，因此許多 NoSQL 數(shù)據(jù)庫放棄了一致性?！薄w移到 NoSQL 的最大挑戰(zhàn)

請意識(shí)到，現(xiàn)代算法使數(shù)據(jù)庫能夠在沒有集中化的情況下提供一致性。在本文中，我們已經(jīng)看到了一些執(zhí)行此操作的算法和數(shù)據(jù)庫示例?；谶@些算法構(gòu)建的數(shù)據(jù)庫是新一代數(shù)據(jù)庫，它們不再可以用簡單的類別（如 NoSQL、SQL 或甚至 NewSQL）來描述。

使用基于 Percolator、Spanner、Calvin 和 FaunaDB 事務(wù)協(xié)議的分布式云數(shù)據(jù)庫，您可以擁有提供更強(qiáng)一致性模型的高性能分布式數(shù)據(jù)庫。這意味著您可以構(gòu)建提供低延遲的數(shù)據(jù)密集型應(yīng)用程序，而無需擔(dān)心數(shù)據(jù)錯(cuò)誤、性能或服務(wù)配置。在這樣的系統(tǒng)中，一致性是透明的，您無需作為開發(fā)人員考慮它。下次選擇數(shù)據(jù)庫時(shí)，請選擇默認(rèn)情況下保持一致的數(shù)據(jù)庫。

文章系列

1. 你為何需要關(guān)注？
2. 可能出現(xiàn)什么問題？
3. 采用的障礙是什么？
4. 新算法如何提供幫助？

以上是一致的后端和UX：新算法如何幫助？的詳細(xì)內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！