一、 什么是分布式數據庫

分布式系統數據庫系統原理(第三版)中的描述：“我們把分布式數據庫定義為一群分布在計算機網絡上、邏輯上相互關聯的數據庫。分布式數據庫管理系統(分布式DBMS)則是支持管理分布式數據庫的軟件系統，它使得分布對于用戶變得透明。有時，分布式數據庫系統(Distributed Database System,DDBS)用于表示分布式數據庫和分布式DBMS這兩者。”

[[322120]]

在以上表述中，“一群分布在網絡上、邏輯上相互關聯”是其要義。在物理上一群邏輯上相互關聯的數據庫可以分布式在一個或多個物理節點上。當然，主要還是應用在多個物理節點。這一方面是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

從上圖可以看出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) 主要站點

https://www.postgres-xl.org/overview/

https://wiki.postgresql.org/wiki/Postgres-XC

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) 主要站點

http://citusdb.cn/

https://docs.citusdata.com/en/v8.2/

四、 總結

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

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中的分庫分表解決方案》/ 唐成