作者：劉旭晖 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能做得更好的原因大概是：
- 更細力度的Paxos狀态機(Tablet v.s. entity group)減少了沖突的可能性
- Megastore的底層架構在HBase上，通訊開銷較大，Spanner直接管理Tablet，簡化了層次
- True Time API base的全局一緻性的支援，簡化了并發讀寫的實作邏輯（這點還要好好體會一下）