分布式數(shù)據(jù)庫原理和PostgreSQL 分布式架構(gòu)是怎樣的

分布式數(shù)據(jù)庫原理和PostgreSQL 分布式架構(gòu)是怎樣的，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

 一、 什么是分布式數(shù)據(jù)庫

分布式系統(tǒng)數(shù)據(jù)庫系統(tǒng)原理(第三版)中的描述：“我們把分布式數(shù)據(jù)庫定義為一群分布在計算機網(wǎng)絡(luò)上、邏輯上相互關(guān)聯(lián)的數(shù)據(jù)庫。分布式數(shù)據(jù)庫管理系統(tǒng)(分布式DBMS)則是支持管理分布式數(shù)據(jù)庫的軟件系統(tǒng)，它使得分布對于用戶變得透明。有時，分布式數(shù)據(jù)庫系統(tǒng)(Distributed  Database System,DDBS)用于表示分布式數(shù)據(jù)庫和分布式DBMS這兩者?！?/p>

在以上表述中，“一群分布在網(wǎng)絡(luò)上、邏輯上相互關(guān)聯(lián)”是其要義。在物理上一群邏輯上相互關(guān)聯(lián)的數(shù)據(jù)庫可以分布式在一個或多個物理節(jié)點上。當(dāng)然，主要還是應(yīng)用在多個物理節(jié)點。這一方面是X86服務(wù)器性價比的提升有關(guān)，另一方面是因為互聯(lián)網(wǎng)的發(fā)展帶來了高并發(fā)和海量數(shù)據(jù)處理的需求，原來的單物理服務(wù)器節(jié)點不足以滿足這個需求。

分布式不只是體現(xiàn)在數(shù)據(jù)庫領(lǐng)域，也與分布式存儲、分布式中間件、分布式網(wǎng)絡(luò)有著很多關(guān)聯(lián)。最終目的都是為了更好的服務(wù)于業(yè)務(wù)需求的變更。從哲學(xué)意義上理解是一種生產(chǎn)力的提升。

二、 分布式數(shù)據(jù)庫理論基礎(chǔ)

1. CAP理論

首先，分布式數(shù)據(jù)庫的技術(shù)理論是基于單節(jié)點關(guān)系數(shù)據(jù)庫的基本特性的繼承，主要涉及事務(wù)的ACID特性、事務(wù)日志的容災(zāi)恢復(fù)性、數(shù)據(jù)冗余的高可用性幾個要點。

其次，分布式數(shù)據(jù)的設(shè)計要遵循CAP定理，即：一個分布式系統(tǒng)不可能同時滿足 一致性( Consistency ) 、可用性 ( Availability )  、分區(qū)容 忍 性 ( Partition tolerance ) 這三個基本需求，最 多只能同時滿足其中的兩項， 分區(qū)容錯性  是不能放棄的，因此架構(gòu)師通常是在可用性和一致性之間權(quán)衡。這里的權(quán)衡不是簡單的完全拋棄，而是考慮業(yè)務(wù)情況作出的犧牲，或者用互聯(lián)網(wǎng)的一個術(shù)語“降級”來描述。

針對CAP理論，查閱了國外的相關(guān)文檔表述，CAP理論來源于2002年麻省理工學(xué)院的Seth Gilbert和Nancy  Lynch發(fā)表的關(guān)于Brewer猜想的正式證明。

CAP 三個特性描述如下 ：

一致性：確保分布式群集中的每個節(jié)點都返回相同的 、 最近 更新的數(shù)據(jù) 。一致性是指每個客戶端具有相同的數(shù)據(jù)視圖。有多種類型的一致性模型 ，  CAP中的一致性是指線性化或順序一致性，是強一致性。

可用性：每個非失敗節(jié)點在合理的時間內(nèi)返回所有讀取和寫入請求的響應(yīng)。為了可用，網(wǎng)絡(luò)分區(qū)兩側(cè)的每個節(jié)點必須能夠在合理的時間內(nèi)做出響應(yīng)。

