Google Cloud Spanner內(nèi)部機(jī)制,您的設(shè)備不支持google play 服務(wù)

Google Cloud Spanner內(nèi)部機(jī)制

我們已經(jīng)了解了有關(guān)Google Cloud Spanner的更多內(nèi)部信息。我們從Youtube上閱讀了Spanner白皮書的某些部分以及深入的內(nèi)部內(nèi)容。我們在此處共享了視頻鏈接，但我們希望將所有學(xué)習(xí)總結(jié)在一個地方。特別感謝Deepti Srivastava（Spanner產(chǎn)品經(jīng)理）在Google Cloud Next Event中介紹了Spanner的深潛課程。

MySQL的痛苦：

在2005年，2006年，Google大規(guī)模使用MySQL。Google Adwords是使用90多個MySQL Shards存儲數(shù)據(jù)的最大平臺之一。由于進(jìn)行了一些維護(hù)，他們重新分配了MySQL群集。這個過程花了2年時間才能完成。Google知道它們的發(fā)展非常迅速，而這類數(shù)據(jù)庫在將來會很痛苦。這就是Spanner的誕生方式。

BigTable和Spanner：

一旦他們決定構(gòu)建分布式的新東西，Big Table團(tuán)隊便是開始為Spanner流程工作的團(tuán)隊。因為BigTable使用分布式過程，存儲和高可用性（或其他一些原因）。

巨人：

Colossus是從GFS派生的分布式文件系統(tǒng)。超級數(shù)據(jù)庫需要高性能的文件系統(tǒng)。此項目由BigTable團(tuán)隊啟動，BigTable由Colossus提供支持。因此，Spanner也成為了文件系統(tǒng)的巨像。

為什么選擇Spanner？

Google Adwords是基于MySQL的堆棧，新系統(tǒng)需要具有關(guān)系數(shù)據(jù)庫的基本要素，例如ACID合規(guī)性，而不受規(guī)模的限制。MySQL的痛苦在于重新分片。因此，他們想要像傳統(tǒng)的NoSQL分片這樣的分片功能，這些功能將負(fù)責(zé)重新分片和重新平衡。加上更多可用性，水平擴(kuò)展和全球分布。

Spanner架構(gòu)：

Spanner是一個全球數(shù)據(jù)庫系統(tǒng)，每個區(qū)域至少需要3個分片。每個分片將位于每個區(qū)域中。用Spanner的術(shù)語來說，分片稱為Split。如果您提供了1個Node Spanner群集，則您將在不同區(qū)域上獲得另外2個對您不可見的節(jié)點。并且計算層和存儲層是分離的。Paxos算法用于一次維護(hù)一位領(lǐng)導(dǎo)者，其余節(jié)點將成為跟隨者。

基于分區(qū)，我們將在存儲層中有更多的拆分（碎片）。每個分片將被復(fù)制到其他區(qū)域。例如：如果您在A區(qū)上有一個名為S1的分片，它將被復(fù)制到B區(qū)和C區(qū)。復(fù)制基于Leader跟隨器方法進(jìn)行。因此，Paxos將有助于維持法定人數(shù)，并有助于在失敗期間選擇新的Leader。如果您在此Split上編寫內(nèi)容，則Spanner API會知道Leaders。因此，寫入將直接轉(zhuǎn)到具有“前導(dǎo)分割”的區(qū)域。每個拆分都有自己的領(lǐng)導(dǎo)者區(qū)域。

全球強(qiáng)一致性：

當(dāng)我觀看Spanner的深潛視頻時，他們正在討論強(qiáng)大的一致性。Spanner支持所有節(jié)點（全局）之間的強(qiáng)一致性。如果您在美國地區(qū)寫東西，則可以從亞洲地區(qū)或任何其他地區(qū)讀取相同的數(shù)據(jù)。他們?nèi)绾螌崿F(xiàn)這種邏輯？它稱為TrueTime。

TrueTime：

