背景

使用Kong作为分布式服务的统一入口，使用PostgreSQL作为Kong的数据存储，API网关的稳定就非常重要了，我们在两个节点部署了Kong通过负载均衡对外提供统一服务，共用同一个数据库，单一节点的数据库又成了系统的最大隐患…

Postgresql主从复制

我们现在使用的是Postgresql的主从复制模式，暂时只可以保障数据的备份能力，当数据库主节点发生故障时并不能保障整个系统的稳定运行，由于从节点是只读节点，也不能实现在主节点故障后切点到从节点来实现快速恢复服务的能力，即使是将从节点改为读写模式也有主节点恢复后数据同步的问题，所以主从复制不能满足业务需求。

Postgresql分布式存储

Postgresql有citus、pg_shardman、plproxy几个插件来实现数据的分布式存储能力，连接方式上和单节点数据上没有太大区别，由单组织节点+多存储节点构成，主要是解决单表数据量过大导致的数据检索瓶颈，Kong的数据量不大，主要是需要高可用，所以目的也不一样。

Postgresql集群

我们在想是不是可以使用Citus来实现高可用，Citus是一个PostgreSQL的扩展，类似于PostGIS、pgRouting，它主要的作用是将一张大表分布到多台机器的数据库中，并且可已经将查询分布到不同节点并行执行，最后汇总结果。Citus是单coordinator，多worker结构，coordinator统筹协调，worker是真正干活的壮丁。

coordinator节点是统筹协调，而且是在coordinator节点上配置worker节点列表，是否可以有多个coordinator节点管理相同的worker列表。

这个应该会出现脏数据吧。。