分區(qū)容忍性：盡管存在網(wǎng)絡(luò)分區(qū)，系統(tǒng)仍可繼續(xù)運行并 保證 一致性。網(wǎng)絡(luò)分區(qū)已成事實。保證分區(qū)容忍度的分布式系統(tǒng)可以在分區(qū)修復(fù)后從分區(qū)進行適當(dāng)?shù)幕謴?fù)。

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

在分布式數(shù)據(jù)庫管理系統(tǒng)中，分區(qū)容忍性是必須的。網(wǎng)絡(luò)分區(qū)和丟棄的消息已成事實，必須進行適當(dāng)?shù)奶幚怼Ｒ虼耍到y(tǒng)設(shè)計人員必須在一致性和可用性之間進行權(quán)衡  。簡單地說，網(wǎng)絡(luò)分區(qū)迫使設(shè)計人員選擇完美的一致性或完美的可用性。在給定情況下， 優(yōu)秀  的分布式系統(tǒng)會根據(jù)業(yè)務(wù)對一致性和可用性需求的重要等級提供最佳的答案，但通常一致性需求等級會更高，也是最有挑戰(zhàn)的 。

2. BASE理論

基于CAP定理的權(quán)衡，演進出了 BASE理論 ，BASE是Basically Available(基本可用)、Soft  state(軟狀態(tài))和Eventually  consistent(最終一致性)三個短語的縮寫。BASE理論的核心思想是：即使無法做到強一致性，但每個應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。

BA：Basically Available 基本可用，分布式系統(tǒng)在出現(xiàn)故障的時候，允許損失部分可用性，即保證核心可用。

s：soft State 軟狀態(tài)，允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會影響系統(tǒng)整體可用性。

E：Consistency 最終一致性，系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時間后，最終能夠達到一致的狀態(tài)。

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

這里補充說明一下什么是強一致性：

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

1、任何一次讀都能讀到某個數(shù)據(jù)的最近一次寫的數(shù)據(jù)。

2、系統(tǒng)中的所有進程，看到的操作順序，都和全局時鐘下的順序一致。

對于關(guān)系型數(shù)據(jù)庫，要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到，這是強一致性。簡言之，在任意時刻，所有節(jié)點中的數(shù)據(jù)是一樣的。

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

接下來介紹另一個分布式數(shù)據(jù)庫重要的概念：分布式事務(wù)。瀏覽了幾篇介紹分布式事務(wù)的文章，發(fā)現(xiàn)會有不同的描述，但大致含義是相同的。分布式事務(wù)首先是事務(wù)，  需要滿足事務(wù)的ACID的特性。主要考慮業(yè)務(wù)訪問處理的數(shù)據(jù)分散在網(wǎng)絡(luò)間的多節(jié)點上，對于分布式數(shù)據(jù)庫系統(tǒng)而言，  在保證數(shù)據(jù)一致性的要求下，進行事務(wù)的分發(fā)、協(xié)同多節(jié)點完成業(yè)務(wù)請求。

多節(jié)點能否正常、順利的協(xié)同作業(yè)完成事務(wù)是關(guān)鍵，它直接決定了訪問數(shù)據(jù)的一致性和對請求響應(yīng)的及時性。從而就需要科學(xué)有效的一致性算法來支撐。

3. 一致性算法

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

2PC ：Two-Phase Commit ( 二階段提交 )  也被認為是一種一致性協(xié)議，用來保證分布式系統(tǒng)數(shù)據(jù)的一致性。絕大部分的關(guān)系型數(shù)據(jù)庫都是采用二階段提交協(xié)議來完成分布式事務(wù)處理。

主要包括以下兩個階段：

第一階段：提交事務(wù)請求(投票階段)

第二階段：執(zhí)行事務(wù)提交(執(zhí)行階段)

優(yōu)點：原理簡單、實現(xiàn)方便

缺點：同步阻塞、單點問題、數(shù)據(jù)不一致、太過保守

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

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

三階段提交在兩階段提交的基礎(chǔ)上增加了一個 preCommit 的過程，當(dāng)所有參與者收到 preCommit 后，并不執(zhí)行動作，直到收到 commit  或超過一定時間后才完成操作。

