【作者】魏波，中國PostgreSQL分會培訓認證總監。十多年的資料庫運維從業經驗，掌握DB2/PostgreSQL，關注開源技術，目前主要負責完善培訓認證體系、運營推廣，PG社群技術內容組織等工作。

一、 什麼是分散式資料庫

分散式系統資料庫系統原理（第三版）中的描述：“我們把分散式資料庫定義為一群分佈在計算機網路上、邏輯上相互關聯的資料庫。分散式資料庫管理系統（分散式DBMS）則是支援管理分散式資料庫的軟體系統，它使得分佈對於使用者變得透明。有時，分散式資料庫系統（Distributed Database System,DDBS）用於表示分散式資料庫和分散式DBMS這兩者。”

在以上表述中，“一群分佈在網路上、邏輯上相互關聯”是其要義。在物理上一群邏輯上相互關聯的資料庫可以分散式在一個或多個物理節點上。當然，主要還是應用在多個物理節點。這一方面是X86伺服器價效比的提升有關，另一方面是因為網際網路的發展帶來了高併發和海量資料處理的需求，原來的單物理伺服器節點不足以滿足這個需求。

分散式不只是體現在資料庫領域，也與分散式儲存、分散式中介軟體、分散式網路有著很多關聯。最終目的都是為了更好的服務於業務需求的變更。從哲學意義上理解是一種生產力的提升。

二、 分散式資料庫理論基礎

1． CAP理論

首先，分散式資料庫的技術理論是基於單節點關聯式資料庫的基本特性的繼承，主要涉及事務的ACID特性、事務日誌的容災恢復性、資料冗餘的高可用性幾個要點。

其次，分散式資料的設計要遵循CAP定理，即：一個分散式系統不可能同時滿足 一致性（ Consistency ） 、可用性 （ Availability ） 、分割槽容 忍 性 （ Partition tolerance ） 這三個基本需求，最 多隻能同時滿足其中的兩項， 分割槽容錯性 是不能放棄的，因此架構師通常是在可用性和一致性之間權衡。這裡的權衡不是簡單的完全拋棄，而是考慮業務情況作出的犧牲，或者用網際網路的一個術語“降級”來描述。

針對CAP理論，查閱了國外的相關文件表述，CAP理論來源於2002年麻省理工學院的Seth Gilbert和Nancy Lynch發表的關於Brewer猜想的正式證明。

CAP 三個特性描述如下 ：

一致性：確保分散式群集中的每個節點都返回相同的 、 最近 更新的資料 。一致性是指每個客戶端具有相同的資料檢視。有多種型別的一致性模型 ， CAP中的一致性是指線性化或順序一致性，是強一致性。

可用性：每個非失敗節點在合理的時間內返回所有讀取和寫入請求的響應。為了可用，網路分割槽兩側的每個節點必須能夠在合理的時間內做出響應。

分割槽容忍性：儘管存在網路分割槽，系統仍可繼續執行並 保證 一致性。網路分割槽已成事實。保證分割槽容忍度的分散式系統可以在分割槽修復後從分割槽進行適當的恢復。

原文主要觀點有在強調CAP理論不能簡單的理解為三選二。

在分散式資料庫管理系統中，分割槽容忍性是必須的。網路分割槽和丟棄的訊息已成事實，必須進行適當的處理。因此，系統設計人員必須在一致性和可用性之間進行權衡 。簡單地說，網路分割槽迫使設計人員選擇完美的一致性或完美的可用性。在給定情況下， 優秀 的分散式系統會根據業務對一致性和可用性需求的重要等級提供最佳的答案，但通常一致性需求等級會更高，也是最有挑戰的 。

2． BASE理論

基於CAP定理的權衡，演進出了 BASE理論 ，BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。

BA：Basically Available 基本可用，分散式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。

S：Soft State 軟狀態，允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。

E：Consistency 最終一致性，系統中的所有資料副本經過一定時間後，最終能夠達到一致的狀態。

BASE 理論本質上是對 CAP 理論的延伸，是對 CAP 中 AP 方案的一個補充。

這裡補充說明一下什麼是強一致性：

Strict Consistency （ 強一致性 ） 也稱為Atomic Consistency （ 原子一致性） 或 Linearizable Consistency（線性一致性） ，必須滿足以下 兩個要求：

1、任何一次讀都能讀到某個資料的最近一次寫的資料。

2、系統中的所有程式，看到的操作順序，都和全域性時鐘下的順序一致。

