今天，利用大家的休息时间分享postgresql分布式集群，利用Citus实现分库分表。

一、Citus是什么

   citus是PG的一个sharding插件，可以把PG变成一个分布式数据库。目前在苏宁有大量的生产应用跑在citus+pg的环境中。大家可以看it大咖视频。

   citus是一款基于PostgreSQL的开源分布式数据库,自动继承了PostgreSQL强大的SQL支持能力和应用生态（不仅仅是客户端协议的兼容还包括服务端扩展和管理工具的完全兼容）。 

   和其他类似的基于PostgreSQL的分布式方案，比如GreenPlum，PostgreSQL-XL，PostgreSQL-XC相比，citus最大的不同在于citus是一个PostgreSQL扩展而不是一个独立的代码分支。 

    因此，citus可以用很小的代价和更快的速度紧跟PostgreSQL的版本演进；同时又能最大程度的保证数据库的稳定性和兼容性。

二、主要特性

● PostgreSQL兼容

● 水平扩展

● 实时并发查

● 快速数据加载

● 实时增删改查

● 持分布式事务

● 支持常用DDL

三、Citus架构节点

   Container简称CN节点  worker节点

  CN只存储和数据分布相关的元数据，实际的表数据被分成M个分片，打散到N个Worker上。这样的表被叫做“分片表”，可以为“分片表”的每一个分片创建多个副本，实现高可用和负载均衡。

    分片表和参考表

   分片表分布打散在多个worker节点，而参考表每一个container节点和worker都保留一模一样的副本。

   下图是Citus处理客户端访问的一个简单的架构流程图，应用层直接连接CN节点，CN节点对客户端传入的sql语句进行解析，生成分布执行计划，并将各个子任务下发到相应的Worker节点，之后收集Worker的结果，经过处理后返回最终结果给客户端。最基本的流程就是这样，但是生成环境我们还应该考虑到高可用。下面将完整的介绍Citus实战集群原理。

四、Citus的三种集群

   因为，citus本身不支持HA，不像mongodb一样故障自动修复，但是可以结合pg的流复制，以及应用层jdbc数据驱动实现读写分离，故障切换。

第一种集群，增加读的能力

多个container节点，多个container节点进行流复制，保持元数据一致，在应用层设置多个读写分离，保证了数据的一致性，也保证了业务的高可用。

第二种集群，citus的MX功能

此功能可以说是解决了读和写的瓶颈，苏宁的架构中也是采用同样的思想。

原理：Mx功能的原理就是让其他的worker节点携带元数据，相当于携带元数据的worker节点都支持读写的能力，很大程度解决了读写的问题。

第三种集群，流复制，异地容灾。使用不同的dns，解决两套集群IP不同的问题。扩展容灾能力。

这套集群是在mX的基础上解决异地容灾的方案，通过dns解析到不同的机房的数据库。

上面三种集群，最常用的最有效的方法还是MX集群，只要在应用层设置好读写规则就可以了，底层worker的HA可以用流复制，多个副本实现数据高可用。

五、worker节点网络问题

cn节点访问所有worker节点。oltp业务的访问比较频繁。

重分布数据时，worker节点相互访问，访问频率不大。olap业务场景，数据交换吞吐较大。

cn节点连worker有两种模式

1、事务级保持连接模式（每条sql发起建立连接，sql结束断开连接，（除非事务中）。跑OLAP类sql时，使用即时连接模式（olap场景并发不高，建立连接带来的额外开销不大）

2、会话保持连接模式（会话发起建立连接，会话结束后释放连接）。跑OLTP类的SQl时，使用的是会话保持（oltp查询，并发性能高）

上面两种模式，基本上Citus能满足TP也能满足AP。

后面我会把搭建过程分享出来，比较简单。如果大家有什么好的pgsql的分布式方案，可以留言评论一起交流。

citus还有好多的特性，

比如：对于计算count处理时，如何进行优化。

       对于数据统计，citus提供了topn插件，与HLL类似

大家可以看官方文档介绍：https://docs.citusdata.com/en/v7.5/get_started/concepts.html#nodes-coordinator-and-workers