谷歌已經(jīng)為她的全球分布式關(guān)系型數(shù)據(jù)庫(kù)服務(wù)云Spanner對(duì)外發(fā)布了Beta版。作為谷歌云平臺(tái)的一部分，它同時(shí)提供ACID事務(wù)和高可用性，看起來(lái)像是顛覆了CAP理論。

Spanner已經(jīng)在谷歌內(nèi)部廣為使用了，現(xiàn)在正在向公眾開(kāi)放。它是一個(gè)可管理的云數(shù)據(jù)庫(kù)，可以作為谷歌云平臺(tái)的一部分使用，而且不會(huì)涉及底層的基礎(chǔ)設(shè)施。

Spanner看起來(lái)和傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)一樣，有ACID事務(wù)、SQL、關(guān)系型模式等。但是，它是分布式的，在地理上跨谷歌基礎(chǔ)設(shè)施，可以滿(mǎn)足日益增長(zhǎng)的更大事務(wù)處理量。除此之外，它還有強(qiáng)一致性，在提供數(shù)據(jù)服務(wù)時(shí)只有幾毫秒的延遲。

CAP理論證明一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)不可能同時(shí)滿(mǎn)足以下三種特性：可用性、一致性和分區(qū)容忍性。關(guān)系型數(shù)據(jù)庫(kù)傾向于犧牲可用性，而NoSQL數(shù)據(jù)庫(kù)則用最終一致性換來(lái)了高可用性。

事實(shí)上Spanner也沒(méi)有顛覆CAP理論，它只是在功能上看起來(lái)像是這樣而已。谷歌基礎(chǔ)設(shè)施副總裁Eric Brewer解釋到：

Eric Brewer：這意味著根據(jù)CAP的定義，Spanner就是一個(gè)CA系統(tǒng)了嗎？從技術(shù)上來(lái)說(shuō)可以直截了當(dāng)?shù)鼗卮?ldquo;不是”，但從實(shí)際效果來(lái)說(shuō)，卻可以認(rèn)為是“是”，用戶(hù)可以認(rèn)為它就是CA的而直接使用。

Brewer總結(jié)道，在Spanner系統(tǒng)中，出現(xiàn)網(wǎng)絡(luò)分區(qū)的可能性是1比105。如果這種情況真的發(fā)生了，系統(tǒng)會(huì)選擇一致性，從技術(shù)的角度看就是CP的。但是，由于這種可能性極低，所以也可以就認(rèn)為它是可用的。

在Brewer的白皮書(shū)中，他解釋這種級(jí)別的可靠性的基礎(chǔ)在于Spanner是運(yùn)行在谷歌全球自建網(wǎng)絡(luò)中的。Spanner的網(wǎng)絡(luò)包從來(lái)不會(huì)發(fā)到公共互聯(lián)網(wǎng)中，而且由于冗余級(jí)別非常之高，像切斷光纖之類(lèi)的災(zāi)難性事件也不會(huì)導(dǎo)致斷網(wǎng)。

還有一些第三方，比如Cloudera的分布式系統(tǒng)工程師Henry Robinson也認(rèn)可這樣的說(shuō)法，他解釋道：

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

為了確保ACID特性，Spanner實(shí)現(xiàn)了典型的分布式事務(wù)模型——兩階段提交。Brewer解釋說(shuō)盡管這個(gè)模型要求所有的成員都必須在線，因此有些降低可用性，但Spanner通過(guò)使用一個(gè)Paxos組來(lái)繞過(guò)了這個(gè)問(wèn)題，換句話說(shuō)，當(dāng)某些成員不在的時(shí)候，一個(gè)多數(shù)選舉的結(jié)果也可以生效。

Spanner也使用了谷歌的全球同步的鎖TrueTime。Brewer說(shuō)TrueTime同時(shí)使用了GPS接收器和原子時(shí)鐘來(lái)保證時(shí)間的準(zhǔn)確性。它可以正確地為分布式事務(wù)打上時(shí)間戳，從而保證外部一致性。

面向公眾的云Spanner仍然是Beta版，現(xiàn)在還可以在線上免費(fèi)試用。

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