能否给张PostgreSQL数据库在分布式场景下的架构？

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

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

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

来张比较流行的GP架构：

在分布式数据库中，无论是share-disk，share-memory，还是share-nothing的结构，数据库高可用性能主要实现方案都是通过节点冗余的方式，greenplum是采用share-nothing的MPP架构，其高可用也是通过给每个节点（master节点和所有的segment节点）设置一个冗余节点来实现的。

目前GP版本基于PG 9.6
Master 主节点冗余通过物理流复制实现
每个segment都有一个热备份（hot standby）称为segment mirror。
Master节点能够检测到primary segment的状态，当primary segment不能继续提供服务时，会主动激活mirror segment成为新的primary。正常情况下primary segment处于active状态，primary segment和mirror segment之间的数据同步是通过两种方式：

（1） 数据同步复制

primary segment上，在事务commit之前，把事务的commit log同步到mirror segment上，同步结束以后，primary segment才做真正的commit。这样当mirror segment被提升成primary后，能够保证事务的一致性。

（2） 物理文件复制

堆表使用物理文件复制。GP中表数据是由元组组成的一个固定大小的块文件存储在磁盘上，为了优化磁盘I/O，块文件会被存储到缓冲区，当缓冲区满了之后会被新更新的块文件替换，被替换出来的块文件被写到primary segment的磁盘上，同时通过网络复制到mirror segment上，Mirror segment只更新其文件副本中的相应块。当块保存在缓存中时，primary segment和mirror segment具有不同的块镜像，但是数据库仍然是一致的，因为事务日志已经被复制了。

详细内容可参考：
https://www.pgfans.cn/a?id=419

PG的分布式基本上都是pgxl、pgxc的架构模式，可以看下开源产品AntDB。我正在写一篇文章关于PG VS MySQL为何PG不适合OLTP业务场景的原因，核心是没有真正的 MVCC，在做UPDATE/DELETE的时候很吃亏。

另外，使用OLTP分布式数据库产品后，则数据库端没有业务计算的包、自定义函数、存储过程、视图，甚至连复杂子查询都没有，则PG的内部机制就会显得更加笨重，不如MySQL走的轻量型路线高效和处理快

目前，主要流行的就3种： Citus 、 Pgxc/Pgxl 、 Greenplum