Spanner在分布于多個數(shù)據(jù)中心的全球所有節(jié)點之間同步并維持相同的時間。硬件內(nèi)置原子鐘以維持時間。如果您查看服務(wù)器硬件機(jī)架，則該服務(wù)器有4個時間服務(wù)器。2臺服務(wù)器與GPS連接，其余2臺與原子振蕩器連接。有2種不同的振蕩器品牌，可以實現(xiàn)更好的故障轉(zhuǎn)移處理。GPS時間服務(wù)器將與振蕩器同步，以每30秒間隔同步全球數(shù)據(jù)中心的時間。

現(xiàn)在，讓我們嘗試了解這如何TrueTime幫助Spanner保持一致。

與TrueTime的一致性

要了解一致性和TrueTime之間的關(guān)系，我們必須了解Spanner中的寫操作如何工作。在每次寫操作期間，Spanner會拾取當(dāng)前的TrueTime值，并且此TrueTime時間戳記將為寫操作創(chuàng)建一個順序。因此，每次提交都附帶了時間戳。

例如：如果要在節(jié)點1上寫入數(shù)據(jù)，它將使用TrueTime時間戳提交數(shù)據(jù)，并將數(shù)據(jù)和時間戳復(fù)制到其他節(jié)點。在所有節(jié)點上，此時間戳都相同。假設(shè)我們在節(jié)點1上提交了此數(shù)據(jù)，如果您正在從節(jié)點B讀取相同的數(shù)據(jù)，那么Spanner API會向Split的負(fù)責(zé)人詢問最后提交的數(shù)據(jù)的時間戳，如果時間戳與Node A的時間戳相匹配，則數(shù)據(jù)將從節(jié)點B返回，否則將等待，直到節(jié)點A將數(shù)據(jù)同步到節(jié)點B，然后它將返回數(shù)據(jù)。

單行寫操作的生命周期：

這是單個寫入操作的生命周期。我們正在寫一行將轉(zhuǎn)到拆分2的行。現(xiàn)在，Spanner API將了解誰是拆分2的領(lǐng)導(dǎo)者節(jié)點，然后請求將進(jìn)入Zone B節(jié)點（藍(lán)色指示是領(lǐng)導(dǎo)者）。然后它將獲取鎖，將其寫入拆分。寫入完成后，它將請求發(fā)國際快遞區(qū)域A和C節(jié)點以進(jìn)行寫入。它將等待大多數(shù)節(jié)點的確認(rèn)。領(lǐng)導(dǎo)者分裂一旦獲得了大部分的認(rèn)可，便會將成功響應(yīng)發(fā)快遞給客戶。

多行寫操作：

如果要在單個事務(wù)中寫入數(shù)據(jù)，但數(shù)據(jù)位于不同的拆分中，則Spanner將以不同的方式處理它。例如：我們必須更新2行。

第1行在Split1中C區(qū)是Leader Split

第2行位于Split2中B區(qū)是Leader Split

當(dāng)我們啟動事務(wù)時，Spanner API將理解這些行處于不同的拆分中。他們將隨機(jī)選擇一個協(xié)調(diào)器區(qū)域。在我們的示例中，API選擇了區(qū)域C為協(xié)調(diào)器區(qū)域。對于多行操作將執(zhí)行以下步驟。

選擇協(xié)調(diào)器區(qū)域。（C區(qū)）

同時獲取兩個領(lǐng)導(dǎo)者分組上的數(shù)據(jù)鎖。

在兩個領(lǐng)導(dǎo)者拆分上添加新數(shù)據(jù)。領(lǐng)導(dǎo)者拆分將新數(shù)據(jù)復(fù)制到跟隨者拆分。然后從跟隨者拆分中獲得確認(rèn)（兩個拆分將等待獲得確認(rèn)）。

然后，區(qū)域B拆分將向協(xié)調(diào)器區(qū)域的拆分發(fā)快遞一條消息，表明它已完成更新并準(zhǔn)備提交。

然后，區(qū)域C中的Split1將告訴Split2，繼續(xù)并提交數(shù)據(jù)。同時，拆分1也將提交。

提交請求將轉(zhuǎn)到所有拆分（領(lǐng)導(dǎo)者和關(guān)注者），并永久提交數(shù)據(jù)。

然后，成功響應(yīng)將傳遞給客戶。