優(yōu)點：降低參與者阻塞范圍，并能夠在出現(xiàn)單點故障后繼續(xù)達成一致 缺點：引入 preCommit  階段，在這個階段如果出現(xiàn)網(wǎng)絡(luò)分區(qū)，協(xié)調(diào)者無法與參與者正常通信，參與者依然會進行事務(wù)提交，造成數(shù)據(jù)不一致。

2PC / 3PC 協(xié)議用于保證屬于多個數(shù)據(jù)分片上操作的原子性。

這些數(shù)據(jù)分片可能分布在不同的服務(wù)器上，2PC / 3PC 協(xié)議保證多臺服務(wù)器上的操作要么全部成功，要么全部失敗。

Paxos 、 Raft 、 Zab 算法用于保證同一個數(shù)據(jù)分片的多個副本之間的數(shù)據(jù)一致性 。以下是三種算法的概要描述 。

Paxos 算法主要解決數(shù)據(jù)分片的單點問題 ， 目的是讓整個集群的結(jié)點對某個值的變更達成一致。Paxos (強一致性) 屬于多數(shù)派算法  。任何一個點都可以提出要修改某個數(shù)據(jù)的提案，是否通過這個提案取決于這個集群中是否有超過半數(shù)的結(jié)點同意，所以 Paxos 算法需要集群中的結(jié)點是單數(shù) 。

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

其有兩個基本過程：

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

② 同步log：L eader會找到系統(tǒng)中l(wèi)og(各種事件的發(fā)生記錄)最新的記錄，并強制所有的follow來刷新到這個記錄。

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

三、PostgreSQL 分布式架構(gòu)一覽

PostgreSQL發(fā)展時間線及分支圖

1. 基于內(nèi)核分布式方案 Postgres-XL

(1) 什么是Postgres-XL

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

官方稱其既適合寫操作壓力較大的OLTP應(yīng)用，又適合讀操作為主的大數(shù)據(jù)應(yīng)用。它的前身是Postgres-XC(簡稱PGXC)，PGXC是在PG的基礎(chǔ)上加入了集群功能，主要適用于OLTP應(yīng)用。PGXL是在PGXC的基礎(chǔ)上的升級產(chǎn)品，加入了一些適用于OLAP應(yīng)用的特性，如  Massively Parallel Processing (MPP) 特性。

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

(2) 技術(shù)架構(gòu)

架構(gòu)圖1

從上圖可以看出Coordinator和datanode節(jié)點可以配置為多個，并且可以位于不同的主機上。只有Coordinator節(jié)點直接對應(yīng)用服務(wù)，Coordinator節(jié)點將數(shù)據(jù)分配存儲在多個數(shù)據(jù)節(jié)點datanode上。

Postgres-XC主要組件有g(shù)tm(Global Transaction Manager) ， gtm_standby ， gtm_proxy,  Coordinator 和Datanode。

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

主要作用：

•  生成全局唯一的事務(wù)ID

•  全局的事務(wù)的狀態(tài)

•  序列等全局信息

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

協(xié)調(diào)節(jié)點 (Coordinator) 是數(shù)據(jù)節(jié)點 (Datanode) 與應(yīng)用之間的接口， 負責(zé)接收用戶請求、生成并執(zhí)行分布式查詢、 把 SQL  語句發(fā)給相應(yīng)的數(shù)據(jù)節(jié)點。

Coordinator 節(jié)點并不物理上存儲表數(shù)據(jù)，表數(shù)據(jù)以分片或者復(fù)制的方式分布式存儲，表數(shù)據(jù)存儲在數(shù)據(jù)節(jié)點上。當(dāng)應(yīng)用發(fā)起SQL時，會先到達  Coordinator 節(jié)點，然后 Coordinator節(jié)點將 SQL分發(fā)到各個數(shù)據(jù)節(jié)點，匯總數(shù)據(jù)，這一系統(tǒng)過程是通過GXID 和Global  Snapshot 再 來控制的。

