乐悠厨房这个标题看起来像一串乱码，但它不是乱码。99999999，是我们线上一次事故里真实存在的配置值，也是我见过最典型的“把有限变无限”的翻车现场。
那阵子业务要做一波大促放量，运营反馈说接口网关的风控限流把真实用户给卡掉了。为了不误伤正常请求，团队里有人直接在配置中心把单用户每分钟的调用阈值从 100 调到了 99999999。当时看这个操作很合理：阈值足够大，不就等于不限制了。改完的当晚确实一切太平，谁也没想到三天后的深夜，监控全红，核心服务抖了整整两三个小时，最后把值改回 100 才稳住。
这篇文章我打算把这个过程完整复盘一遍，包括那条变更单是怎么进去的、限流组件内部发生了什么、我怎么从监控一步步定位到这个 8 位数字，以及后来团队把这类“假无限”从架构里清出去的方案。如果你也在系统里见过 99999999、999999、2099-12-31 这类“值”，那这篇文章应该能帮你少走点弯路。
1. 从“放开限制”到“全员进不去”：一条变更单引发的线上险情
1.1 第一次改动：为了让真实用户不被误伤
先说背景。我们的网关有一个针对用户维度的限流规则，目的是防止单个账号高频刷接口，活动页的“领取权益”和“查询订单状态”都走这套规则。最开始的阈值是每分钟 100 次，按正常用户的操作习惯绝对够用，但对脚本和爬虫来说，100 次很快就能触发拦截。
大促前做全链路压测时，问题来了。我们内部压测工具为了方便，共用了一批测试账号，跑起来之后每个人的请求频率远高于每分钟 100 次，于是大量请求被限流直接拦掉，压测数据根本没法看。更麻烦的是，有一部分真实用户的操作路径比较特殊，比如一边开着多个页面、一边反复点击领取按钮，也会触发拦截。
群里开始有人反馈“活动页进不去”“一直转圈”。查了一下，限流日志里大量出现 blocked by rate limit, key=xxx。当时距离活动正式上线只剩几个小时，产品给出的诉求是“先让用户能进去，别让规则挡人”。于是，最快的方案就是把阈值调大。
从 100 调到 99999999，就是那一刻发生的。
这个操作本身不复杂。配置中心里有现成的键，修改之后可以自动热加载，不需要发版，不需要重启网关。大概三十秒，新的规则就生效了。
1.2 为什么改完的当晚反而“很稳”
说实话，改完当晚系统指标确实很平稳。限流拦截日志立刻少了，原来被打回来的请求也都能正常往下走，业务方没有继续投诉。
但“平稳”本身就是一种假象。它意味着原本被限流挡在网关层的流量，已经能够穿透到更后面的服务。网关只是第一道闸，真正的压力被转移到了下游的订单服务、用户服务和数据库上。只不过那晚整体请求量还不够大，下游还能扛得住。
第二天白天，请求量逐步上涨，网关转发量开始明显增加，我们以为是活动预热带来的正常增长，没有太在意。现在回看，那其实就是风险在积累。
到了第三天凌晨，业务方在整点配置了一波定时任务，大量用户同一时间收到活动提醒并涌入接口，流量一下子比平时涨了七八倍。系统先是从数据库连接池等待开始出现超时，紧接着服务间的调用链全链路超时，最终整个活动链路瘫痪，用户看到的就是“页面能打开，但点击没有任何反应”。
1.3 把值直接改到 99999999 为什么没有触发任何校验
很多人问，这么大的值修改，难道没有校验机制吗？
我们当时的配置中心确实没有针对这个键做范围限制。校验规则只判断了“是否为正整数”，没判断“是否合理”。100 是正整数，99999999 也是正整数，所以校验顺利通过。
这类问题不只出现在配置中心。很多后台管理系统的表单校验也只做类型和必填校验，对数值的上下边界没有约束。你以为自己在填“一个很大的数字”，系统也没有理由认为这不对，但它并不知道这个数字会被写进一个和流量控制强相关的核心链路。
这次事故之后，我养成了一个习惯：凡是配置里出现超过业务数量级太多倍的值，都要追问一句“如果这个值真实生效，会发生什么”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 8 个 9 真的等于“不限量”吗？限流组件内部到底怎么理解这个值
2.1 把阈值放大后，限流器的行为是什么
从业务语义上讲，99999999 约等于不限制。但从技术实现上讲，它和“不限制”完全不是一回事。
我们用的限流器是一个基于滑动窗口的实现，每次请求进来会先做一次计数累加，再和阈值做比较。简化后的逻辑大概是：
javascript复制// 简化版伪代码：滑动窗口限流
async function checkRateLimit(key, limit, windowMs) {
const current = await redis.incr(key);
if (current === 1) {
await redis.expire(key, Math.ceil(windowMs / 1000));
}
if (current > limit) {
return { allowed: false };
}
return { allowed: true };
}
这段代码的一个关键点是：就算你把 limit 设成 99999999，Redis 的 INCR 也照常执行，key 的过期时间也照常设置。也就是说，限流器并没有因为阈值变大而变成一个“空操作”，它仍然在每一个请求进来时做一次 Redis 操作。
平时流量小，多一次 Redis 访问没什么感觉。但在流量放大七八倍的深夜，每个进来的请求都先到 Redis 里做一次 INCR，这个操作本身就成了瓶颈。Redis 的连接数和内存占用同时飙升，限流器组件率先扛不住，开始大量报错。
这里我想多解释一点：限流不只是一个“拦人”的组件，它本质上也是一个“分流”的组件。它通过把一部分请求挡在前面，来保护下游的服务能力。你把阈值调到 99999999，等于主动放弃了这层保护，但 Redis 计数器仍然承担着无意义的写入，等于保护没得到，框架的消耗倒是一点没少。
2.2 上游 “放行” 后，压力去了哪里
真正让系统崩掉的不是网关本身的转发，而是被放行后到达下游的流量。
我们的活动链路大致是：网关 -> 活动服务 -> 订单服务 -> 数据库。原先限流规则每分钟最多允许单个用户请求 100 次，对于接口整体来说，大部分脚本请求会在网关层被拦截，根本到不了后面的订单服务。
把限制调到 99999999 之后，单个用户的请求基本都能穿透网关。单个用户打不出那么高流量，但架不住账号太多、并发太高。活动服务为了响应这些请求，会同步去查库存、查用户权益、查订单状态，每个查询背后都是一次或者多次数据库操作。数据库连接池很快被占满，新的查询全部在等待连接，等待时间一长就变成超时，服务端开始报错。
这还没完。最常见也最容易被忽略的，是客户端的重试机制。用户看到页面没反应，会本能地反复点击，而 App 端自己也有一套失败重试逻辑，每失败一次就往网关再发一个请求。原本一波流量进来了，系统处理不了，超时报错又引发重试，重试流量再次涌入网关，这就是典型的流量放大效应。
如果没有限流在最前面拦截这一层，系统根本没有机会从超时状态里恢复出来。
2.3 为什么“一个非常大的数”不等于“没有限制”
做系统设计时，我们经常会把“不能做的事”投射成“一个不可能达到的阈值”。但代码不认业务语义，代码只认比较结果。
在固定窗口和滑动窗口算法里，若阈值是 99999999，只要窗口期内请求总数没超过这个数，所有请求都放行。它在一段时间内和“不放行任何限制”效果上很像，但它仍然会占用窗口计数器的存储资源，也仍然会在极端情况下触发反转。
如果你需要表达的语义是“这里不做限制”，更好的做法不是把阈值改成超大数，而是直接用另一个字段去表达“关闭限流”。这个字段可以是枚举，可以是布尔开关，唯独不应该是一个可以被计算、被比较、被取余的数字。
3. 从“流量随便进”到“数据库打满”：完整排查链路还原
3.1 最先看到的异常指标
事故发生在凌晨，告警先是从订单服务的平均响应时间开始的，曲线从之前的 40ms 一路拉高到 3000ms 以上。紧接着是网关的错误率，5xx 状态码开始大量出现。再往下看，数据库的连接池使用率已经到了 100%。
刚看到这个现象时，我们的第一反应是“某个 SQL 慢查询拖垮了数据库”。于是先让 DBA 拉了一把慢查询日志，也确实看到几条 SQL 的执行时间异常。但仔细一看，这些 SQL 本身很简单，索引也完全正常。不是慢查询导致的故障，是大量请求堆积之后，每条 SQL 要排队等执行时间变长，被误记录成了“慢查询”。
这是一个很典型的排查误区：数据库慢只是结果，不是原因。真正要问的是，为什么突然有这么多请求进来。
3.2 从调用链里一步步找根因
接下来我们在全链路追踪系统里筛选了网关到活动服务的调用记录。正常的调用链应该是：网关做一次鉴权，检查限流，然后转发到活动服务。但我看到相当一部分请求在网关层的“限流检查”这一步耗时明显偏长，再仔细看，这部分请求并没有进入后续的转发流程，而是卡在了和 Redis 通信的过程里。
这说明网关组件本身已经出问题了。点开限流器的监控面板，我发现一个矛盾现象：错误数很高，但“被拦截请求数”几乎是 0。
这个现象很关键。正常情况下，如果限流规则还在工作，总会有一定比例的请求被拦截；如果规则没生效，那限流器不应该报错。两个指标同时出现，最合理的解释是：限流器在 Redis 上做的计数操作失败了，规则没法正常判断，默认放行了这些请求。
我们顺着限流器的时序查询了网关日志，看到每条请求的打点里都带着一个 limit=99999999。到这一步，问题基本清楚了——不是哪个机房网络抖动，而是这个配置把规则退化成了一种“永远不可能拦截”的状态。
3.3 配置中心里的变更记录帮我们确认了原因
我们又去配置中心查了变更历史，发现这个值的修改时间正好在活动压测阶段。当时为了放行压测流量，有人手动把单用户每分钟的阈值从 100 调成了 99999999，活动上线后忘了收回来。
其实这个时间点距离事故已经过去了接近七十二小时。也就是说，系统在一种“把限流废掉”的状态下运行了整整三天。前两天的流量没有达到临界点，系统还能强撑，第三天达到峰值后，整个链路便迅速崩盘。
恢复操作倒是很直接：把阈值从 99999999 改回每分钟 100，同时重启了限流器组件，让 Redis 里已经堆积的计数 key 清掉。大约过了一两分钟，错误率开始下降，几分钟后数据库连接池逐步释放，系统恢复正常。
这次恢复得快，是因为我们已经定位到了直接原因。但复盘时大家都很清楚：如果不改掉“用超大数字表达不限制”的习惯，下一次换个场景，同样的问题还会再出现。
4. 给“不受限”一个明确的业务语义：方案改造与代码落地
4.1 用开关表达策略，不用量值表达策略
恢复之后，我们做的第一件事，是把限流配置从“一个整数阈值”重构为“一个策略 + 一个阈值”。
原来的配置是这样的：
json复制{
"rate_limit": {
"enabled": true,
"limit_per_minute": 100
}
}
当我们需要临时放行时，最直接的做法是把 limit_per_minute 调大，也就是这次事故的做法。
重构之后，配置变成了这样：
json复制{
"rate_limit": {
"mode": "monitor",
"limit_per_minute": 100
}
}
mode 有三个可选值：enforce 表示强制拦截，monitor 表示不拦截但记录日志，off 表示彻底关闭限流检查。
关键差异在于，monitor 模式下，网关仍然会执行限流器的计数逻辑，也会把判断结果写进日志，但它不会真正拦截请求。这样既不影响正常用户，又能在日志里保留“如果规则生效，会有多少人被拦下来”的信息，为后续的阈值调整提供依据。
off 模式则是直接跳过限流器计数，不再和 Redis 通信，从代码上杜绝了因为一个超大 value 导致 Redis 连接被打满的问题。
在 Java 代码里的体现大致是：
java复制if (ProtectionMode.OFF.equals(mode)) {
// 跳过限流器，不进 Redis，只记一个审计日志
auditLogger.info("rate_limit_bypassed, key={}", key);
return true;
}
if (ProtectionMode.MONITOR.equals(mode)) {
boolean blocked = rateLimiter.isOverLimit(key, limitPerMinute);
auditLogger.info("would_block={}, key={}", blocked, key);
return true;
}
// enforce 模式：真正执行拦截
return !rateLimiter.isOverLimit(key, limitPerMinute);
如果你只想做最小改动，那至少也应该把“关闭限流”做成一个明确的布尔开关 rate_limit_enabled=false，而不是把限流阈值改成 99999999。关闭和放大，在语义上是两件完全不同的事。
4.2 配置安全边界：超范围告警而不是直接生效
除了调整配置结构，我们还在配置中心加了一层取值范围的强校验。当然，这不是说每个键都硬编码一个最大值，而是根据键的用途做分类。
比如 limit_per_minute 这个键，正常业务不会有单用户每分钟超过 10000 次调用的场景。我们就在校验规则里加了一条：如果新配置值大于 10000，则拒绝保存，除非有二次审批。
如果某些特殊情况确实需要临时放开，系统也支持一种临时变更方式：变更单必须填写原因和自动过期时间。比如申请“这个值改为 1000000，有效期 30 分钟”，到期后配置中心会自动把值回滚到上一个稳定版本。
这个机制很实用。它不会妨碍真正需要应急处置的场景，但能防止“放开后忘记收回”这种最基础的人为失误。
4.3 取消放行后，如何找到真实的容量水位
阈值恢复成 100 只是让系统回到了原来的状态，但原来的状态也不是最优状态。活动期间真实用户到底需要多高的阈值？系统到底能扛住多大流量？这些都是未知数。
我们做了一次更细致的压测，结论是：活动页正常的单用户请求频率大概在每分钟 5 到 10 次，加上一些异常操作和同事之间的在线协作，大部分用户不会超过每分钟 30 次。把我们之前的 100 次阈值放到真实业务里去评估，其实已经非常宽裕了。
真正需要重新设计的是网关整体能做到多少 QPS，而不是单个用户能请求多少次。我们依托压测平台逐步加压，找到活动服务在可接受延迟范围内的最佳容量值，再把网关的集群节点和限流阈值做了一次匹配调整。
这就是我想要强调的思路：限流不只是挡用户，它其实是系统容量的一道闸门。你必须先知道自己最多能放多少流量，再决定闸门开多大。单纯把闸门拆掉，没有意义。
5. 比 99999999 更常见的“假无限”：这些极值约定都值得清理
5.1 有效期、库存、计数上限里的“假无限”
那次事故之后，我在团队内部发起了一次“假无限排查”，专门找代码里那些用超大数值表达特殊含义的地方。一找才发现，99999999 只是一个典型案例，类似的约定散落在各个业务里。
最常见的是“会员有效期”。表设计时为了表示“永久会员”，很多人不喜欢用 null，觉得为空的字段不好处理，于是约定把过期时间设为 9999-12-31 23:59:59。这个值在普通查询里没问题，但在计算“剩余到期天数”或做任务调度时，需要额外处理这个特殊日期。一旦写成 days = expire_time - now，算出来的结果是一个巨大无比的天数，可能超出前端展示范围，也可能在后续的取模计算里产生奇怪的数字。
还有库存上限。有些人库里没有出清概念，就把可售库存初始化成 99999999 表示“随便卖”。但在秒杀系统里，超卖判断常常依赖库存扣减后的剩余值，初始值越大，并发扣减时的冲突概率和处理成本就越高。更麻烦的是，运营并不知道库存到底剩多少，只知道一个天大的数字。
再比如“重试次数”。我之前遇到过有人把失败重试次数设为 10，结果接口每次都要等三十秒超时后再重试，最坏情况下单个请求会卡五分钟，用户那边早就超时离开了。这类数值越大，代表容错空间越大的直觉，在分布式系统里往往会造成反效果。
5.2 在团队约定里增加“字面量禁区”和自动化检查
要系统性地解决这类问题，不能只靠代码 review 时的一句“这里别用这么大的数”。我建议把常见的“假无限”模式列入代码规范的检查规则里。
我们在静态检查工具里加了几条规则：
- 代码里不允许出现超过 999999 且含义模糊的直接量，除非在常量定义处做了详细注释；
- 所有表示“永久”“不限制”“无上限”的字段，优先使用
null配合默认值处理； - 如果外部接口必须返回一个具体的未来时间或超大值，要在出参 DTO 上直接注明语义；
- 新表字段涉及时间或次数时，默认不允许直接写“超大值当特殊状态”，要先和产品确认业务语义。
有同学问，用 null 不是会更麻烦吗？每次取值都要判空。我的观点恰恰相反：判空才说明代码里明确知道这个字段可能有特殊状态，而一个 99999999 会让所有下游把它当成普通数字去计算，风险更隐蔽。麻烦一点，总比线上出事故强。
自动化检查也很容易做。静态检查工具里可以自定义一个规则，扫描所有魔法数字。即使做不到完全禁止，至少能保证每个大数字出现在常量区时都带着清晰的注释。排查困难从来不是因为你找不到那个数字，而是你不确定这个数字到底是普通业务数据，还是一个代表特殊含义的暗号。
那次事故之后，我把线上的“不限量”配置全部改成显式关闭，把“永久时间”改成 null + 业务默认值，把库存里的大数初始化也改成了合理值。过程不算难，但要求团队里有一个人愿意把这些细节盯到底。
如果非要用一句话总结这段经历，那就是：技术系统里没有一个数字是“随便写写”的，你让数字承担它不该承担的语义，总有一天它会以最意外的方式还回来。9 这个数字看着吉利，在配置里一点都不吉利。