Google Spanner 論文筆記

• • 架構
  • 復制與一致性
  • TrueTime
  • 事務
  • 數據遷移

Google Spanner是谷歌的全球級分布式數據庫（Golbally-Distributed Database）。Spanner的擴展性達到了全球級，可以擴展到數百個數據中心，數百萬臺機器，上萬億行數據，除了夸張的可擴展性之外，他還能通過同步復制和多版本控制MVCC來滿足外部一致性。支持垮數據中心的事務。是一個大規模分布式技術和傳統關系型數據庫技術的完美融合。

架構

Spanner的模型和MegaStore系統較為相似

如圖，Spanner的表示層次化的，最底層的表是目錄表（Directory），可以通過INTERLEAVE IN PARENT來表示層次關系。相當于Megastore中的EG。同一個目錄會分配到同一臺機器（當然，同一個目錄會復制多分以達到容錯性）。因此，針對同一個目錄的讀寫事務大部分情況下都不會設計跨機操作。

Spanner構建在Google下一代分布式文件系統Colossus上，由于其全球性的部署理念，它引入了很多其他分布式系統沒有的概念：

• Universe：一個spanner部署實例稱為一個Universe。全世界只有三個Universe：一個開發，一個測試，一個線上
• Zones：每個zone屬于一個數據中心，zone內部網路通信代價較低。每一個zone由一個zone master和100~1000個span server組成。zone master有一個熱備。

Spanner包含以下組件：

Universe Master：監控Universe里Zone級別里的信息

Placement Driver：提供跨Zone的數據遷移能力

Location Proxy：提供獲取數據位置信息的能力

Spanserver：提供存儲服務，功能上相當于Bigtable系統中的TabletServer

每一個Spanserver上有100-1000個tablet，和Bigtable中tablet類似，spanner中的tablet也包含時間戳

復制與一致性

每個zone都運行著一套Colossus提供存儲服務。每個spanserver中的tablet都維護者自己的paxos state machine，通過paxos選出一個leader，leader有10秒鐘的lease時間。

Spanner垮數據中心的一致性也是通過paxos來保證的。另外每個tablet的主副本可以通過表級鎖的方式進行并發控制。鎖表可以實現單個paxos組內事務，垮paxos組的事務需要通過在主副本上的事務管理器進行，用到了兩階段提交協議。有一個paxos組的主副本成為當前垮組事務的leader協調者（coordinator leader），其他成為參與者（participant leaders）。

TrueTime

為了實現并發控制，需要給事務分配全局唯一的事務ID，在spanner這么大規模的分布式系統中，使用全球時鐘同步機制TrueTime。其實現的基礎是GPS和原子鐘。

由于在分布式系統中，各個節點的時鐘不可避免的存在誤差，因此多數系統會采用一個中心節點來進行授時（例如tidb的pd），但是對于谷歌這樣讓數據全球分布的需求而言，使用中心化節點從延時和性能上代價太大，因此谷歌開發了TrueTime API，它提供了下面三個接口。

MethodReturn

TT.now()	返回一個范圍區間[𝑒𝑎𝑟𝑙𝑖𝑒𝑠𝑡, 𝑙𝑎𝑡𝑒𝑠𝑡], 當前的真實時間位于這個區間中
TT.after(t)	如果確保當前真實時間已經超過t，則返回true
TT.before(t)	如果確保當前真實時間還未到t，則返回true

事務

Spanner除支持快照讀外，還支持ACID事務讀寫操作。所有的讀操作都是非阻塞、無鎖的。讀操作使用了多版本技術，版本號就是時鐘時間。

Spanner使用TrueTime來控制并發，實現外部一致性，支持以下幾種事務：

讀寫事務

只讀事務

快照讀，客戶端提供時間戳

快照讀，客戶端提供時間范圍

使用TreuTime作為事務并發控制，其核心思想在于：考慮事務A的commit操作早于事務B，要將原子鐘的誤差考慮進去。Spanner使用了一種成為延時提交（Commit Wait）的手段，假設原子鐘的誤差是ε，則事務B要在事務A提交之后再過ε的時間才能提交，這意味著寫事務的時延至少是2ε

引入TrueTime的難點在于：機器時間drift引起的多機時鐘無法同步，從而使得，由于不同事務參與的集群和他們的時鐘不同，則使全部數據庫的commit時間戳混亂，無法與真實事件發生順序一致。所以我們需要原子鐘保證機器間的時間差不超過ε，并且Coordinator選完commit時間戳之后等待ε的時間才廣播commit，這樣保證所有參加此事務的participant的本地時鐘已經超過commit時間戳的值。

我們可以看到：Spanner由于commit等待，ε越大，寫的latency越高，單線程throughput越低。

在討論過TrueTime后，我們后面的討論在不考慮誤差的情況下進行：

事務只涉及一個Paxos組

讀寫事務步驟：

獲取當前時間戳

執行讀寫操作，并將時間戳一并提交

只讀事務步驟：

獲取當前時間戳

通過MVCC獲取當前應該讀取的版本

由于快照度會自帶時間戳，因此會獲取指定時間戳版本的數據，而不是當前時間戳版本

事務設計多個Paxos組：

讀寫事務需要執行兩階段提交，步驟如下：

Prepare：客戶端將數據發往多個paxos的主副本，協調者主副本發起prepare，其他participant需要鎖住對應的資源

Commit：協調者發起Commit，讓每一個participant執行commit，該事物使用協調者本地當前時間戳作為事務版本ID

只讀事務流程在單個Paxos組內的操作同上，需要注意的是，只讀事務需要保證不會讀到不完整的事務，假設讀到一個事務只進行到prepare階段，需要等一會，事務提交之后才能讀到爭取的數據。

數據遷移

spanner系統設計的重要目標就是垮數據中心的數據可用已經重新平衡數據的能力，所以這一點在spanner上很重要。

之前講了Directory目錄是數據分區的基本單位，目錄可以在paxos組之間移動，有下面幾種情況會涉及目錄遷移：

負載均衡

將目錄遷移到和用戶更近的地方，降低時延

把經常一起訪問的目錄放在同一個Paxos組（多個directory可以放在同一個paxos組中）

總結

以上是生活随笔為你收集整理的Google Spanner 论文笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。