PostgreSQL原生不支持多主复制，但可通过BDR、逻辑复制分片、中间件或Citus等分布式方案实现多写，需根据业务场景权衡一致性、复杂度与扩展性。
PostgreSQL 原生并不支持多主复制（Multi-Master Replication），也就是说多个节点同时接受写操作在官方功能中是不直接支持的。但实际业务中存在多写需求，比如跨地域部署、高可用、负载均衡等场景，因此社区和第三方提供了多种实现多写方案的途径。下面从可行性和方案角度进行分析。
一、原生限制与挑战
PostgreSQL 的流复制（Streaming Replication）是典型的主从结构，备库只读，无法写入。这种设计保证了数据一致性，但也限制了写扩展能力。如果强行在多个节点上开启写权限，会出现以下问题：
- 数据冲突：同一行记录在不同节点被修改，无法自动合并
- 序列冲突：自增ID可能产生重复值
- 事务隔离异常：缺乏全局事务时钟，MVCC 可见性难以协调
- 无冲突解决机制：没有内置的冲突检测与处理策略
这些因素决定了 PostgreSQL 多主写入必须依赖外部工具或架构设计来规避风险。
二、常见的多写实现方案
1. BDR（Bi-Directional Replication）
BDR 是一个基于逻辑复制的双向复制插件，支持真正的多主架构，适用于需要跨数据中心同步的场景。
- 使用逻辑解码技术实现节点间数据同步
- 支持异步多主、部分同步模式
- 提供冲突检测机制（如“last update wins”）
- 仅支持部分数据类型和DDL限制（例如不能在所有节点自由加列）
缺点是配置复杂，维护成本高，且对应用有一定侵入性。
2. Logical Replication + 自定义路由
PostgreSQL 10+ 提供了逻辑复制功能，可按表级别订阅发布，通过合理设计可以模拟多主行为。
- 将不同表或数据分片分配到不同主节点写入
- 各节点之间互为发布者和订阅者
- 避免同一行数据被多个节点修改，从源头规避冲突
这种方式本质是“分片多主”，适合能做水平拆分的系统，比如按租户、区域划分数据。
3. 中间件层控制（如 Pgpool-II、Patroni + HAProxy）
这类方案通常不是真正意义上的多写，而是通过中间件做写请求分发或故障切换。
- Pgpool-II 支持连接池和简单负载均衡，但多写需配合复制插件
- Patroni 实现高可用主从切换，仍为单主写入
- 若结合 Citus 或其他分片框架，可在分片维度实现多主写入
适用于希望保持架构简洁、又能提升可用性的场景。
4. 第三方分布式数据库（基于 PostgreSQL）
一些商业或开源项目在 PostgreSQL 基础上构建了完整的多主或多写能力：
- Citus：将 PostgreSQL 扩展为分布式数据库，支持分片写入，每个分片可独立写
- TimescaleDB：针对时序数据优化，支持透明分片，写入可分布
- Greenplum：MPP 架构，多段并行写入，适合分析型场景
这类方案牺牲了一定的通用性，换取更强的扩展能力。
三、多写方案选型建议
是否采用多主复制，应根据具体业务需求判断：
- 如果只是需要高可用，推荐主从 + 故障自动切换（如 Patroni）
- 如果写压力集中在不同数据集上，可用逻辑复制做分片多主
- 若必须全量数据多点可写，BDR 是较成熟选择，但要接受其约束
- 大规模数据分析场景，考虑 Citus 或 Greenplum 等 MPP 方案
多写带来的复杂度远高于单主架构，建议优先考虑应用层分片或读写分离，而非盲目追求多主。
四、总结
PostgreSQL 原生不支持多主复制，但通过 BDR、逻辑复制、中间件或分布式扩展等方式，可以实现不同程度的多写能力。关键在于理解每种方案的适用边界和潜在风险。对于大多数应用，合理的架构设计比强行实现多主更可靠。基本上就这些，不复杂但容易忽略细节。
