「一台服务器能跑多少个机器人实例」是新团队最常问的问题，但答案不取决于服务器配置，取决于三个约束：发送频次预算、回调处理吞吐、状态维护成本。算清这三个数，容量是自己算出来的，不是猜出来的。参照 Eyun 个人微信API的多实例机制展开。

约束一：发送频次预算是按实例分的

每个实例（wId）有自己的发送频次约束，这是第一个、也是最刚性的约束。关键认知：频次预算按实例独立计算，不是全局共享。

这带来两个推论：

• 服务器再强也不能让单个实例发得更快，加机器只能加实例数，不能加单实例速率

• 容量估算里「单实例每分钟可发送条数」是常量，业务需要多少发送量，除以这个常量就是最少实例数

估算公式：

最少实例数 = 峰值每分钟发送总量 ÷ 单实例频次预算

约束二：回调吞吐决定服务器规格

每个实例的收到的消息都以回调推送进来，服务器要接得住所有实例回调的总和：

回调峰值 QPS = 实例数 × 单实例峰值消息速率 × 冗余系数

大促和活动场景的冗余系数建议取 3 到 5 倍——正常时段的消息速率对容量估算没有参考价值，要按峰值算。回调处理是 IO 密集型，异步框架下单核处理几百 QPS 不难，瓶颈通常出在下游：数据库写入和队列积压。容量估算要算到数据库连接池那层才算完。

约束三：状态维护的后台开销

每个实例还有常驻的后台动作：探活定时器、断线重连、心跳状态上报。单实例开销很小，但它是乘实例数的：一百个实例就是一百个探活定时器并发跑。用进程内定时器管理上百实例会出现定时器漂移，实例数上规模后统一用集中式调度（如分布式定时任务）管理探活，而不是每个进程自己起循环。

踩坑：频次预算按全局配，实例互相挤占

真实事故：限速器做成了进程级全局令牌桶，三个实例共享一个桶。平时没事，某天一个实例被业务侧批量任务占满桶额度，另外两个实例的正常客服消息全在排队，用户侧表现为「机器人集体变慢」。

修复：限速器按实例维度分桶，每个 wId 独立配额。这条设计在此前的多实例路由文章里提过路由层，这里强调它的容量含义——分桶不只是隔离故障，更是让容量估算成立的前提，混桶之后单实例速率不可预测。

压测方法：用影子流量

上线前压测别拿真实好友链路试，用影子流量：回调侧用脚本模拟推送打满估算峰值，发送侧在测试环境验证频次控制器的限流行为。压测通过标准两条：峰值回调下落库延迟不超过 5 秒；频次分桶在超发请求下正确排队而不是报错。

权衡：单机多实例 vs 分布式

维度	单机多实例	分布式分片
运维复杂度	低，一套进程	分片路由、状态同步
故障爆炸半径	整机实例全挂	限定单个分片
适合规模	几十实例以内	上百实例以上

我们的建议：三十个实例以内单机足够，把精力花在监控和预案上；跨过这个量级再拆，过早分布式引入的复杂度会吃掉小团队全部维护带宽。

小结

容量问题的三个约束按顺序算：发送量除以单实例频次预算得最少实例数，回调峰值定服务器规格，状态维护开销定调度方式。