文章来源于数据库架构之美，作者数据库架构之美

Postgresql由于强大的功能和良好的扩展性，基于postgresql来做的分布式架构也比较多，大部分用于分析类场景，下面比较几种常见的架构特点。

Citus

Citus以插件的方式扩展到postgresql中，独立于postgresql内核，所以能很快的跟上pg主版本的更新，部署也比较简单，是现在非常流行的分布式方案。Citus在苏宁有大规模应用，微软也提供citus的商业支持。下面是citus的架构：

Citus节点主要分为协调节点和工作节点，协调节点不存储真实数据，只存储数据分布的元信息，实际的数据被分成若干分片，打散到不同worker节点中，应用连接协调节点，协调节点进行sql解析，生成分布式执行计划，下发到worker节点执行，cn将结果汇总返回客户端。

Ciitus的主要架构特点如下：

①有两种表类型：参考表和分布表，参考表每个协调节点和worker节点都有一份完整的副本，分布表则会打散分布到不同worker中。

②可以进行读写分离，如上图cn1为写节点，可以通过再增加多个cn读节点增加集群读的能力，写cn和读cn之间使用流复制进行元数据同步。

③支持MX模式，可以将元数据也存在某些worker节点中，这样使得该worker节点能够直接提供写的能力，以此增加集群写的能力。

④底层worker节点可以通过流复制搭建副本，保证数据高可用。

⑤做join时最好的结果是能够将计算下推到worker节点，但是只有在参考表和其他表做join以及两个表的分布方式相同的情况下才能下推到worker计算，否则需要将数据拉到协调节点进行计算。

⑥整体架构类似mycat的中间件，因为没有全局事务管理，故不能保证数据的实时读一致性，但是性能上相比要好。数据写一致性使用2pc来保证。

pgxc && pgxl

Pgxc是经典的分布式数据库架构，是真正的企业级HTAP，我们看到市面上很多分布式数据库产品都是基于pgxc架构扩展而来。pgxc是和pg内核紧耦合的，是嵌入到pg内核中，最初pgxc的核心开发者将pgxc商业化，创建了stormdb，进行了一些并行算子优化，后来TransLattice公司将stormdb收购，并且将项目开源，就是现在的pgxl，所以pgxc和pgxl是一脉相承的，大部分代码是直接移植过来的。下面是pgxc的架构：

其实这个架构和citus优点类似，也是分为协调节点和数据节点，数据也是通过hash分布到不同数据节点上，只是在集群中增添了全局事务管理组件，保证全局事务的一致性。

pgxc的架构特点如下：

①gtm保证全局读一致性，两阶段提交保证全局写一致性。

②gtm是整个系统的瓶颈点，在超过150并发的情况下，gtm的瓶颈就会显现，每一个事务开启都会去gtm取事务号和快照信息，造成gtm在网络压力和分配事务号速度上存在瓶颈。

③多个协调节点间需要同步元数据信息，如果协调节点失败，不仅会造成ddl hang住，也可能造成两阶段事务的阻塞。

④pgxc的出现主要是在pg在oltp应用场景上的优化，不管是新增gtm，还是数据一致性的保证上面都做得更加精细化。

⑤和citus类似，数据表也可以分为分布表和复制表，复制表在每一个数据节点都有一份全量数据。

Greenplum

Greenplum是pivotal公司推出的一款开源olap的mpp数据库，greenplum的用户在某种程度上甚至超越了pg，很多人可能是通过greenplum才认识的pg，可见greenplum的风靡。下面是greenplum架构：

Master节点存储全局系统元数据信息，不存储真实数据。数据通过hash分布到不同的segment中，master作为sql的全局入口，负责在segment中分配工作负载，整合处理结果，返回客户端。

Greenplum架构特点如下：

①master节点可以做主备，segment节点也有镜像保证高可用，segment主备尽量混布到不同服务器上。

②支持行列混合存储引擎，同时支持外部表。

③在join时也涉及到数据跨节点重分布的问题，这也是share nothing数据库不可避免的问题。

④高速内部interconnect网络，实现数据join时的高速移动和汇总。

⑤高效的数据并行加载。