2.4　GoldenDB數據庫與CAP理論

2000年，加州大學伯克利分校的Eric Brewer教授在PODC（Principles Of Distributed Computing）座談會上首次提出了CAP設想。2002年，麻省理工學院的Seth Gilbert和Nancy Lynch證明了CAP設想的可行性，從此CAP理論成為分布式系統的定理。

CAP指的是一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）。根據分布式系統中的CAP理論，當分區故障發生時，只能在一致性和可用性之間二選一。

2.4.1　什么是CAP理論

CAP定理指出一個分布式系統在一次操作中不可能同時滿足一致性、可用性和分區容錯性，最多只能同時滿足其中的兩項。為了更好地理解CAP定理，下面分別介紹一致性、可用性和分區容錯性。

一致性（Consistency）：一致性服務最為經典的理論就是原子化數據對象。原子一致性或者線性一致性是當今Web服務的基本要求。根據一致性的要求，所有的操作必須如同在一個單獨的實例中一樣，按照線性的順序依次執行。這相當于要求分布式共享內存的請求必須如同訪問一個獨立節點一樣，在一個時間響應一個操作。一個最重要的特性就是，對于一個支持原子化讀寫請求的共享內存，當讀請求發生在寫請求成功以后，讀請求的返回值必須反映出前面寫請求操作后的結果。這種一致性約束，為使用者提供了最容易理解的模型。同時對于那些嘗試設計使用分布式服務的客戶端應用程序用戶而言，也是最方便的。

可用性（Availability）：對于一個分布式系統來說，持續可用就是指系統中沒有宕機的節點接到請求都必須產生應答。換句話說，任何服務執行的程序必須要有一個終態。在某些方面，以上對于可用性的定義要求并不高：對于程序需要執行多長時間到終態沒有限制，因此允許程序無限期地執行下去。另一方面，當系統同時具備分區容錯性時，這個要求又變得很高：當分布式系統內部的網絡崩潰了，每個請求仍然需要一個應答。

分區容錯性（Partition Tolerance）：以上關于一致性和可用性的定義都是基于系統具備分區容錯性的基礎上的。為了解釋什么是分區容錯性，將允許節點之間的網絡傳輸存在消息隨機丟失。當網絡被分區，處在該分區的一個組件的節點發往另一組件中節點的所有消息都會丟失。因此，原子性要求意味著即使作為程序執行的一部分而發送的任意消息可能沒有傳遞過去，每個響應都將是原子的?？捎眯砸笠馕吨词拱l送的消息可能會丟失，接收到客戶端請求的每個節點也必須響應。這類似于要求一個運行在純內存共享的系統中完成wait-free的程序直到終止：即使網絡中的每個其他節點都出現故障也必須生成有效的原子響應。不允許少于總網絡故障的故障導致系統響應不正確。

與集中式系統相比，分布式系統無法避免網絡故障。當分布式系統出現網絡故障時，基于CAP理論，為確保分區容錯性，只能從一致性和可用性中二者擇其一。當選擇一致性時，系統要么直接返回錯誤，要么不返回任何結果，等待觸發超時。當選擇可用性時，系統會及時給接收到的請求返回結果，但不保證結果數據是最新的。

與分布式系統不同，傳統關系數據庫遇到網絡故障時，優先選擇一致性。如圖2-22所示，Db2、Oracle和MySQL，由于沒有網絡分區，不存在分區容錯性，屬于CA類系統；又如Cassandra，通過配置副本之間策略，保證寫操作可用性，但降低了寫操作一致性，屬于AP類系統；而GoldenDB分布式數據庫，優先保證數據一致性與分區容錯性，屬于CP類系統。

2.4.2　GoldenDB保證一致性

分布式事務中的一致性和CAP理論中的一致性雖然含義不完全對等，但仍然面臨相同的問題，一致性和可用性就像是魚與熊掌不可兼得。

互聯網公司普遍采用的異步事務方案，則是另外一種選擇，采用最終一致性，犧牲事務的實時一致性，來提升系統的可用性。按照前面對金融級分布式數據庫的定義，必須優先選擇一致性，要確保數據的實時一致性，就要在系統的可用性上做一些犧牲。

2.4.3　GoldenDB最大程度保證可用性

在分布式環境下，當服務器、網絡出現故障時，為保證一致性，數據庫服務會不可用，導致可用性下降。在無法完全保證可用性的情況下，需盡可能縮短系統不可用時間，為此GoldenDB通過主從切換、HA切換自動恢復系統可用性，通過高低數值設置能夠最大程度地保障系統的可用性。

高于最高數值會有告警，低于最低數值會觸發只讀。系統可用性會有一個從正常到異常告警，再到異常不可用的一個衰減過程。如能及時響應告警、處理故障，可以保證較高的系統可用性。

2.4.4　GoldenDB保證分區容錯性

在分布式環境中，涉及的組件眾多，由于環境相較單機環境復雜，根據不同組件可分為數據節點、計算節點、全局事務管理器節點和管理節點。

1．數據節點容錯性

在分布式環境下，事務執行中發生主節點異常，未提交數據不會被同步到從節點。若出現部分提交，則進行已提交事務回滾。之后進行主從切換，在從節點切換成主節點之前，該安全組不提供讀寫服務，主從切換完成后自動恢復。

2．計算節點容錯性

計算節點本身無狀態，發生異常僅導致當前業務失敗，并且負載均衡自動屏蔽該節點，保證后續交易發往其他計算節點。對于需要進行已提交事務回滾的事務，計算節點故障無法執行。計算節點部署的監控會重啟進程，執行回滾操作。若計算節點重啟失敗，則根據配置由其他計算節點發起對等回滾操作。

3．全局事務管理器節點容錯性

一般GTM按照主從部署，通常采用一主多從模式。主機異常時會自動觸發主從切換，在從節點切換成主節點之前，不提供申請釋放GTID服務，主從切換完成后自動恢復。

4．管理節點容錯性

管理節點分為管理組件與集群元數據兩部分，通過部署雙機HA軟件搭建主從關系，管理組件安裝在主從服務器上，集群元數據存儲在主從數據庫中。若主機管理組件發生故障，雙機軟件會自動切換到從機。若主機數據庫發生故障，雙機軟件會自動切換到從機，并完成主備切換操作。