對於關係型資料庫，要求更新過的資料能被後續的訪問都能看到，這是強一致性。簡言之，在任意時刻，所有節點中的資料是一樣的。

BASE 理論的最終一致性屬於弱一致性。

接下來介紹另一個分散式資料庫重要的概念：分散式事務。瀏覽了幾篇介紹分散式事務的文章，發現會有不同的描述，但大致含義是相同的。分散式事務首先是事務， 需要滿足事務的ACID的特性。主要考慮業務訪問處理的資料分散在網路間的多節點上，對於分散式資料庫系統而言， 在保證資料一致性的要求下，進行事務的分發、協同多節點完成業務請求。

多節點能否正常、順利的協同作業完成事務是關鍵，它直接決定了訪問資料的一致性和對請求響應的及時性。從而就需要科學有效的一致性演算法來支撐。

3． 一致性演算法

目前主要的 一致性演算法 包括 ：2PC 、 3PC 、 Paxos 、 Raft 。

2PC ：Two-Phase Commit （ 二階段提交 ） 也被認為是一種一致性協議，用來保證分散式系統資料的一致性。絕大部分的關係型資料庫都是採用二階段提交協議來完成分散式事務處理。

主要包括以下兩個階段：

第一階段：提交事務請求（投票階段）

第二階段：執行事務提交（執行階段）

優點：原理簡單、實現方便

缺點：同步阻塞、單點問題、資料不一致、太過保守

3PC ：Three- Phase Commi （ 三階段提交 ）包括 CanCommit、PreCommit、doCommit 三個階段。

為了避免在通知所有參與者提交事務時，其中一個參與者 crash 不一致時，就出現了三階段提交的方式。

三階段提交在兩階段提交的基礎上增加了一個 preCommit 的過程，當所有參與者收到 preCommit 後，並不執行動作，直到收到 commit 或超過一定時間後才完成操作。

優點：降低參與者阻塞範圍，並能夠在出現單點故障後繼續達成一致 缺點：引入 preCommit 階段，在這個階段如果出現網路分割槽，協調者無法與參與者正常通訊，參與者依然會進行事務提交，造成資料不一致。

2PC / 3PC 協議用於保證屬於多個資料分片上操作的原子性。

這些資料分片可能分佈在不同的伺服器上，2PC / 3PC 協議保證多臺伺服器上的操作要麼全部成功，要麼全部失敗。

Paxos 、 Raft 、 Zab 演算法用於保證同一個資料分片的多個副本之間的資料一致性 。以下是三種演算法的概要描述 。

Paxos 演算法主要解決資料分片的單點問題 ， 目的是讓整個叢集的結點對某個值的變更達成一致。Paxos （強一致性） 屬於多數派演算法 。任何一個點都可以提出要修改某個資料的提案，是否透過這個提案取決於這個叢集中是否有超過半數的結點同意，所以 Paxos 演算法需要叢集中的結點是單數 。

Raft 演算法是簡化版的Paxos， Raft 劃分成三個子問題：一是Leader Election；二是 Log Replication；三是Safety。Raft 定義了三種角色 Leader、Follower、Candidate，最開始大家都是Follower，當Follower監聽不到Leader，就可以自己成為Candidate，發起投票 ，選出新的leader 。

其有兩個基本過程：

① Leader選舉：每個 C andidate隨機經過一定時間都會提出選舉方案，最近階段中 得 票最多者被選為 L eader。

② 同步log：L eader會找到系統中log（各種事件的發生記錄）最新的記錄，並強制所有的follow來重新整理到這個記錄。

Raft一致性演算法是透過選出一個leader來簡化日誌副本的管理，例如，日誌項（log entry）只允許從leader流向follower。ZAB基本與 raft 相同。

三、PostgreSQL 分散式架構一覽

PostgreSQL發展時間線及分支圖

1． 基於核心分散式方案 Postgres-XL

（1） 什麼是Postgres-XL

Postgres-XL是一款開源的PG叢集軟體，XL代表eXtensible Lattice，即可擴充套件的PG“格子”之意，以下簡稱PGXL。

官方稱其既適合寫操作壓力較大的OLTP應用，又適合讀操作為主的大資料應用。它的前身是Postgres-XC（簡稱PGXC），PGXC是在PG的基礎上加入了叢集功能，主要適用於OLTP應用。PGXL是在PGXC的基礎上的升級產品，加入了一些適用於OLAP應用的特性，如 Massively Parallel Processing (MPP) 特性。