數(shù)據(jù)節(jié)點(datanode)物理上存儲表數(shù)據(jù)，表數(shù)據(jù)存儲方式分為分片(distributed)和完全復(fù)制(replicated)兩種。數(shù)據(jù)節(jié)點只存儲本地的數(shù)據(jù)。

數(shù)據(jù)分布

 replicated table 復(fù)制表

表在多個節(jié)點復(fù)制

distributed table 分布式表

Hash

Round robin

注釋：Round robin 輪流放置是最簡單的劃分方法：即每條元組都會被依次放置在下一個節(jié)點上，如下圖所示，以此進行循環(huán)。

2. 擴展分布式方案Citus

(1) 什么是Citus

Citus是一款基于PostgreSQL的開源分布式數(shù)據(jù)庫 ，  自動繼承了PostgreSQL強大的SQL支持能力和應(yīng)用生態(tài)(不僅是客戶端協(xié)議的兼容還包括服務(wù)端擴展和管理工具的完全兼容)。Citus是PostgreSQL的擴展(not  a fork)，采用shared nothing架構(gòu)，節(jié)點之間無共享數(shù)據(jù)，由協(xié)調(diào)器節(jié)點和Work節(jié)點構(gòu)成一個數(shù)據(jù)庫集群。專注于高性能HTAP分布式數(shù)據(jù)庫  。

相比單機PostgreSQL，Citus可以使用更多的CPU核心，更多的內(nèi)存數(shù)量，保存更多的數(shù)據(jù)。通過向集群添加節(jié)點，可以輕松的擴展數(shù)據(jù)庫。

與其他類似的基于PostgreSQL的分布式方案，比如GreenPlum，PostgreSQL-XL相比，Citus最大的不同在于它是一個PostgreSQL擴展而不是一個獨立的代碼分支。Citus可以用很小的代價和更快的速度緊跟PostgreSQL的版本演進;同時又能最大程度的保證數(shù)據(jù)庫的穩(wěn)定性和兼容性。

Citus支持新版本PostgreSQL的特性，并保持與現(xiàn)有工具的兼容  。Citus使用分片和復(fù)制在多臺機器上橫向擴展PostgreSQL。它的查詢引擎將在這些服務(wù)器上執(zhí)行SQL進行并行化查詢，以便在大型數(shù)據(jù)集上實現(xiàn)實時(不到一秒)的響應(yīng)。

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

• Citus社區(qū)版

• Citus商業(yè)版

• Cloud [AWS，citus cloud]

(2) 技術(shù)架構(gòu)

Citus集群由一個中心的協(xié)調(diào)節(jié)點(CN)和若干個工作節(jié)點(Worker)構(gòu)成。

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

架構(gòu)圖1

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

應(yīng)用將查詢發(fā)送到協(xié)調(diào)器節(jié)點，協(xié)調(diào)器處理后發(fā)送至work節(jié)點。對于每個查詢協(xié)調(diào)器將其路由到單個work節(jié)點，或者并行化執(zhí)行，這取決于數(shù)據(jù)是否在單個節(jié)點上還是在多個節(jié)點上。Citus  MX模式允許直接對work節(jié)點進行訪問，進行更快的讀取和寫入速度。

架構(gòu)圖2(

Citus有三種類型表

• 分片表(最常用)

• 參考表

• 本地表

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

除了分片表和參考表，還剩下一種沒有經(jīng)過分片的PostgreSQL原生的表，被稱為“本地表”?！氨镜乇怼边m用于一些特殊的場景，比如高并發(fā)的小表查詢。

客戶端應(yīng)用訪問數(shù)據(jù)時只和CN節(jié)點交互。CN收到SQL請求后，生成分布式執(zhí)行計劃，并將各個子任務(wù)下發(fā)到相  應(yīng)的Worker節(jié)點，之后收集Worker的結(jié)果，經(jīng)過處理后返回最終結(jié)果給客戶端。

看完上述內(nèi)容，你們掌握分布式數(shù)據(jù)庫原理和PostgreSQL 分布式架構(gòu)是怎樣的的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！