PostgreSQL的流复制是基于WAL（Write Ahead Log）物理日志的同步机制，主库将产生的WAL记录通过网络发送给备库，备库重放这些日志达到与主库一致的状态。在这种架构下，备库可以以只读模式打开，承接那些不需要写入数据的查询请求，从而实现读写分离和查询分流。许多团队在业务读多写少或者报表分析场景重的情形下，都会考虑把这部分流量引到备库，以降低主库负载。
流复制备库只读模式的原理与限制
在流复制体系中，备库通过recovery.conf（或PostgreSQL 12之后的postgresql.auto.conf中的primary_conninfo）连接主库，以standby_mode持续接收WAL。当配置hot_standby = on时，备库在完成日志恢复的同时允许建立只读连接执行SELECT。由于备库不接收任何写事务，所有数据变更都必须来自主库WAL重放，因此它本身具备强一致基础，只是存在重放延迟。
备库只读查询面临的首要限制是恢复冲突。当主库执行了某些操作（例如VACUUM清理死元组、DROP TABLE、或者表结构变更），而备库上正有查询访问相关对象，就会触发恢复冲突。PostgreSQL提供了max_standby_streaming_delay参数，控制备库为了等待只读查询结束而最多推迟WAL应用的时间。超过该时间，备库会取消冲突的查询并抛出错误。这意味着如果备库承接了运行时间很长且涉及热表的查询，很可能被中断。
另一个限制是可见性延迟。因为WAL是异步（或同步但仍有传播时延）到达的，备库数据状态通常落后主库几毫秒到几秒。应用如果先在主库写入一条记录，立刻到备库查询，可能查不到。这对一些强一致读场景（如支付后立刻查账单）是不适用的，需要业务层识别哪些查询可以容忍延迟，哪些必须走主库。
基于连接层与驱动层的查询分流方案
实现只读分流最直观的方式是在应用侧做路由。开发人员可以在代码里维护两个数据库连接池：一个指向主库，用于INSERT、UPDATE、DELETE及事务内的读；另一个指向备库，专门用于报表、列表分页等只读语句。例如在Java的HikariCP中配置两个数据源，通过注解或方法名约定选择。
如果不想在业务代码里硬编码，也可以使用中间件。像Pgpool-II这类工具支持基于查询语义的负载均衡，它能解析SQL，把以SELECT开头且不在事务中的请求发给备节点。不过中间件解析SQL存在误判风险，且引入额外网络跳点。以下示例展示在应用代码里手动分流的简单逻辑：
// 根据SQL类型选择数据源
public DataSource route(String sql) {
String trim = sql.trim().toLowerCase();
// 写操作或事务内读走主库
if (trim.startsWith("insert") || trim.startsWith("update")
|| trim.startsWith("delete") || trim.startsWith("begin")) {
return masterDataSource;
}
// 普通select走备库
if (trim.startsWith("select")) {
return replicaDataSource;
}
return masterDataSource;
}
对于使用连接字符串的客户端，还可以通过libpq的target_session_attrs参数。设置为read-only时，驱动会自动连接到处于只读状态的节点，配合多主机地址可实现简单分流。但要注意，这一方式只保证连到只读节点，并不区分该节点是备库还是被设置为只读的主库，且无法按单条语句动态切换。
延迟容忍与冲突处理的工程实践
要让备库稳定承接只读流量，必须监控复制延迟。可以通过查询备库上的pg_stat_replication（在主库侧）或pg_last_wal_replay_lsn与pg_current_wal_lsn差值来计算落后字节数。当延迟超过阈值，应用应有降级逻辑：将请求切回主库或返回友好提示，防止用户看到过期数据。
针对恢复冲突导致的查询取消，一种缓解手段是适当调大max_standby_streaming_delay，但这会增加备库与主库的数据差异时间。更优的做法是把大查询、统计类请求安排在业务低峰，或放在专门的数据仓库而非线上备库。另外开启hot_standby_feedback = on可让备库把最老事务号回传给主库，避免主库VACUUM清除备库仍需要的行版本，从而减少冲突，但可能导致主库膨胀。
在分流架构里，还应明确只读用户的权限。通过创建仅有SELECT权限的角色并绑定到备库连接，避免误操作。同时利用application_name标记不同业务线流量，便于在pg_stat_activity中观察备库负载构成，及时发现某类查询占比异常。综合这些手段，PostgreSQL流复制备库才能成为可靠的只读查询分流节点，而非仅仅是容灾副本。
典型配置与监控代码示例
在备库配置文件里，以下参数组合是常见起点。它们允许热备查询，并控制冲突等待时间，同时打开反馈减少清理冲突。实际数值应结合业务查询时长调整。
# postgresql.conf 备库片段 hot_standby = on max_standby_streaming_delay = 30s hot_standby_feedback = on wal_level = replica
监控复制延迟可用如下SQL在备库执行，计算已重放日志与主库当前日志的字节差。运维脚本可周期性采集并告警。
SELECT pg_last_wal_receive_lsn() AS receive_lsn, pg_last_wal_replay_lsn() AS replay_lsn, EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())) AS lag_seconds;
整体来看，PostgreSQL流复制备库做只读查询分流是一项成熟但需细致打磨的方案。从原理认知到路由策略，再到延迟与冲突的运维处理，每一步都影响最终效果。只有把业务查询特征与数据库机制匹配好，才能既保住主库性能，又让备库资源物尽其用。
PostgreSQL流复制只读分流修改时间：2026-08-14 02:18:31