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 ！以上幾個操作基于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有一個對應的視頻，但是我沒一次能從頭看到尾（網絡啊），可自己搜索了解。

轉載于:https://www.cnblogs.com/sunyongyue/archive/2012/09/20/spanner_note.html

總結

以上是生活随笔為你收集整理的Spanner——Google的全球化分布式数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

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