Google Cloud Spanner內部機制,google pixel 7pro上市時間

Google Cloud Spanner內部機制,google pixel 7pro上市時間

Google Cloud Spanner內部機制

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

MySQL的痛苦：

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

BigTable和Spanner：

一旦他們決定構建分佈式的新東西，Big Table團隊便是開始爲Spanner流程工作的團隊。因爲BigTable使用分佈式過程，存儲和高可用性（或其他一些原因）。

巨人：

Colossus是從GFS派生的分佈式文件系統。超級數據庫需要高性能的文件系統。此項目由BigTable團隊啓動，BigTable由Colossus提供支持。因此，Spanner也成爲了文件系統的巨像。

爲什麼選擇Spanner？

Google Adwords是基於MySQL的堆棧，新系統需要具有關係數據庫的基本要素，例如ACID合規性，而不受規模的限制。MySQL的痛苦在於重新分片。因此，他們想要像傳統的NoSQL分片這樣的分片功能，這些功能將負責重新分片和重新平衡。加上更多可用性，水平擴展和全球分佈。

Spanner架構：

Spanner是一個全球數據庫系統，每個區域至少需要3個分片。每個分片將位於每個區域中。用Spanner的術語來說，分片稱爲Split。如果您提供了1個Node Spanner羣集，則您將在不同區域上獲得另外2個對您不可見的節點。並且計算層和存儲層是分離的。Paxos算法用於一次維護一位領導者，其餘節點將成爲跟隨者。

基於分區，我們將在存儲層中有更多的拆分（碎片）。每個分片將被複制到其他區域。例如：如果您在A區上有一個名爲S1的分片，它將被複制到B區和C區。複製基於Leader跟隨器方法進行。因此，Paxos將有助於維持法定人數，並有助於在失敗期間選擇新的Leader。如果您在此Split上編寫內容，則Spanner API會知道Leaders。因此，寫入將直接轉到具有“前導分割”的區域。每個拆分都有自己的領導者區域。

全球強一致性：

當我觀看Spanner的深潛視頻時，他們正在討論強大的一致性。Spanner支持所有節點（全局）之間的強一致性。如果您在美國地區寫東西，則可以從亞洲地區或任何其他地區讀取相同的數據。他們如何實現這種邏輯？它稱爲TrueTime。

TrueTime：

Spanner在分佈於多個數據中心的全球所有節點之間同步並維持相同的時間。硬件內置原子鐘以維持時間。如果您查看服務器硬件機架，則該服務器有4個時間服務器。2臺服務器與GPS連接，其餘2臺與原子振盪器連接。有2種不同的振盪器品牌，可以實現更好的故障轉移處理。GPS時間服務器將與振盪器同步，以每30秒間隔同步全球數據中心的時間。

現在，讓我們嘗試瞭解這如何TrueTime幫助Spanner保持一致。

與TrueTime的一致性

要了解一致性和TrueTime之間的關係，我們必須瞭解Spanner中的寫操作如何工作。在每次寫操作期間，Spanner會拾取當前的TrueTime值，並且此TrueTime時間戳記將爲寫操作創建一個順序。因此，每次提交都附帶了時間戳。

例如：如果要在節點1上寫入數據，它將使用TrueTime時間戳提交數據，並將數據和時間戳複製到其他節點。在所有節點上，此時間戳都相同。假設我們在節點1上提交了此數據，如果您正在從節點B讀取相同的數據，那麼Spanner API會向Split的負責人詢問最後提交的數據的時間戳，如果時間戳與Node A的時間戳相匹配，則數據將從節點B返回，否則將等待，直到節點A將數據同步到節點B，然後它將返回數據。

單行寫操作的生命週期：

這是單個寫入操作的生命週期。我們正在寫一行將轉到拆分2的行。現在，Spanner API將瞭解誰是拆分2的領導者節點，然後請求將進入Zone B節點（藍色指示是領導者）。然後它將獲取鎖，將其寫入拆分。寫入完成後，它將請求發國際快遞區域A和C節點以進行寫入。它將等待大多數節點的確認。領導者分裂一旦獲得了大部分的認可，便會將成功響應發快遞給客戶。

多行寫操作：

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

第1行在Split1中C區是Leader Split

第2行位於Split2中B區是Leader Split

當我們啓動事務時，Spanner API將理解這些行處於不同的拆分中。他們將隨機選擇一個協調器區域。在我們的示例中，API選擇了區域C爲協調器區域。對於多行操作將執行以下步驟。

選擇協調器區域。（C區）

同時獲取兩個領導者分組上的數據鎖。

在兩個領導者拆分上添加新數據。領導者拆分將新數據複製到跟隨者拆分。然後從跟隨者拆分中獲得確認（兩個拆分將等待獲得確認）。

然後，區域B拆分將向協調器區域的拆分發快遞一條消息，表明它已完成更新並準備提交。

然後，區域C中的Split1將告訴Split2，繼續並提交數據。同時，拆分1也將提交。

提交請求將轉到所有拆分（領導者和關注者），並永久提交數據。

然後，成功響應將傳遞給客戶。

讀操作的壽命：

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

我們想從MyTable讀取值123的數據。此值存儲在Split 2中。現在，一旦請求到達Spanner Frontend服務器，它將瞭解誰是最近的關注者拆分，並將請求轉發到該拆分。在我們的情況下，區域A是最近的拆分。請求到達拆分後，該拆分將請求Leader拆分以獲取最後提交的TrueTime。然後它將時間戳與自己的時間戳進行比較。如果兩者都匹配，它將把數據提供給應用程序。如果時間戳不匹配，則領導者分組將要求跟隨者等待，直到將數據同步到該區域。然後拆分將爲數據提供服務。

過期/時間限制爲：

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

多區域Spanner：

上面說明的所有方案都適用於單個區域（區域級別）內的羣集。但是，Spanner是爲全球規模和多區域部署而構建的。在多區域設置中，體系結構和寫/讀操作將略有不同。在單區域概念中，我們至少需要3個區域才能創建集羣。區域同時支持讀取和寫入。但是在多區域概念中，一個大洲將充當領導者，而其他大洲將成爲追隨者。用Spanner的話來說，我們擁有更多地區的歐洲大陸將成爲法定人數。所有寫操作都將到達該大陸的任何地區。在仲裁大陸中，將有2個區域託管數據節點，而1個區域將託管見證服務器進行故障轉移。其他大洲將具有隻讀副本節點。

多區域一致性：

在多區域羣集中，寫操作始終在Quorum大陸上執行。假設美國地區是R/W大陸，那麼如果您從美國地區發快遞寫請求，則Spanner API會將其發國際快遞最近的地區，一旦提交了數據，則成功響應將轉到客戶。如果您要從亞洲地區發快遞寫請求，則亞洲地區的API服務器會將請求放入Google的內部網絡中，然後將請求發國際快遞美國地區的API服務器。然後，該美國地區API服務器將提交數據，並將成功響應發快遞給亞洲地區客戶。

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

結論：

我們介紹了Spanner的大多數內部概念。但是，在Cloud Spanner中還有很多事情要學習。請參考下面的Google Cloud Next活動視頻鏈接。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關於作品內容、版權或其它問題請於作品發表後的30日內與ESG跨境電商聯繫。