共计 6011 个字符，预计需要花费 16 分钟才能阅读完成。
一、什么是分布式数据库
分布式系统数据库系统原理（第三版）中的形容：“咱们把分布式数据库定义为一群散布在计算机网络上、逻辑上互相关联的数据库。分布式数据库管理系统（分布式 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（强一致性）也称为 www.cungun.comAtomic 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 分布式架构一览（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
从上图能够看出 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]
（2）技术架构
本截图援用 2020 年 3 月苏宁陈华军 Citus 的实际分享
Citus 集群由一个核心的协调节点 (CN) 和若干个工作节点 (Worker) 形成。
CN 只存储和数据分布相干的元数据，理论的表数据被分成 M 个分片，打散到 N 个 Worker 上。这样的表被叫做“分片表”，能够为“分片表”的每一个分片创立多个正本，实现高可用和负载平衡。
Citus 官网文档更倡议应用 PostgreSQL 原生的流复制做 HA，基于多正本的 HA 兴许只实用于 append only 的分片。
利用将查问发送到协调器节点，协调器解决后发送至 work 节点。对于每个查问协调器将其路由到单个 work 节点，或者并行化执行，这取决于数据是否在单个节点上还是在多个节点上。Citus MX 模式容许间接对 work 节点进行拜访，进行更快的读取和写入速度。
分片表次要解决的是大表的程度扩容问题，对数据量不是特地大又常常须要和分片表 Join 的维表能够采纳一种非凡的分片策略，只分 1 个片且每个 Worker 上部署 1 个正本，这样的表叫做“参考表”。
除了分片表和参考表，还剩下一种没有通过分片的 PostgreSQL 原生的表，被称为“本地表”。“本地表”实用于一些非凡的场景，比方高并发的小表查问。
客户端利用拜访数据时只和 CN 节点交互。CN 收到 SQL 申请后，生成分布式执行打算，并将各个子工作下发到相 应的 Worker 节点，之后收集 Worker 的后果，通过解决后返回最终后果给客户端。