通俗的說PGXL的程式碼是包含PG程式碼，使用PGXL安裝PG叢集並不需要單獨安裝PG。這樣帶來的一個問題是無法隨意選擇任意版本的PG，好在PGXL跟進PG較及時，目前最新版本Postgres-XL 10R1，基於PG 10。

社群發展史：

2004~2008 年， NTT Data 構建了模型 Rita-DB

2009 年， NTT Data 與 EnterpriseDB 合作進行社群化開發

2012 年， Postgres-XC 1.0 正式釋出

2012 年， StormDB 在 XC 基礎上增加 MPP 功能 .

2013 年， XC 1.1 釋出 ；TransLattice 收購 StormDB

2014 年， XC 1.2 釋出 ；StormDB 開源為 Postgres-XL.

2015 年，兩個社群合併為 Postgres-X2

2016 年 2 月， Postgres-XL 9.5 R1

2017年7月 ， Postgres-XL 9.5 R1.6

2018年10月 ， Postgres-XL 10R1

2019 年 2 月 ， 宣佈推出Postgres-XL 10R1 .1

PostgreSQL與PGXC對比圖（浙江移動譚峰分享）

（2） 技術架構

架構圖1

架構圖2

從上圖可以看出Coordinator和datanode節點可以配置為多個，並且可以位於不同的主機上。只有Coordinator節點直接對應用服務，Coordinator節點將資料分配儲存在多個資料節點datanode上。

Postgres-XC主要元件有gtm（Global Transaction Manager） ， gtm_standby ， gtm_proxy, Coordinator 和Datanode。

全域性事務節點 ( GTM )， 是Postgres-XC的核心元件，用於全域性事務控制以及tuple的可見性控制。gtm 為分配GXID和管理PGXC MVCC的模組 ， 在一個CLUSTER中只能有一臺主的gtm。gtm_standby 為gtm的備機 。

主要作用：

– 生成全域性唯一的事務ID

– 全域性的事務的狀態

– 序列等全域性資訊

gtm_proxy為降低gtm壓力而誕生的, 用於對coordinator節點提交的任務進行分組等操作. 機器中可以存在多個gtm_proxy。

協調節點 (Coordinator) 是資料節點 (Datanode) 與應用之間的介面， 負責接收使用者請求、生成並執行分散式查詢、 把 SQL 語句發給相應的資料節點。

Coordinator 節點並不物理上儲存表資料，表資料以分片或者複製的方式分散式儲存，表資料儲存在資料節點上。當應用發起SQL時，會先到達 Coordinator 節點，然後 Coordinator節點將 SQL分發到各個資料節點，彙總資料，這一系統過程是透過GXID 和Global Snapshot 再 來控制的。

資料節點（datanode）物理上儲存表資料，表資料儲存方式分為分片（distributed）和完全複製（replicated）兩種。資料節點只儲存本地的資料。

資料分佈

• replicated table 複製表

– 表在多個節點複製

• distributed table 分散式表

– Hash

– Round robin

註釋：Round robin 輪流放置是最簡單的劃分方法：即每條元組都會被依次放置在下一個節點上，如下圖所示，以此進行迴圈。

（3） 主要站點

2． 擴充套件分散式方案Citus

（1） 什麼是Citus

Citus是一款基於PostgreSQL的開源分散式資料庫 ， 自動繼承了PostgreSQL強大的SQL支援能力和應用生態（不僅是客戶端協議的相容還包括服務端擴充套件和管理工具的完全相容）。Citus是PostgreSQL的擴充套件（not a fork），採用shared nothing架構，節點之間無共享資料，由協調器節點和Work節點構成一個資料庫叢集。專注於高效能HTAP分散式資料庫 。

相比單機PostgreSQL，Citus可以使用更多的CPU核心，更多的記憶體數量，儲存更多的資料。透過向叢集新增節點，可以輕鬆的擴充套件資料庫。

與其他類似的基於PostgreSQL的分散式方案，比如GreenPlum，PostgreSQL-XL相比，Citus最大的不同在於它是一個PostgreSQL擴充套件而不是一個獨立的程式碼分支。Citus可以用很小的代價和更快的速度緊跟PostgreSQL的版本演進；同時又能最大程度的保證資料庫的穩定性和相容性。

Citus支援新版本PostgreSQL的特性，並保持與現有工具的相容 。Citus使用分片和複製在多臺機器上橫向擴充套件PostgreSQL。它的查詢引擎將在這些伺服器上執行SQL進行並行化查詢，以便在大型資料集上實現實時（不到一秒）的響應。