讀操作的壽命：

從Spanner讀取數(shù)據(jù)時，將從最近的關(guān)注者拆分中獲取數(shù)據(jù)。讓我們用一個例子來解釋一下。請參考下圖。

我們想從MyTable讀取值123的數(shù)據(jù)。此值存儲在Split 2中。現(xiàn)在，一旦請求到達(dá)Spanner Frontend服務(wù)器，它將了解誰是最近的關(guān)注者拆分，并將請求轉(zhuǎn)發(fā)到該拆分。在我們的情況下，區(qū)域A是最近的拆分。請求到達(dá)拆分后，該拆分將請求Leader拆分以獲取最后提交的TrueTime。然后它將時間戳與自己的時間戳進(jìn)行比較。如果兩者都匹配，它將把數(shù)據(jù)提供給應(yīng)用程序。如果時間戳不匹配，則領(lǐng)導(dǎo)者分組將要求跟隨者等待，直到將數(shù)據(jù)同步到該區(qū)域。然后拆分將為數(shù)據(jù)提供服務(wù)。

過期/時間限制為：

Spanner支持MVCC。因此，它將舊數(shù)據(jù)保留一段時間。如果我們的應(yīng)用程序可以很好地獲取舊數(shù)據(jù)（早于X秒），則無需等待領(lǐng)導(dǎo)者分裂的數(shù)據(jù)同步。例如，我們必須告訴Split我們使用15秒的舊數(shù)據(jù)就可以了，然后它將檢查提交的時間戳，該時間少于15秒，然后將舊數(shù)據(jù)提供給應(yīng)用程序。

多區(qū)域Spanner：

上面說明的所有方案都適用于單個區(qū)域（區(qū)域級別）內(nèi)的群集。但是，Spanner是為全球規(guī)模和多區(qū)域部署而構(gòu)建的。在多區(qū)域設(shè)置中，體系結(jié)構(gòu)和寫/讀操作將略有不同。在單區(qū)域概念中，我們至少需要3個區(qū)域才能創(chuàng)建集群。區(qū)域同時支持讀取和寫入。但是在多區(qū)域概念中，一個大洲將充當(dāng)領(lǐng)導(dǎo)者，而其他大洲將成為追隨者。用Spanner的話來說，我們擁有更多地區(qū)的歐洲大陸將成為法定人數(shù)。所有寫操作都將到達(dá)該大陸的任何地區(qū)。在仲裁大陸中，將有2個區(qū)域托管數(shù)據(jù)節(jié)點，而1個區(qū)域?qū)⑼泄芤娮C服務(wù)器進(jìn)行故障轉(zhuǎn)移。其他大洲將具有只讀副本節(jié)點。

多區(qū)域一致性：

在多區(qū)域群集中，寫操作始終在Quorum大陸上執(zhí)行。假設(shè)美國地區(qū)是R/W大陸，那么如果您從美國地區(qū)發(fā)快遞寫請求，則Spanner API會將其發(fā)國際快遞最近的地區(qū)，一旦提交了數(shù)據(jù)，則成功響應(yīng)將轉(zhuǎn)到客戶。如果您要從亞洲地區(qū)發(fā)快遞寫請求，則亞洲地區(qū)的API服務(wù)器會將請求放入Google的內(nèi)部網(wǎng)絡(luò)中，然后將請求發(fā)國際快遞美國地區(qū)的API服務(wù)器。然后，該美國地區(qū)API服務(wù)器將提交數(shù)據(jù)，并將成功響應(yīng)發(fā)快遞給亞洲地區(qū)客戶。

對于讀取，該過程與單個區(qū)域的概念相同，如果TrueTime匹配，則將從本地區(qū)域提供數(shù)據(jù)，否則將等待直到數(shù)據(jù)同步到本地區(qū)域然后再提供給客戶端。

結(jié)論：

我們介紹了Spanner的大多數(shù)內(nèi)部概念。但是，在Cloud Spanner中還有很多事情要學(xué)習(xí)。請參考下面的Google Cloud Next活動視頻鏈接。

特別聲明：以上文章內(nèi)容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。