容量演练

组织人：王芳

环境：预发

日期：0000-00-00

场景：预订创建 40 QPS

结论：40 QPS 通过，可以按此限流

一、演练结论

9月15日在预发把会议室预订打到 40 QPS，持续 15 分钟。P99 为 280 毫秒，错误率 0.04%，没有出现两个人订到同一时段。这个水位对应六地错峰后的保护线。总部目前峰值约 4 QPS。张伟确认生产限流维持 40 QPS。80 QPS 不在本次通过范围，那一档的索引问题另有记录。

二、场景设置

1. 预发 2 台 4 核应用，数据库 1 主 1 从，预订表 1.8 万行。
2. 2,000 个独立工号，每个最多成功 1 次，避开单人 10 秒 3 次的限制。
3. 房间按总部 12 间循环。企业微信用挡板，固定 30 毫秒成功。
4. 演练 14:00 开始，15:10 结束，中间含 10 QPS 的 10 分钟热身。

三、结果

40 QPS 档结束后 1 分钟，成功率回到 100%。陈静抽了 10 条被限流拒绝的请求，预订表没有对应新行。拒绝文案是「当前预订人数较多，请稍后再试」。

四、后续

生产限流保持 40 QPS，由刘洋写在配置里。若研发园开放首日超过 15 QPS，周敏可临时调到 30，并在群里写恢复条件。下次演练放在索引进入生产之后，目标看 80 QPS 能否也落到 300 毫秒以内。王芳把本次四档的原始数存了 30 天。热身 10 QPS 的 10 分钟里，主库 CPU 稳定在 18% 至 20%。40 QPS 档的第 8 分钟 CPU 到过 44%，随后回到 41%，没有触发限流之外的拒绝。陈静据此在配置说明里保持 40 这条保护线。演练账号用完后，王芳按批次号删除了 2,000 个工号下的成功预订，删除 1,186 笔，预发房间恢复到演练前的占用。生产数据没有被这次演练写入。预发在删除后抽查 3 楼第一间，占用回到演练前的 4 段，王芳 15:40 确认。