万级房间并发：机器人集群的容量规划方法

“我们支持一万间房”是一句无法做容量规划的承诺：一万间斗地主房和一万间四人麻将房的决策负载差着数倍。正确的容量单位是决策QPS——房间数、每房AI位数、平均决策频率三个数乘出来，需要多少服务器才有得算，扩容和限流也才有依据。

估算公式本身很简单，功夫全在参数取值：每房AI位按玩法取值（四人麻将常配3位、斗地主2-3位），平均决策频率由真人节奏决定——一桌每人每20-30秒出一手，单个AI位每秒约0.04次决策。代入万级房间得到千次量级的基线QPS，再乘高峰系数，才是要建设的容量。

// 容量估算：QPS = 房间数 x AI位 x 单位决策频率
baseline_qps    = rooms * ai_seats * decisions_per_seat_per_sec
                = 10000 * 3 * 0.04        // 约 1200 QPS
peak_qps        = baseline_qps * 2.5      // 晚间高峰约 3000 QPS
capacity_target = peak_qps * 1.3          // 预留30%余量

决策服务必须无状态：每次请求携带局面上下文或上下文引用，服务实例随时可增可减、可发布可回滚，扩容才是改副本数而不是迁移数据。状态分两层放——热状态（当前局面、对手画像）放会话层缓存，冷状态（历史对局、审计）落存储层，决策实例只做纯计算。无状态不是架构洁癖，是弹性的前提。

棋牌流量集中在晚间高峰，决策负载同步放大2-3倍，弹性策略要按这条日曲线预置而不是临时扩容：高峰前30分钟预热副本——模型加载与特征缓存预热的成本不低，冷启动实例第一分钟的延迟不可接受；高峰过后再释放。按小时粒度的水位曲线比任何自动伸缩算法都可靠，因为棋牌的流量模式是天级别可预测的。

容量必须按水位管理并配分级动作：水位低于60%正常运行，60%-80%触发预热扩容，80%以上进入限流。限流分级的原则是先降“贵”的再降“快”的——第一级关闭非关键计算（聊天建议、情绪附加项），第二级切换轻量模型兜底，第三级对新增会话排队。任何一级都不允许拒绝已有牌局的决策请求，那等于当着玩家的面宕机。

降级预案要演练过才算数：轻量模型的牌力下限、排队时的think_ms补偿、缓存兜底的陈旧度上限，都要在压测里验证后写进预案。容量规划的最后一步不是算出数字，而是把数字变成每周复盘的水位报表——水位连续一周高于70%，就是扩容工单的触发线。