CAP 定理

menu icon

CAP 定理

我們在本指南中探討 CAP 定理,以及它在我們設計分散式應用程式與選擇 NoSQL 或關聯式資料儲存庫時的相關性。

何謂 CAP 定理?

您有沒有看過某位庭園設計師、房屋油漆師或一些其他技師以「便宜、快速、優良:挑選其中兩個」做為標題開頭的廣告?

CAP 定理對分散式系統套用類似邏輯,亦即分散式系統只能提供三種所需特性的其中兩個: 一致性可用性 分割區容錯(CAP 中的 'C'、 'A' 和 'P')。

分散式系統是一種同時在多個節點,實體或虛擬機器上儲存資料的網路。 所有雲端應用程式都是分散式系統,因此在設計雲端應用程式時,必須瞭解 CAP 定理,以便您可以選擇能夠為應用程式提供最需要之特性的資料管理系統。

CAP 定理也稱為布魯爾定理 (Brewer’s Theorem),因為它是由 Eric A Brewer 教授在 2000 年談論分散式運算時最先提出的。 兩年後,MIT 的 Seth Gilbert 和 Nancy Lynch 兩位提出 "Brewer's Conjecture" 的證明。

說明 CAP 定理中的 'CAP'

讓我們仔細看一下 CAP 定理所指的三個分散式系統特性。

一致性

一致性表示所有用戶端可在同時看到相同資料,無論它們連接哪一個節點。 為了達到如此,每當將資料寫入某個節點時,就必須立即將它轉遞或抄寫至系統當中的所有其他節點,這樣才能將視為「成功」寫入。

可用性

可用性表示任何要求提供資料的用戶端都會獲得回應,即使一或多個節點關閉也無妨。 用另一種方式來說,分散式系統中的所有工作節點都會針對任何要求傳回有效回應,沒有任何例外。

分割區容錯

分割區 是分散式系統內部的通訊岔斷,即兩個節點之間的連線遺失或暫時延遲。 分割區容錯表示,儘管系統內部節點之間有一些通訊故障,叢集必須持續運作。

CAP 定理 NoSQL 資料庫類型

NoSQL(非關聯式)資料庫很適合用於分散式網路應用程式。 不同於可垂直擴充的 SQL(關聯式)對手,NoSQL 資料庫可橫向擴充而且重視分散設計,它們可以快速擴充由多個交互連接節點所組成的增長中網路。(查看「SQL 與 NoSQL 資料庫比較:有什麼不同?」以取得詳細資訊。)

現在,NoSQL 資料庫是根據他們所支援的兩個 CAP 特性來做分類:

  • CP 資料庫:CP 資料庫提供一致性和分割區容錯,但代價是可用性。 當任何兩個節點之間出現分割區時,系統必須關閉不一致的節點(即使其無法使用),直到解決分割區為止。
  • AP 資料庫:AP 資料庫提供可用性和分割區容錯,但代價是一致性。 當出現分割區時,所有節點保持可用,但在分割區錯誤端的那些節點可能會傳回版本比其他節點還舊的資料。(在解決分割區後,AP 資料庫通常會重新同步節點,以修復系統當中的所有不一致。)
  • CA 資料庫:CA 資料庫跨所有節點提供一致性和可用性。 不過,如果在系統中任何兩個節點之間出現分割區,它就無法完成任務,結果導致無法提供容錯。

我們最後將此類型放在最後是有原因的,因為在分散式系統中無法避免出現分割區。 因此,雖然我們可以在理論上探討 CA 分散式資料庫,但實際上 CA 分散式資料庫不可能存在。 不過,這不表示如果您的分散式應用程式不能有 CA 資料庫,有需要的話還是可以使用。 許多關聯式資料庫,例如 PostgreSQL,都提供一致性和可用性,而且可利用抄寫來部署至多個節點。

MongoDB 與 CAP 定理 (CP)

MongoDB 是熱門的 NoSQL 資料庫管理系統,其可將資料儲存為 BSON(二進位 JSON)文件。 它經常用於在多個不同位置執行的大數據和即時應用程式。 與 CAP 定理相關的 MongoDB,它是一種 CP 資料儲存庫,其中藉由維護一致性來解決網路分割區,但代價是可用性。

MongoDB 是單一主要 系統,其中每一個抄本集(IBM 外部鏈結)都只能有一個主要節點用來接收所有寫入作業。 相同抄本集中的所有其他節點都是次要節點,其中會抄寫主要節點的作業日誌,然後將它套用至自己的資料集。 依預設,用戶端也會從主要節點進行讀取,但它們也可以指定讀取喜好設定(IBM 外部鏈結),以便它們從次要節點進行讀取。

當主要節點變成無法使用時,具有最新作業日誌的次要節點將獲選為新的主要節點。 一旦所有其他次要節點都跟上新的主要節點之後,叢集就會再次變成可用。 用戶端在這個期間無法發出任何寫入要求,因此整個網路中的資料將會保持一致。

Cassandra 與 CAP 定理 (AP)

Apache Cassandra 是由 Apache Software Foundation 負責維護的開放原始碼 NoSQL 資料庫。 它是寬欄式資料庫,可讓您在分散式網路上儲存資料。 然而與 MongoDB 不同,Cassandra 擁有無主架構,因此它會有多個失敗點,而不是單一失敗點。

與 CAP 定理相關,Cassandra 是一種 AP 資料庫,它提供可用性和分割區容錯,但無法總是提供一致性。 Cassandra 沒有主要節點,因此所有節點都必須持續可用。 不過,Cassandra 讓用戶端可以隨時寫入任何節點並儘快協調不一致,藉此提供一致性

資料只有在出現網路分割區的情況下變得不一致,而且不一致很快會獲得解決,Cassandra 提供「修復」功能(IBM 外部鏈結)以協助節點跟上其同層級節點。 不過,持續可用性會導致高效能系統得在許多情況下進行取捨。

使用微服務

微服務是鬆散連結的可獨立部署應用程式元件,其擁有自己的技術堆疊,包括自己的資料庫和資料模型,並透過網路進行相互通訊。 您可以在雲端伺服器和內部部署資料中心裡執行微服務,因此它們大受混合式多雲應用程式的歡迎。

瞭解您在設計從多個位置執行的微服務型應用程式時,CAP 定理如何協助您選擇最佳資料庫。 例如,如果快速反覆運算資料模型和橫向擴充的能力對您的應用程式來說至關重要,而且您可以接受最終(相對於嚴格的)一致性,則像 Cassandra 或 Apache CouchDB 之類的 AP 資料庫可以滿足您的需求並簡化您的部署。 另一方面,如果您的應用程式高度依賴資料一致性,例如電子商務應用程式或付款服務, 您可能會選擇像 PostgreSQL 之類的關聯式資料庫。

CAP 定理與 IBM Cloud

IBM 提供全方位的完整受管理資料庫服務。 除了關聯式資料庫管理系統之外,您也可以在 IBM Cloud 上執行 MongoDBCloudant(另一種 AP 分散式資料儲存庫)、Elasticsearchetcd 及其他資料庫解決方案。

如需查看我們整體的資料庫選項(無需承諾),請註冊 IBMid 並建立您的 IBM Cloud 帳戶