多节点部署

先把单节点的渠道、令牌和完整请求链路跑通，再扩容。多节点不会自动消除数据库瓶颈，也不等于所有内存状态都已共享。

拓扑建议

客户端 → HTTPS 负载均衡 → 网关 A / 网关 B
                         ↓         ↓
                       共享主数据库
                         ↓         ↓
                         共享 Redis

所有节点需要连接同一个主数据库，使用相同代码版本和一致的关键配置。共享 Redis 用于共享限流与缓存；日志库可单独配置。

必须统一的配置

配置	要求
SQL_DSN	指向同一主数据库
SESSION_SECRET	所有节点使用相同持久化随机值
CRYPTO_SECRET	共享 Redis 的节点使用相同有效值；未设置时跟随会话密钥
REDIS_CONN_STRING	需要共享限流时连接同一 Redis
SESSION_COOKIE_*	与对外控制台 Origin 保持一致
NODE_NAME	每个节点用不同名称，便于查日志

NODE_TYPE 的从节点值是 slave，不是随意填写 worker；哪些后台工作由主节点承担需结合部署版本检查。升级迁移期间避免旧、新主节点并发运行迁移。

Redis 拓扑会改变什么

共享 Redis 时，登录会话撤销与版本发布通过共同缓存传播。各节点使用独立 Redis 时，会话状态最迟在该节点缓存 TTL 到期并回源后收敛，窗口受有效 SYNC_FREQUENCY 约束；限流则各自独立计数。不用 Redis 时会话回源数据库，限流仍按各节点内存计数。

因此，不能把单节点限流值直接当成独立 Redis 集群的总限额。调大同步周期也会延长独立 Redis 的状态陈旧窗口。

扩容验证

1. 在每个节点直接检查 /api/status，再检查负载均衡入口。
2. 用同一网关令牌分别请求两个节点，核对渠道和模型一致。
3. 测试登录刷新与会话撤销，观察实际共享拓扑。
4. 检查长连接在代理空闲超时和节点重启时的行为。
5. 检查后台任务是否按预期运行，避免以为增加节点就自动增加轮询能力。

准确的会话传播说明可阅读仓库 docs/authentication.md。本页为部署设计参考，不是已完成的多节点容量测试报告。