印刻数据库

外观

PostgreSQL 读写分离一致性处理 ​

读写分离一致性挑战 ​

在 PostgreSQL 读写分离架构中，主库负责处理写操作，从库负责处理读操作。由于数据同步需要时间，从库数据可能存在延迟，导致读操作获取到的数据不是最新的，这就是读写分离面临的一致性挑战。

延迟产生原因 ​

  • 网络传输延迟：主库产生的 WAL 日志需要通过网络传输到从库
  • 从库应用日志延迟：从库需要解析和应用主库发送的 WAL 日志
  • 从库负载过高：从库 CPU、内存或磁盘 I/O 瓶颈导致日志应用缓慢
  • 大事务影响：主库上的大事务会产生大量 WAL 日志，从库需要较长时间才能应用完毕

一致性级别 ​

  • 强一致性：所有读操作都能获取到最新数据
  • 最终一致性：读操作可能获取到旧数据，但最终会达到一致状态
  • 会话一致性：同一用户会话内的读操作能获取到该会话之前写操作的结果
  • 因果一致性：有因果关系的操作保持一致

一致性处理方案 ​

1. 延迟检测与阈值控制 ​

通过监控从库延迟，当延迟超过设定阈值时，将读请求路由到主库。

延迟检测方法 ​

sql
-- 通过查询 pg_stat_replication 视图获取从库延迟
SELECT 
    client_addr,
    state,
    sync_state,
    extract(epoch FROM (now() - pg_last_xact_replay_timestamp())) AS replication_delay_seconds
FROM pg_stat_replication;

-- 通过查询 pg_stat_wal_receiver 视图获取从库延迟（适用于流复制）
SELECT 
    pg_wal_lsn_diff(pg_current_wal_lsn(), received_lsn) AS write_lag,
    pg_wal_lsn_diff(received_lsn, flushed_lsn) AS flush_lag,
    pg_wal_lsn_diff(flushed_lsn, replayed_lsn) AS replay_lag,
    extract(epoch FROM now() - last_msg_send_time) AS last_msg_send_delay,
    extract(epoch FROM now() - last_msg_receipt_time) AS last_msg_receipt_delay
FROM pg_stat_wal_receiver;

阈值控制策略 ​

  • 根据业务对一致性的要求设定延迟阈值（如 100ms、500ms 或 1s）
  • 动态调整阈值，高峰期可适当放宽，低峰期可收紧
  • 对不同业务类型设置不同的延迟阈值

2. 读操作路由策略 ​

基于会话的路由 ​

  • 同一用户会话内的读操作，在写操作后一段时间内路由到主库
  • 适用于需要会话一致性的业务场景

基于操作类型的路由 ​

  • 对实时性要求高的读操作（如订单查询、余额查询）路由到主库
  • 对实时性要求低的读操作（如报表查询、历史数据查询）路由到从库

基于数据版本的路由 ​

  • 记录数据的版本号或时间戳
  • 读操作时检查从库数据版本是否符合要求，不符合则路由到主库

3. 数据同步机制优化 ​

使用同步复制 ​

sql
-- 在 postgresql.conf 中配置同步复制
# 至少需要一个同步备用节点
 synchronous_commit = on
 synchronous_standby_names = 'ANY 1 ("standby1", "standby2")'

优化从库配置 ​

sql
-- 提高从库 WAL 应用效率
 hot_standby = on
 max_standby_streaming_delay = 30s
 hot_standby_feedback = on

使用逻辑复制 ​

对于需要更灵活复制策略的场景，使用逻辑复制可以减少延迟：

sql
-- 在主库创建发布
CREATE PUBLICATION my_publication FOR TABLE users, orders;

-- 在从库创建订阅
CREATE SUBSCRIPTION my_subscription
  CONNECTION 'host=primary dbname=mydb user=repl password=secret'
  PUBLICATION my_publication;

4. 应用层一致性处理 ​

写入后立即读主库 ​

