在 PostgreSQL 中，流复制（Streaming Replication）和逻辑复制（Logical Replication）是两种核心的复制机制，用于构建高可用集群。对于读重负载的应用，流复制通过多从库分担读压力，提供低延迟的实时同步；对于写重负载，逻辑复制的表级灵活性支持选择性数据同步，避免全实例开销。本文将从架构适配、延迟控制和故障切换角度，探讨如何根据工作负载特性定制复制方案。
流复制：读重应用的首选
流复制是一种物理复制方式，主库将 WAL（Write-Ahead Logging）日志实时流式传输到从库，实现全实例的字节级同步。从库为只读模式，适合读重场景，如 OLAP 查询或 Web 应用的用户数据读取。根据 PostgreSQL 官方文档，流复制的延迟通常在毫秒级，远低于逻辑复制的解码开销。
在读重应用中，流复制的优势在于读扩展：主库专注写操作，从库处理海量读请求。例如，一个电商平台的商品浏览查询可路由到多个从库，降低主库负载。证据显示，在高并发读场景下，使用流复制的多从架构可将读 QPS 提升 5-10 倍，而不影响写性能。
配置落地参数：
- postgresql.conf 主库设置：wal_level = replica（或 higher），max_wal_senders = 10（根据从库数调整），synchronous_commit = remote_write（平衡一致性和性能）。
- 从库恢复配置：primary_conninfo = 'host=primary port=5432 user=repl dbname=postgres'，使用 pg_basebackup 初始化。
- 监控清单：查询 pg_stat_replication 查看 sent_lag 和 replay_lag；设置 wal_keep_segments = 128 保留 WAL 段，防止从库落后时日志丢失。
对于 failover，流复制支持 pg_ctl promote 手动提升从库为主，或集成 Patroni 工具实现自动切换。Patroni 使用 Etcd 进行 Leader 选举，检测主库故障后 30 秒内完成切换，RTO 控制在分钟级。
逻辑复制：写重应用的灵活选择
逻辑复制基于发布 - 订阅模型，仅复制指定表的 DML 操作（INSERT/UPDATE/DELETE），支持从库读写，适用于写重或混合负载，如日志系统或实时分析应用需跨表同步。相比流复制，逻辑复制的 WAL 解码过程引入额外 CPU 开销，但允许跨版本迁移和数据过滤。
在写重场景，逻辑复制避免全 WAL 传输，减少带宽消耗。例如，一个金融交易系统可仅订阅交易表到分析从库，支持从库独立写操作。实践经验表明，对于写密集表，逻辑复制的延迟约 100ms，适合 RPO <5s 的需求，但不宜用于超高吞吐写（>1000 TPS），以防解码瓶颈。
配置落地参数：
- 主库：wal_level = logical，max_replication_slots = 10，创建 PUBLICATION：CREATE PUBLICATION pub_sales FOR TABLE sales.orders;
- 从库：CREATE SUBSCRIPTION sub_sales CONNECTION 'host=primary dbname=postgres user=repl' PUBLICATION pub_sales;
- 优化清单：使用 replication slots 管理槽位，SELECT * FROM pg_replication_slots; 定期清理无效槽；对于大表，启用并行应用（PostgreSQL 14+）以降低 lag。
Failover 时，逻辑复制需重建订阅：故障后，新主需重新创建 publication，从库 DROP SUBSCRIPTION 后重连。结合 repmgr 工具，可自动化此过程，确保切换后订阅一致性。
延迟管理和通用最佳实践
无论流复制还是逻辑复制，lag 管理是关键。读重应用优先异步流复制，容忍短暂 lag 以最大化读吞吐；写重则用同步逻辑复制，确保数据一致。监控工具如 pgBadger 或 Prometheus 可追踪 lag 指标，阈值设为 <1s 告警。
风险控制：流复制在写重下，同步模式会阻塞主库写（延迟增 20-50%）；逻辑复制不支持 DDL 复制，需手动同步 schema。通用参数：max_worker_processes = 8（逻辑解码线程），archive_mode = on 备份 WAL。
通过上述配置，读重应用可实现 99.99% 可用性，写重则聚焦数据一致性。实际部署中，结合 PgBouncer 连接池和 HAProxy 负载均衡，进一步优化集群性能。
（正文字数：1028）