2月14日，Google 宣布推出 Cloud Spanner 云端數據庫服務的 Beta 版。Cloud Spanner 是構建在 Google Cloud Platform（GCP）平臺上的全球級分布式關系型數據庫服務，主要為 OLTP 場景的核心業務應用提供服務。不同于 Bigtable、Cloud SQL 和 Cloud Datastore，此次 Google 發布的 Cloud Spanner 打破了傳統關系型數據庫與 NoSQL 數據庫之間的壁壘，讓開發者可以使用到兼具二者優點的新型數據庫：支持 ACID 事務及 SQL 語義，同時具備水平擴展和跨數據中心高可用。

1. 什么是 Cloud Spanner?

Cloud Spanner 提供（跨區域/跨數據中心）分布式關系型數據庫服務，即所謂 NewSQL 數據庫服務：

分布式、橫向擴展（ NoSQL 數據庫）；

關系語義：Schema, ACID 事務和 SQL 查詢（傳統關系型數據庫）。

Cloud Spanner 可以橫向擴展到跨區域、跨數據中心的幾百個甚至幾千個節點，同時保證全局強一致性的事務。橫向擴展使得 Cloud Spanner 服務既是高可用的（一個實例失效，還有其他實例），又具備高吞吐能力（多實例并行處理）。

注 1： Cloud Spanner 只支持 SQL 查詢，即支持讀操作。寫操作是自定義的 API [2]。

2. 這算是打破 CAP 定理了嗎？

且慢，這是說 Cloud Spanner 同時提供了強一致性和高可用性嗎？ CAP 定理指出一個分布式系統，下列三個特性只能同時實現兩個：

一致性（Consistency）：分布式共享的數據只能有一個值；

可用性（Availability）：讀寫操作都是 100% 可用；

分區（Partition）：能夠容忍網絡分區。

在廣域網環境中，通常認為網絡分區是不可避免的，分布式系統只能是一個 CP 系統或 AP 系統。為什么 Cloud Spanner 能夠實現一個 CA 系統呢？

Eric Brewer 指出 [3, 4] ，嚴格地說， Cloud Spanner 并非一個 CA 系統，但從實際效果看，“仿佛就是”一個 CA 系統。

首先， Cloud Spanner 確實會發生網絡分區，此時它會選擇 C 而不保證 A 。因此，理論層面上， Cloud Spanner 實際上是一個 CP 系統。

其次， Cloud Spanner 實際上能夠提供 5 個 9 以上的可用性，這對于大多數應用來說，足以視為高可用。

注 2：這個可用性是根據 Google 及已有客戶使用 Spanner 服務的實際情況計算的。不能保證所有的應用都能達到這個程度的可用性。

3. 所謂的高可用性，究竟是指什么？

現在的問題是：一個跨區域、跨數據中心的 CP 式分布式系統，高可用的定義是什么？如何保證高可用性？

可用性的定義：確定停用時間區間，觀察一段時間內服務的停用情況。如果在某個時間點服務停用，只有當停用時間超過時間區間，才會真正被算為服務停用。如果還沒到一個時間區間就已經恢復服務，則不算服務停用。

舉個例子，假設停用時間區間是 10 分鐘，觀察 1000 分鐘的服務。共發生 2 次服務停用。第一次，5 分鐘后服務恢復；第二次， 12 分鐘后服務恢復正常。只有第二次才會被視為發生了服務停用，所有該服務的可用性是 1 - 1/100 = 0.99 。

什么叫高可用？首先，服務實際上具有很高的可用性，用戶的應用程序中無需包含專門處理服務停用的代碼。像 Google 內部使用的 Spanner 服務，雖然達不到 100% 可用性，但是遠超 5 個 9 的可用性。從 Google 和客戶實際使用的情況看，可以視為一個高可用的系統。

注 3：Cloud Spanner 與 Spanner 不同，可用性估計會低一些，因此號稱是 5 個 9 的可用性。但是計算可用性時，沒說停用時間區間是多少。

其次，引發服務故障（包括停用）的原因很多。這里討論 Cloud Spanner 可用性的前提是客戶端工作正常，能夠發送請求，因此能夠發現服務是否停用。顯然，僅考慮這種情況計算得到的服務可用性，比 Spanner 真正的可用性要高很多。

最后，由于 Spanner 采用特殊的網絡技術，在實踐中，幾乎不會發生網絡分區。因此，不考慮因為網絡分區導致的服務不可用。

總而言之，說 Cloud Spanner 高可用是指：

實踐中，系統處于 CA 狀態的概率非常高，用戶不需要編寫處理服務停用的代碼；

如果發生了服務停用，原因是網絡分區的可能性也非常非常小。

4. Cloud Spanner 高可用性究竟是如何實現的？

Google 打造了私有的全球網絡。以 Spanner 服務為例，所有的路由器和鏈接（除了客戶端與服務的鏈接）都是由 Google 控制的。每個數據中心都至少有 3 條獨立光纖連接到私有全球網，保證任何兩個數據中心之間都有多條物理路徑。在同一個數據中心內，網絡設備和路徑也是冗余的。因此，不會出現因為網絡路徑中斷引發的網絡分區。

如果配置不當或者軟件升級，導致多條路徑同時中斷，就會引發網絡分區。因此，采用部分升級的策略，即每次升級影響到部分路徑或副本，確保無虞之后，再全面升級。

當然，除了網絡分區，還有很多原因能夠引發服務停用。實際上，在所有引發服務事故（包括停用）的原因中，與網絡相關的僅占 8% 左右。既然 Google 用私有全球網絡解決了網絡分區的問題，那么剩下那些問題如何解決？答案很簡單：他們有一只厲害的運維隊伍。

注 4：討論了半天，實質上是告誡大家別想著達到 Google 的高可用性了。你有錢打造私有全球網嗎？你有高效的運維隊伍嗎？沒有，就購買 Google 托管的 Cloud Spanner 服務吧。

一個現實的問題是：即使采用上述手段，使得網絡分區的可能性大大降低，接近于零。畢竟還不是零，萬一發生了網絡分區呢？ 答案是：如果發生網絡分區， Cloud Spanner 將保證強一致性，不管可用性。至于如何保證強一致性，那是另外一個需要詳細討論的問題了。

參考資料

[1] Introducing Cloud Spanner: a global database service for mission-critical applications

[2] Cockroach Labs CTO 談 Cloud Spanner

[3] Inside Cloud Spanner and the CAP Theorem

[4] Spanner, TrueTime and the CAP Theorem

[5] Google 今日發布 Cloud Spanner，這些內容你可能想知道