在关键业务流程中，写入数据后立即的读操作直接访问主库，确保获取最新数据。

读库降级机制 ​

当从库延迟超过阈值时，自动将读请求路由到主库，待延迟恢复后再切回从库。

数据版本校验 ​

在应用层实现数据版本校验逻辑，当从库数据版本不符合预期时，自动重试或切换到主库。

不同版本的一致性处理差异 ​

PostgreSQL 9.6 及以下版本 ​

  • 仅支持流复制，不支持逻辑复制
  • 同步复制配置相对简单
  • 延迟监控工具有限，主要依赖 pg_stat_replication 视图

PostgreSQL 10 及以上版本 ​

  • 引入逻辑复制，提供更灵活的复制策略
  • 增强了同步复制功能，支持多个同步备用节点
  • 提供了更丰富的延迟监控指标
  • 支持并行 WAL 应用，提高从库应用效率

PostgreSQL 13 及以上版本 ​

  • 引入了并行逻辑复制，进一步提高复制效率
  • 增强了从库反馈机制，减少主从冲突
  • 提供了更精确的延迟监控

生产环境最佳实践 ​

1. 合理规划从库数量 ​

  • 根据业务读负载规划从库数量
  • 考虑不同业务场景对一致性的要求，配置不同的从库集群
  • 定期评估从库性能，及时扩容或优化

2. 监控与告警 ​

  • 实时监控从库延迟，设置合理的告警阈值
  • 监控从库同步状态，及时发现同步异常
  • 监控主库 WAL 生成速率和从库应用速率

3. 故障切换机制 ​

  • 实现自动故障切换，当主库故障时，从库能够快速提升为主库
  • 故障切换过程中确保数据一致性
  • 定期进行故障切换演练

4. 业务设计优化 ​

  • 对一致性要求高的业务，避免过度依赖读写分离
  • 设计支持最终一致性的业务逻辑
  • 使用缓存等中间件缓解从库压力

5. 定期测试与评估 ​

  • 定期测试从库延迟对业务的影响
  • 评估不同一致性方案的性能开销
  • 根据业务发展调整一致性策略

常见问题（FAQ） ​

Q1: 如何选择合适的一致性级别？ ​

A1: 选择一致性级别需要权衡业务需求和系统性能：

  • 对实时性要求高的业务（如金融交易），选择强一致性
  • 对实时性要求低的业务（如报表查询），选择最终一致性
  • 大多数业务场景可以采用会话一致性或因果一致性

Q2: 同步复制会影响主库性能吗？ ​

A2: 同步复制会增加主库写操作的延迟，因为主库需要等待从库确认收到 WAL 日志后才能返回。可以通过以下方式缓解：

  • 使用多个同步备用节点，提高可用性
  • 对非关键业务使用异步复制
  • 优化从库性能，减少同步确认时间

Q3: 如何处理从库延迟突然增大的情况？ ​

A3: 当从库延迟突然增大时，可以采取以下措施：

  • 检查主库是否有大事务在执行
  • 检查从库是否存在性能瓶颈（CPU、内存、磁盘 I/O）
  • 临时将读请求路由到主库或其他延迟较小的从库
  • 如延迟持续增大，考虑重建从库

Q4: 逻辑复制和流复制在一致性处理上有什么区别？ ​

A4: 流复制是基于 WAL 日志的物理复制，延迟较低，适合强一致性要求的场景；逻辑复制是基于逻辑变更的复制，延迟相对较高，但提供更灵活的复制策略，适合最终一致性要求的场景。可以根据业务需求选择合适的复制方式。

Q5: 如何验证从库数据的一致性？ ​

A5: 可以通过以下方式验证从库数据一致性：

  • 使用 pg_basebackup 定期重建从库，确保数据基础一致
  • 使用 pg_verifybackup 工具验证备份数据完整性
  • 在应用层实现数据一致性校验逻辑
  • 定期执行主从数据对比，如使用 pg_comparator 工具