Spanner論文出來后大家山呼萬歲，但是它是否適合業務？可能只有自己能搞明白。本文是讀spanner過程的一點小記錄，不准備全文翻譯，權當筆記。如有錯漏，煩請指正，如有見解也歡迎討論。
section 1 介紹
優點：
高可用、可擴展、（中間態的？tmp）多版本、全分布式、同步復制、對外一致的分布式事務
應用：
F1
高可用 vs 低延遲：大多數應用使用3-5個datacenter，以獲得較低延遲，可抵抗1-2個datacenter的失效
關注點：
管理復制到數據中心間的數據。同時在底層分布式系統之上提供一些數據庫功能。
因為bigtable UI不夠簡單。megastore寫吞吐低
描述：
從Bigtable類型的多版本的key-value store演變到帶有中間態多版本的數據庫。數據保存在半關系型的表中，可有多版本並被標上提交時的時間戳。老版本數據可通過時間戳訪問，可被內部機制（他們說是cop哦-_-）垃圾回收。支持事務並提供SQL接口。
復制功能各指標可配置：
數據位置（在哪個數據中心）
讀延遲（與應用的距離）
寫延遲（各副本的距離）
持久性、可用性與讀性能（副本數）
平衡各數據中心的資源使用（動態地、向上透明地在數據中心間遷移數據）
！對外一致的讀寫，各數據中心全局一致的指定時間戳的讀操作
Section 2 實現
結構
universe —— zone（可理解為對應數據中心）
universemaster（1個，顯示狀態的終端）、placement driver（1個，自動在數據中心間遷移數據，時間大概以分鍾記）
zonemaster（1個/zone，指派數據給spanserver）、location proxy（N個/zone，向client提供查詢數據所在spanserver服務）、spanserver（N個/zone，向client提供數據服務）
spanserver
自下而上包含的基本組件：colossus（GFS的進化版，據說消除了單點？未考究） -> tablet（結構化的存儲，大致對應bigtable的tablet） -> paxos（為支持高層的副本概念） -> replica（注意副本概念提升到了較高層）
寫操作需要先在leader處初始化paxos狀態，而讀操作則可直接訪問任意足夠新的replica。
相同數據的多個replica組成一個paxos組，組里的leader需要使用lock table（2PL）和transaction manager來支持並發控制（2PC）和分布式事務。其中，當不需要同步讀時（只讀操作），可以繞過lock table；當事務只涉及一個paxos組時，可繞過transaction manager（不使用2PC，減輕可用性問題，因為lock table與paxos已經保證了）。當事務涉及到多個paxos組時使用，leader與其他組的leader使用2PC進行協同，此時leader也participant leader。多個組中有一個被選作協調者coordinator，而此時的participant leader也是coordinator leader。
directory
一組帶有共同前綴的連續的key的數據集。是數據部署、遷移的單位。
遷移可線完成。50MB大小的directory可在秒級遷移完。遷移時並非從頭到尾使用事務，而是在遷移快完成時才使用，在事務中完成數據遷移及元數據的修改。
應用可指定的部署屬性的數據粒度也是directory，屬性包含兩方面：副本的數量與類型、副本的位置。
以上是簡化的說明，實際上，directory在過大時會拆成多個fragment，並分布在不同的paxos組中（因此可能在不同的機器上），數據遷移的實際上是fragment的遷移，而不是整個driectory。
！當directory拆成fragment以后，又回到了數據相關性問題，這個先放一下。
數據模型
很多人詬病2PC帶來的性能與可用性問題。可用在性方面：下層先使用paxos與2PL，上層才使用2PC，以減輕可用性問題。性能方面：作者認為控制過度使用的事務（需要用2PC的原因）比糾結沒事務要好方式的編碼要好一些。
database定義在universe上，可有多個。一個database下可有多個table（帶有行、列、
版本）。table要求定義一個有序（可排序？）的主鍵，各個table中都有主鍵到非主鍵的映射。
！數據分區后，相關性是由應用指定的。table是帶有層次結構的，最上層的是directory table，下層的可以使用INTERLEAVE IN指定其屬於哪個table。directory table中的每一條記錄（假設其主鍵為K），與所有在其下table中前以K作為主鍵前綴的記錄共同組成一個directory。
Section 3 TrueTime
定義了幾個操作，跳過沒細看，大致了解其使用到Marzullo算法、
GPS、原子鍾
TT.now() TTinterval: [earliest; latest]
TT.after(t) true if t has definitely passed
TT.before(t) true if t has definitely not arrived
TT.before(t) true if t has definitely not arrived
！以上幾個操作基於Marzullo算法，而其時間的同步則依賴於GPS和原子鍾。這種TrueTime操作給出了時序表達的另一種思路，但不能忽略其使用GPS與原子鍾的前提（還在整Logic time嗎，看看這個）
Section 4 並發控制！
！可能是論文中直接給出最有價值的內容，或者說是我最關注的點，但要注意它的實現與TrueTime機制支持分不開。
三種類型的讀寫操作：讀-寫、只讀（需要預定義）、快照讀。
重試邏輯：在服務內部重試，客戶端不需要再進行重試。
leader權使用租約（lease）機制傳遞，選舉機制是quorum vote（容錯性）。每次寫操作成功后，各replica會自動延長lease時間，而leader則會在租約快過期時，啟動新的選舉。
leader權在各replica間傳遞時"租期不相交性"是spanner后續工作（即使事務由不同leader處理，也能保證對外的一致性）的依賴之一（拗口-_-）。為了保證這個不相交性，當前leader在讓出其leader權時，必須要等到其應用過的時間戳”毫無疑問已經過期”。（此處leader指 participant leader）
讀-寫
提交使用了2PC，由應用驅動第一個phase以減少通信消耗。為了與上述的TrueTime配合來保證時序並做到對外的一致和並發控制，非coordinator leader需要向coordinator leader確認一個prepare ts，而coordinator leader則在此基礎上定出事務的commit ts。
GPS/原子鍾（全局時間同步）+ marzullo算法（估算精確時間）+ lease租期不相交性（多leader）+ 多處monotonicity機制
快照讀
快照讀可以在任意“足夠新”的replica上進行。“足夠新”是指所要讀的快照時間t在t_safe之內（t ≤ t_safe )，問題就轉移到了t_safe上：
，由兩個值中較小的一定確定。
其中，前者為replica上最后一次paxos寫操作的時間。但如果最近一次寫操作隔得比較久呢？更進方法是記錄一個后續寫事務時間的閾值（或叫分水嶺？）MinNextTS（實際上是與paxos序列ID對應的一個mapping），只要paxos安全時間不超過這個值就可以了。
而后者，則是paxos組里邊，最后一個沒有未提交（prepared but not committed）讀寫事務的時間點。由上述讀寫事務描述可知，事務的commit ts不小於各participant/replica的prepare ts，因此可以安全地選擇prepare ts作為TM安全時間的界限。
在以上的方案下，即使讀操作與當前未提交的數據沒有關聯，也需要等待，這是不合理的，簡單的只關注與自己scope相關的那部分，具體做法就是把TM的安全時間考慮粒度切分開。
只讀
首先要確定一個時間戳t_read，然后就按照快照讀的方式來讀取數據，所以問題轉換成t_read的確定方式。
最簡單的方式就是直接使用“當前時間” t.now().latest，但為了讓t ≤ t_safe成立，可能需要等待。如果應用能提供讀事務中所涉及的數據范圍（scope，單獨的事務可由spanner自行推導出scope），spanner是否能按照scope選擇一個更優的t_read？
是滴，當scope只包含一個paxos組時，t_read可以選擇該組上最后一次commit write的時間戳（記為LastTS，在沒有未提交事務時）。涉及多個組時，spanner則是直接使用上邊的t.now().latest（也就意義着需要等），原因是不想為了這個t_read實施一次協商（通信消耗啊）。注意到，在第一種情況下，如果最后一次commit write剛提交，那么即使讀操作所涉及的數據與其無關，也需要等待，改進的方法也是切小粒度。
修改schema
在使用了TrueTime機制之后，支持原子的schema修改（事務），當機器數可能達到百萬級時，這個是非常有意義的。做法就是提前注冊一個t，在這個t之前的操作可以繼續進行。而且由於它執行的速度較快，對其他操作的影響也較小。
改進
關於Paxos安全時間、TM安全時間和LastTS的選取的改進已經在上文提到了。
其他
benchmark、related work、future work等，沒有什么太大的東西，幾個
數字自己看看也就OK了（如果因為不看數字就而被以上內容忽悠，那……）。
參考資料
[1] Spanner: Google’s Globally-Distributed Database http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/spanner-osdi2012.pdf
[2] Building Spanner
http://berlinbuzzwords.de/sites/berlinbuzzwords.de/files/slides/alex_lloyd_keynote_bbuzz_2012.pdf
PS. 參考資料【2】這份keynote有一個對應的視頻，但是我沒一次能從頭看到尾（網絡啊），可自己搜索了解。