Citus目前主要分為以下幾個版本：

• Citus社群版

• Citus商業版

• Cloud [AWS，citus cloud]

本截圖引用2020年3月蘇寧陳華軍Citus的實踐分享

（2） 技術架構

本截圖引用2020年3月蘇寧陳華軍Citus的實踐分享

Citus叢集由一箇中心的協調節點(CN)和若干個工作節點(Worker)構成。

CN只儲存和資料分佈相關的後設資料，實際的表資料被分成M個分片，打散到N個Worker上。這樣的表被叫做“分片表”，可以為“分片表”的每一個分片建立多個副本，實現高可用和負載均衡。

架構圖1（引用2019年蘇寧Citus實踐分享）

Citus官方文件更建議使用PostgreSQL原生的流複製做HA，基於多副本的HA也許只適用於append only的分片。

應用將查詢傳送到協調器節點，協調器處理後傳送至work節點。對於每個查詢協調器將其路由到單個work節點，或者並行化執行，這取決於資料是否在單個節點上還是在多個節點上。Citus MX模式允許直接對work節點進行訪問，進行更快的讀取和寫入速度。

架構圖2（引用2019年蘇寧Citus實踐分享）

Citus有三種型別表

• 分片表（最常用）

• 參考表

• 本地表

分片表主要解決的是大表的水平擴容問題，對資料量不是特別大又經常需要和分片表Join的維表可以採用一種特殊的分片策略，只分1個片且每個Worker上部署1個副本，這樣的表叫做“參考表”。

除了分片表和參考表，還剩下一種沒有經過分片的PostgreSQL原生的表，被稱為“本地表”。“本地表”適用於一些特殊的場景，比如高併發的小表查詢。

本截圖引用2020年3月蘇寧陳華軍Citus的實踐分享

客戶端應用訪問資料時只和CN節點互動。CN收到SQL請求後，生成分散式執行計劃，並將各個子任務下發到相 應的Worker節點，之後收集Worker的結果，經過處理後返回最終結果給客戶端。

本截圖引用2020年3月蘇寧陳華軍Citus的實踐分享

（3） 主要站點

四、 總結

應對大資料量、高併發混合業務資料訪問，資料管理需要分散式資料庫架構的有效支撐，以下總結了幾個主要關鍵詞：

1． 業務融合——TP/AP業務自動識別，職能排程運算節點；實時流處理；關係與非關係資料訪問、轉換；

2． 節點協同——多個計算節點協同作業；資料多副本；同城、異地多活；

3． 冷熱分離——定期定時統計，自動標記冷熱資料，根據儲存速度儲存不同冷熱程度的資料；

4． 架構解耦——微服務、計算儲存分離；

5． 彈性伸縮——線上伸縮；自動平衡資料；

6． 智慧運維——自動調優；自動升降級；執行視覺化，自動告警。

參考資料：

分散式資料庫概念：

·《分散式系統資料庫系統原理》（第三版）

CAP理論 ：

·《Understanding the CAP Theorem》/ Akhil Mehra

·《CAP和BASE理論》/ ~信~仰~ 

Base理論：

·《終於有人把“分散式事務”說清楚了！》/ 陳明羽

·《強一致性、順序一致性、弱一致性和共識》/ chao2016

一致性演算法：

·《分散式理論系列（二）一致性演算法：2PC 到 3PC 到 Paxos 到 Raft 到 Zab》/ binarylei

·《Paxos和Raft快速理解》/ 建懷

PGXL

·《初識Postgres-XL》/ joyeu

Citus

· 部落格“小橋河西 ”

·《PostgreSQL中的分庫分表解決方案》/ 唐成

（連結請點選閱讀原文）

原題：分散式資料庫原理及 PostgreSQL 分散式解讀

如有任何問題，可點選文末閱讀原文，到社群原文下評論交流

覺得本文有用，請轉發或點選“在看”，讓更多同行看到

 資料/文章推薦：

• Oracle 遷移至 MySQL、PG等分散式資料庫，可能遇到的12個典型問題
  

• 分散式資料庫關鍵功能的技術現狀和發展趨勢
  

• PostgreSQL 的備份、恢復、容災 | 資料
  

• 五個PostgreSQL典型故障案例及處理

• 150 篇資料庫架構和運維知識，含Oracle、MySQL、Redis、PostgreSQL、Db2