Django论坛读写分离与水平扩展：PostgreSQL 副本、延迟容忍与幂等写

当论坛成长到中高并发，数据库压力首先出现在“读热门列表、写高频操作（点赞/计数）”两端。本文给出“PostgreSQL 读写分离 + 延迟容忍 + 幂等写”的一套演进式方案。

拆分目标与边界

• 写主库：注册/登录态变更、发帖/回帖、交易/积分、强一致查询。
• 读从库：主题列表、个人主页、历史查询、非强一致统计。
• 热点 KV：计数、会话、限流、缓存放入 Redis，定期落库。

Django 层路由

• 使用 django-db-router 或第三方（如 django-multidb-router）基于“读/写方法与查询标签”进行路由：

• SELECT → read replica（可按 shard key/一致性策略回落主库）

• INSERT/UPDATE/DELETE → primary

class ForumRouter:
    def db_for_read(self, model, **hints):
        return 'replica' if hints.get('weak_consistency', True) else 'default'
    def db_for_write(self, model, **hints):
        return 'default'

副本延迟与一致性策略

• 延迟探测：读取 pg_last_xact_replay_timestamp()，估算 replication_lag_ms，超阈值回退主库。
• 读己之写：用户发帖后返回页面需要看到自己的更新——对该用户短时间（如 3~5s）将读取强制路由到主库或带上“最小 LSN”并在副本达到前回退。
• 幂等查询：允许列表页轻微旧数据，但详情页的关键字段（回复数/状态）可从 Redis 校正。

连接池与超时

• 统一 CONN_MAX_AGE、池化（pgbouncer）与超时配置：

• 主库读写超时更短（防止阻塞业务线程），副本查询超时略长；

• 大查询分页化（游标）并限制单次扫描行数或使用物化视图。

计数与轻量写

• 去直写：点赞/浏览量进入 Redis 计数（Hash 或 HyperLogLog 去重），周期性批量 UPDATE thread SET view_count = view_count + X。
• 冲突控制：批量写使用 WHERE updated_at = ? 乐观锁或 F() 原子运算，失败重试；
• 幂等写：写请求生成 idempotency_key（用户+目标+窗口），服务端 SETNX 防重。

# 幂等写示意
key = f"idem:like:{user.id}:{thread.id}:{ts//60}"
if not redis.setnx(key, 1): return  # 已处理
redis.expire(key, 120)
UserAction.objects.get_or_create(user=user, thread=thread, type='like')

分片与扩容路径

• 按租户/版块分片：为大租户或热点版块独立库实例（库级或 schema 级），应用侧以路由器选择库；
• 水平扩展：在副本上按地域部署（就近读），写仍回归单主或基于 Patroni/Stolon 做高可用主从切换；
• 索引治理：列表页复合索引（(topic_id, -updated_at)）、用户动作表分区（按月/哈希）以控制膨胀。

失败场景与降级

• 副本不可用：全站切回主库并提升缓存 TTL；
• 写放大：点赞风暴时临时关闭实时计数回显，采用“估算值 + 批量合并”；
• 主从切换：连接重试与只读检测（SHOW transaction_read_only），防止误写到只读节点。

观测与压测

• 指标：主/从 QPS、慢查询数、复制延迟 P95、连接占用、缓存命中率；
• 压测：以“首页列表 + 主题详情 + 点赞风暴 + 搜索”组成混合负载，验证在延迟 50–150ms、丢包 0.5% 下的稳定性。
• 预案演练：副本延迟飙升、主库 Failover、缓存冷启动三类脚本化演练，确保路由与降级逻辑有效。