PostgreSQL读写分离通过主从复制和读请求路由实现，一主多从结构下主库处理写操作并同步WAL日志，从库应用日志保持数据一致；同步复制提升安全性但增加延迟，异步复制效率高但有数据丢失风险，建议配置至少一个同步从库。读请求路由策略包括应用层路由、中间件代理（如PgPool-II、HAProxy）和延迟感知路由，结合健康检查与负载均衡可优化性能。为保障一致性，需处理主从延迟问题，采用“读自己写”、主库读或动态下线高延迟从库等机制，并定期校验数据一致性，在性能、一致性和运维复杂度间取得平衡。
PostgreSQL 的读写分离主要通过主从复制和合理的读请求路由策略来实现，目标是提升系统吞吐量、降低主库压力，并保证数据一致性。要实现最佳的读写分离效果，核心在于稳定的数据复制机制和智能的读请求路由策略。
主从复制架构搭建
读写分离的基础是 PostgreSQL 的流复制（Streaming Replication），通常采用一主多从结构：
- 主库（Primary）负责所有写操作，同时将 WAL 日志实时传输给从库
- 从库（Standby）通过物理复制应用 WAL 日志，保持与主库数据同步
- 使用同步复制（synchronous_commit）可提升数据安全性，但会增加写延迟；异步复制更高效，但存在轻微数据丢失风险
推荐配置至少一个同步从库，兼顾性能与可靠性。
读请求路由策略选择
如何将读请求正确分发到从库，是读写分离的关键。常见的路由策略包括：
1. 应用层路由在应用程序中显式区分读写连接：
- 写操作使用主库连接池
- 读操作使用从库连接池（可轮询或按负载分配）
- 优点：控制精细，可结合业务逻辑定制
- 缺点：耦合度高，需改造现有代码
适用于对延迟敏感、需要精确控制读一致性的场景，如金融类系统。
2. 中间件代理路由使用数据库中间件自动识别 SQL 并转发：
- 常用工具：PgBouncer + PgPool-II、HAProxy、ProxySQL（支持 PostgreSQL 插件）
- PgPool-II 支持基于 SQL 类型的自动读写分离（SELECT 转发到从库）
- 可配置健康检查、负载均衡算法（如 least-connection）
- 支持连接池，降低数据库连接开销
推荐生产环境使用 PgPool-II 或 HAProxy 配合脚本实现智能路由。
3. 延迟感知读路由避免从延迟较高的从库读取“过期”数据：
- 监控每个从库的复制延迟（pg_stat_replication 视图中的 replay_lag）
- 路由时优先选择延
迟低于阈值（如 1 秒）的从库 - 对于强一致性要求的查询，强制走主库
迟低于阈值（如 1 秒）的从库可通过自定义脚本或中间件插件实现动态权重调整。
一致性与异常处理建议
读写分离可能引入主从延迟导致的数据不一致问题，需合理应对：
- 对刚写入后立即读取的场景，可将该读请求发送到主库
- 使用“读自己写”策略：用户写入后一段时间内的读操作定向到主库
- 设置最大允许复制延迟，超限时从库自动下线
- 定期校验主从数据一致性（如使用 pg_comparator）
基本上就这些。关键是在性能、一致性与运维复杂度之间找到平衡点。中小规模系统可用 PgPool-II 快速实现，大规模场景建议结合应用层控制与智能代理，实现精细化读路由。
