谷歌已經為她的全球分布式關系型數據庫服務云Spanner對外發布了Beta版。作為谷歌云平臺的一部分，它同時提供ACID事務和高可用性，看起來像是顛覆了CAP理論。

Spanner已經在谷歌內部廣為使用了，現在正在向公眾開放。它是一個可管理的云數據庫，可以作為谷歌云平臺的一部分使用，而且不會涉及底層的基礎設施。

Spanner看起來和傳統關系型數據庫一樣，有ACID事務、SQL、關系型模式等。但是，它是分布式的，在地理上跨谷歌基礎設施，可以滿足日益增長的更大事務處理量。除此之外，它還有強一致性，在提供數據服務時只有幾毫秒的延遲。

CAP理論證明一個數據庫系統不可能同時滿足以下三種特性：可用性、一致性和分區容忍性。關系型數據庫傾向于犧牲可用性，而NoSQL數據庫則用最終一致性換來了高可用性。

事實上Spanner也沒有顛覆CAP理論，它只是在功能上看起來像是這樣而已。谷歌基礎設施副總裁Eric Brewer解釋到：

Eric Brewer：這意味著根據CAP的定義，Spanner就是一個CA系統了嗎？從技術上來說可以直截了當地回答“不是”，但從實際效果來說，卻可以認為是“是”，用戶可以認為它就是CA的而直接使用。

Brewer總結道，在Spanner系統中，出現網絡分區的可能性是1比105。如果這種情況真的發生了，系統會選擇一致性，從技術的角度看就是CP的。但是，由于這種可能性極低，所以也可以就認為它是可用的。

在Brewer的白皮書中，他解釋這種級別的可靠性的基礎在于Spanner是運行在谷歌全球自建網絡中的。Spanner的網絡包從來不會發到公共互聯網中，而且由于冗余級別非常之高，像切斷光纖之類的災難性事件也不會導致斷網。

還有一些第三方，比如Cloudera的分布式系統工程師Henry Robinson也認可這樣的說法，他解釋道：

Henry Robinson：可以從這個角度去考慮：CAP理論告訴我們每個系統都會有她自己的阿基里斯之踵，或者說是軟脅，這就意味著在一定時間之內要放棄C或者放棄A。谷歌則把Spanner的軟脅深深地埋在了某個黑洞里。

為了確保ACID特性，Spanner實現了典型的分布式事務模型——兩階段提交。Brewer解釋說盡管這個模型要求所有的成員都必須在線，因此有些降低可用性，但Spanner通過使用一個Paxos組來繞過了這個問題，換句話說，當某些成員不在的時候，一個多數選舉的結果也可以生效。

Spanner也使用了谷歌的全球同步的鎖TrueTime。Brewer說TrueTime同時使用了GPS接收器和原子時鐘來保證時間的準確性。它可以正確地為分布式事務打上時間戳，從而保證外部一致性。

面向公眾的云Spanner仍然是Beta版，現在還可以在線上免費試用。

閱讀英文原文：Google Launches Cloud Spanner Public Beta