分布式數據庫原理和PostgreSQL 分布式架構是怎樣的

151次閱讀

共計 5929 個字符，預計需要花費 15 分鐘才能閱讀完成。

分布式數據庫原理和 PostgreSQL 分布式架構是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

一、什么是分布式數據庫

分布式系統數據庫系統原理 (第三版) 中的描述：“我們把分布式數據庫定義為一群分布在計算機網絡上、邏輯上相互關聯的數據庫。分布式數據庫管理系統 (分布式 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。

(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 輪流放置是最簡單的劃分方法：即每條元組都會被依次放置在下一個節點上，如下圖所示，以此進行循環。

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]

(2) 技術架構

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

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

架構圖 1

Citus 官方文檔更建議使用 PostgreSQL 原生的流復制做 HA，基于多副本的 HA 也許只適用于 append only 的分片。

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