論文閱讀筆記 – Spanner: Google’sGlobally-Distributed Database

作者：劉旭暉 Raymond 轉載請註明出處

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

更多論文閱讀筆記 http://blog.csdn.net/colorant/article/details/8256145

關鍵字

Spanner,
外部一致性,
跨機房, True time

 

==
目標問題 ==

 

提供一個高效能，全球規模的分布式同步備份資料庫

 

==
核心思想 ==

 

Spanner的設計目標是支援分佈於上百個資料中心，可達百萬級數量規模伺服器的高效能資料庫。其重點在於以較高的效能提供高可靠性和跨機房的資料一致性。

 

Spanner以基於時間戳記的方式實現了資料讀寫的全域一致性，而在全球規模的資料庫中高效的實現這一點，其關鍵在於底層的TrueTime
API的實現。

 

TrueTime API
的實現基於GPS和原子鐘，在全球範圍內保證各個伺服器取得的時間的絕對誤差在1-7毫秒層級以內

 

在TrueTime API提供的精確時間戳記的基礎上，Spanner通過Paxos選舉出來的Leader協調和管理兩階段commit的絕對時間和提交次序，進而保證資料的讀寫一致性。

 

==
實現 ==

 

Spanner的一個叢集部署稱為一個Universe，每個Universe由眾多Zone組成，每個Zone大致可以類比為一個BigTable的叢集。Zone內部包含一個ZoneMaster管理資料分配，數百到上千個SpanServer負責實際的資料存放區和查詢，若干Location
Proxy用來路由用戶端到特定的SpanServer。UniverseMaster僅起到效能資料監控的作用。每個Zone都是一個物理隔離的單位，Placement
Driver負責資料在各個Zone之間進行備份和遷移。

 

 

SpanServer內部的資料群組織形式類似於BigTable的Tablet，但是從論文上看起來，和Bigtable並沒有任何關係。每個SpanServer管理數百到上千個Tablet（包含類似多版本的Key->Value映射形式的資料）每個Tablet之上都架構了一個Paxos狀態機器用於協同並行作業。底層檔案系統為Colossus（號稱GFS的下一代，沒有查到相關文獻。。。）

 

 

所有的寫操作必須要由Leader發起，而讀操作可以由資料時間戳記滿足更新狀態的伺服器直接完成。在跨Tablet的操作中，各個Paxosgroup的leader會進行協同工作。

  

==
相關研究，項目等 ==

 

Spanner的設計目標和Megastore很相似，Megastore的問題在於並發的寫操作的吞吐率可能很差。沒有詳細的同類應用場合的測試資料作比較，只能相信Spanner論文的說法。從粗略的原理上看，個人理解Spanner能做得更好的原因大概是：

1. 更細力度的Paxos狀態機器(Tablet
   v.s. entity group)減少了衝突的可能性

1. Megastore的底層架構在HBase上，通訊開銷較大，Spanner直接管理Tablet，簡化了層次

1. True Time API base的全域一致性的支援，簡化了並發讀寫的實現邏輯（這點還要好好體會一下）