PG数据库如何实现同城异地多活数据同步？
最近在进行系统建设前的设计，系统使用的是pg的数据库。因为业务的实际要求，需要构建同城双活+异地单活 整个三活的模式。
系统在三个机房部署，客户随机访问其中任一机房服务。所以需要保障PG数据库在三个地方的数据是一致，且都能提供读写能力。
目前有想法是在应用层记录下每次的数据库操作，然后写入消息队列，由其他2地消费消息，重新执行数据库操作。但是这种存在消息消费不及时或者前后顺序不一致的情况，不知道有没有什么好的方案能够实现数据库在同城异地多活的模式。
要求三中心数据和服务都是热的，且提供写入的能力。
3同行回答
常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等多种技术方案，不同多活方案技术要求、建设成本、运维成本都不一样，下面我们会逐步介绍这几种多活方案并给出每种方案的优点和缺点。选用哪种方案要结合具体业务规模、当前基础建设能力、投入产出比等多种因素来决定。
同城双活
同城双活是在同城或相近区域内建立两个机房。同城双机房距离比较近，通信线路质量较好，比较容易实现数据的同步复制 ，保证高度的数据完整性和数据零丢失。同城两个机房各承担一部分流量，一般入口流量完全随机，内部RPC调用尽量通过就近路由闭环在同机房，相当于两个机房镜像部署了两个独立集群，数据仍然是单点写到主机房数据库，然后实时同步到另外一个机房。
两地三中心架构
所谓两地三中心是指 同城双中心 + 异地灾备中心。异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，数据和服务平时都是冷的，当双中心所在城市或者地区出现异常而都无法对外提供服务的时候，异地灾备中心可以用备份数据进行业务的恢复。
要建立起完整的异地多活能力远远比上面讨论的要复杂的多，需要对依赖的各种中间件、储存等做相应的单元化改造并配套完整的流量调度和运维管控能力 。
收起直接基于开源的PG，我估计是不行。
因为你的诉求是多地多活都可以写。而PG本身是主从模式基于redo log同步，备机要回放日志，只能读不能写。
数据库要做到多活，有几个问题要解决。
首先是数据共享，两边PG看到的数据必须是同一份，才能避免数据之间的差异。这个问题只要把数据放在共享存储，基于共享存储做个同城数据双活就解决了。
第二个问题就是数据共享之后，多个数据库实例要能修改访问同一份数据，这个问题其实也有解决办法，就是对同一个库或者一个表，始终只有一个人写就行，这个估计改一些中间件也能做到。
第三个问题，是读写一致性，这个就有点麻烦了，因为必须要保证缓存和视图的一致，也就是集群级MVCC。这个东西估计不动内核不太可能从外围解决。
我们目前倒是针对MySQL有个方案，我发过一篇文章《怎样才是分布式数据库存算分离的正确姿势》里面最后的那个架构是能满足要求的，只可惜这个目前是对MySQL的。
收起
ChatGPT 回答
针对你的问题，我可以提供以下几种方案：
- 数据库复制方案
可以使用 PostgreSQL 的流复制（streaming replication）功能，将主数据库的数据同步到备份数据库。在同城的情况下，可以使用同步复制（synchronous replication），确保主数据库和备份数据库的数据是一致的。在异地的情况下，可以使用异步复制（asynchronous replication），可以通过设置延迟时间来控制数据同步的延迟。这种方案可以保证数据的一致性，但是需要考虑主备切换、数据冲突等问题。
- 数据库集群方案
可以使用 PostgreSQL 的集群方案，如 Pgpool-II、PgBouncer、HAProxy 等，将多个数据库节点组成一个集群，提供读写负载均衡和故障转移功能。在同城的情况下，可以使用同城多活模式，将读写请求分发到不同的节点上，提高系统的性能和可用性。在异地的情况下，可以使用异地多活模式，将数据同步到不同的节点上，保证数据的可用性。这种方案需要考虑数据同步、节点故障、网络延迟等问题。
- 数据库中间件方案
可以使用数据库中间件，如 TiDB、OceanBase、YugabyteDB 等，将多个数据库节点组成一个分布式数据库，提供读写负载均衡、数据分片、故障转移等功能。这种方案可以支持同城异地多活，提供数据的高可用性和高性能。但是需要考虑数据分片、数据迁移、节点故障等问题。
综上所述，针对你的需求，可以选择以上三种方案中的一种或多种进行组合，根据实际情况进行选择和调整。同时，需要注意数据的一致性、性能、可用性等问题，确保系统的稳定和可靠。
