企业官网建设流程全解析

1. 项目概述：为什么大模型 API 配额管理不再是“加个计数器”就能解决的事

最近三个月，我帮三家做 AI 应用的团队做过 API 网关层的配额治理改造，无一例外都卡在同一个地方：前端显示“剩余调用次数：87”，后端日志却爆出“超额调用 23 次”，用户还在抱怨“明明还有额度，为什么突然报错”。问题根源不在代码写得烂，而在于所有人默认的“先查再扣”逻辑——它在单机环境里跑得稳，在真实生产环境里就是定时炸弹。你查到余额是 100，三个人同时发起请求，每人扣 1，结果四次请求全成功，实际扣了 4，但系统只记了 1 次。这不是并发 bug，这是原子性缺失。

“大模型 API 配额防透支”这八个字，表面看是计费控制，背后其实是多租户场景下资源边界的生死线。一个 SaaS 平台里，A 客户买了 1000 次/天的 GPT-4 调用额度，B 客户买了 5000 次/天的 Claude 3 调用额度，C 客户用的是免费试用版，限额 50 次。他们共用同一套 API 网关，共享同一组 Redis 实例。如果不用原子操作，A 客户在流量高峰时瞬间打爆自己的额度，B 客户的请求就会被错误拦截；更糟的是，C 客户的试用额度可能被恶意刷空，导致整个租户池的风控策略失效。这不是理论风险——我们上个月就遇到过某教育平台因配额透支触发熔断，导致 17 所学校的智能批改服务集体中断 42 分钟。

Redis + Lua 的组合之所以成为行业事实标准，并非因为它们多酷炫，而是因为它们解决了三个不可妥协的硬约束：毫秒级响应、跨命令原子性、无状态可水平扩展。你不能用数据库事务，因为 PG 的行锁在万级 QPS 下会排队成瀑布；你也不能用本地内存计数器，因为网关集群里每个节点都有自己的内存，根本无法协同。而 Redis 的单线程模型天然保证 Lua 脚本内所有操作要么全执行，要么全不执行，连“查余额→判断是否足够→扣减→返回结果”这四步都能打包成一个不可分割的动作。我实测过，在 Redis 7.0 + Lua 脚本模式下，单实例处理配额校验的 P99 延迟稳定在 1.8ms 以内，比用 Spring Cache + 分布式锁方案快 6.3 倍，且失败率趋近于零。

这个方案真正落地时，你会发现它远不止是“防透支”这么简单。它倒逼你重新梳理租户模型：API Key 必须绑定租户 ID 而非单纯用户 ID；配额策略必须支持按模型、按请求类型（chat/completion/embedding）、按时间窗口（日/周/月）多维切片；甚至还要预留 Hook 位置，让运营人员能手动调整某客户的额度而不重启服务。所以当你看到标题里“多租户治理实战”这几个字，别以为只是加个 tenant_id 字段——它意味着你要把整个计费体系从“功能模块”升级为“基础设施能力”。

2. 核心设计思路：为什么必须用 Lua 脚本，而不是 Redis 原生命令组合

2.1 “先查后扣”为何在分布式环境下必然失败

很多人第一反应是：“Redis 不是有 INCRBY 吗？直接扣减，扣完再查余额不就行了？” 这是个典型的经验陷阱。INCRBY 确实是原子的，但它只解决“扣”的问题，没解决“判”的问题。真实业务逻辑永远是：“如果当前余额 ≥ 扣减量，则扣减并返回成功；否则返回余额不足”。这个“if-else”分支判断，必须和扣减操作在同一个原子上下文中完成，否则就会出现经典竞态条件（Race Condition）。

举个具体例子：租户 A 当前配额余额为 5，现在有 3 个并发请求同时到来，每个请求要扣 3 次调用。

• 请求 1 执行GET quota:A→ 返回 5
• 请求 2 执行GET quota:A→ 返回 5（此时请求 1 还没扣）
• 请求 3 执行GET quota:A→ 返回 5
  三个请求都判断“5 ≥ 3”成立，于是各自执行DECRBY quota:A 3。最终quota:A变成 5 - 3 - 3 - 3 = -4，超额透支 4 次。而系统记录的“已用额度”却是 9，远超购买的 5 次。这种错误不是偶发，只要并发度超过 2，概率就接近 100%。

有人会说：“那我用 WATCH/MULTI/EXEC 呢？” 理论上可行，但实测中会暴露两个致命缺陷：第一，WATCH 是乐观锁，一旦发生冲突（即被监控的 key 在事务执行前被修改），整个事务会回滚重试，高并发下重试率飙升，P99 延迟从 2ms 拉长到 150ms；第二，WATCH 只能监控单个 key，而我们的配额校验需要同时读取租户基础额度、当前已用额度、模型专属额度等多个 key，WATCH 无法覆盖这种多 key 场景。我们曾在线上灰度对比过，WATCH 方案在 2000 QPS 时失败率高达 12.7%，而 Lua 方案稳定在 0.03% 以下。

2.2 Lua 脚本的不可替代性：原子性、确定性与可维护性三角平衡

Redis 的 Lua 执行环境有三条铁律：单线程串行执行、脚本内所有命令原子完成、脚本执行期间不被中断。这意味着你写在 Lua 里的if判断、redis.call('GET')、redis.call('INCRBY')全部在一个不可分割的时间片里跑完。没有中间状态，没有部分执行，没有竞态窗口。

更重要的是，Lua 脚本具备确定性（Determinism）。Redis 规定：脚本内只能调用纯函数命令（如 GET/INCRBY/EXPIRE），禁止调用随机命令（如 SRANDMEMBER）或时间命令（如 TIME），确保同一脚本在任何 Redis 实例上、任何时间点执行，只要输入相同，输出必然一致。这点对配额治理至关重要——你不能接受“同样的请求，在节点 A 返回 success，在节点 B 返回 insufficient_quota”，这会让下游服务陷入不可预测的混乱。

我们最终选定的脚本结构是“三段式”：

1. 参数解析段：从KEYS[1]（租户ID）、ARGV[1]（扣减量）、ARGV[2]（额度类型标识）提取输入；
2. 核心校验段：local balance = redis.call('HGET', 'quota:'..KEYS[1], ARGV[2])读取哈希表中的具体额度，if tonumber(balance) >= tonumber(ARGV[1]) then ...做数值比较；
3. 执行反馈段：若通过则redis.call('HINCRBY', 'quota:'..KEYS[1], ARGV[2], '-'..ARGV[1])扣减，并return 1；否则return 0。

这个结构看似简单，但经过 17 次线上压测迭代才固化下来。早期我们尝试过把额度存在 String 类型里，结果发现无法支持“按模型维度独立配额”（比如租户总配额 1000，其中 gpt-4 占 600，claude-3 占 400），因为 String 只能存一个值。后来改用 Hash 结构，HGET/HINCRBY天然支持字段级操作，一个quota:tenant_123key 就能存{"gpt4": "600", "claude3": "400", "embedding": "2000"}，既节省内存又便于扩展。这个决策背后是成本计算：Hash 的内存占用比多个 String key 低 37%，在百万租户规模下，每年节省 Redis 内存成本超 42 万元。

2.3 为什么不用其他方案：对比 Kafka、数据库、Service Mesh 的真实代价

有团队问：“能不能用 Kafka 做配额事件流？每次扣减发个消息，由消费端更新数据库。” 这听起来很“云原生”，但实测延迟不可接受。Kafka 生产者发送消息平均耗时 8~12ms，加上网络传输、Broker 写盘、消费者拉取、反序列化、DB 更新，端到端 P95 延迟达 210ms。而大模型 API 的 SLA 要求网关层处理时间 ≤ 50ms，否则用户会感知到明显卡顿。更致命的是，Kafka 无法保证“严格有序”——如果两条扣减消息乱序到达，数据库里就可能出现负余额。

也有人提议用 PostgreSQL 的SELECT ... FOR UPDATE。理论上可行，但性能瓶颈明显：PG 的行锁在高并发下会形成锁等待队列，我们模拟 5000 QPS 时，数据库连接池平均等待时间达 340ms，CPU 使用率冲到 98%，而 Redis 此时 CPU 仅 12%。而且 PG 的事务日志（WAL）会产生巨大 I/O 压力，SSD 寿命加速衰减。某金融客户曾因此导致数据库主从同步延迟峰值达 17 分钟，被迫回滚方案。

至于 Service Mesh 层（如 Istio）的限流，它本质是基于 Envoy 的本地缓存做粗粒度控制，无法实现租户级精确配额。Mesh 的限流规则下发有分钟级延迟，且不支持“按 token 数动态扣减”（大模型请求的 token 数差异极大，100 token 和 10000 token 消耗的额度应不同）。我们测试过，Mesh 方案对小请求（<500 token）误拦率 23%，对大请求（>5000 token）漏放率 18%，完全达不到生产要求。

最终选择 Redis + Lua，不是因为它最时髦，而是因为它在精度、性能、可靠性、运维成本四个维度上取得了最优解。它不解决所有问题，但完美解决了“配额原子校验”这个单一、高频、严苛的核心诉求。

3. 核心细节解析：从租户建模到 Lua 脚本的每一处魔鬼细节

3.1 租户配额模型设计：为什么必须用 Hash 而不是 String 或 Sorted Set

配额数据结构的选择，直接决定后续扩展能力和存储效率。我们对比过三种主流方案：

我们最终采用 Hash，核心原因在于字段级原子性。当用户调用gpt-4模型时，只需执行HINCRBY quota:tenant_123 gpt4 -3，不会影响claude3字段的值。如果用 String，就得先GET整个字符串，JSON 解析，修改 gpt4 字段，再SET回去——这三步无法原子化，必然引入竞态。而 Hash 的HINCRBY命令本身就是原子的，Redis 内部用 dict 结构实现，对单个 field 的增减不涉及整个 key 的锁。

更关键的是内存优化。实测 10 万个租户，每个租户存 3 个模型额度（gpt4/claude3/embedding），Hash 结构总内存占用 1.2GB；若拆成 30 万个 String key（quota:tenant_123:gpt4,quota:tenant_123:claude3...），内存占用达 1.9GB，多出 58%。这是因为 String key 本身有固定开销（redisObject 结构体 16 字节 + SDS header 8 字节），而 Hash 的 field 复用同一个 key 的 redisObject，只额外存储 field name 和 value 的 SDS。在云 Redis 按内存计费的背景下，这直接关系到每月账单。

我们还为 Hash 设计了二级 TTL 机制：主 keyquota:tenant_123设置 30 天过期，但每个 field 附加时间戳。例如HSET quota:tenant_123 gpt4 "1000|1717027200"，竖线后是 Unix 时间戳（2024-06-01 00:00:00）。Lua 脚本在读取时自动解析时间戳，若已过期则重置为初始额度。这样既避免频繁刷新整个 key 的 TTL，又保证额度按周期自动重置，运维同学再也不用手动跑 cron 任务。

3.2 Lua 脚本的健壮性设计：如何处理边界值、类型转换与错误码统一

一个能上生产的 Lua 脚本，绝不是if balance >= need then ...这么简单。我们踩过的坑，都变成了脚本里的防御性代码：

-- 1. 参数合法性校验：防止恶意输入导致脚本崩溃 if #KEYS ~= 1 or #ARGV ~= 2 then return {err="invalid args: KEYS="..#KEYS..", ARGV="..#ARGV} end local tenant_id = KEYS[1] local need_str = ARGV[1] local quota_type = ARGV[2] -- 2. 类型强转与范围检查：Redis GET 返回 string，必须转 number local need = tonumber(need_str) if not need or need <= 0 or need > 1000000 then return {err="invalid need: "..need_str} end -- 3. 安全读取：HGET 可能返回 nil，需设默认值 local balance_str = redis.call('HGET', 'quota:'..tenant_id, quota_type) local balance = tonumber(balance_str) or 0 -- 4. 防负数：即使 balance 是负数，也要允许扣减（用于透支预警） if balance < 0 then -- 记录透支事件，但不阻止请求（由上层策略决定是否拦截） redis.call('ZADD', 'overdraft:log', tostring(os.time()), cjson.encode({tenant=tenant_id, type=quota_type, over=-balance, time=os.time()})) return {code=2, balance=balance, need=need} -- code=2 表示透支，非错误 end -- 5. 核心校验：注意浮点数比较陷阱（Redis 用 double 存储） if balance >= need then redis.call('HINCRBY', 'quota:'..tenant_id, quota_type, '-'..need_str) return {code=0, balance=balance-need, need=need} -- code=0 成功 else return {code=1, balance=balance, need=need} -- code=1 不足 end

这段脚本的关键细节在于：

• tonumber()的双重校验：先tonumber(need_str)，再检查not need，因为tonumber("abc")返回nil，而tonumber("1e5")返回100000，必须过滤掉非法字符串；
• or 0的安全兜底：HGET返回nil时，tonumber(nil)是nil，nil >= 0会报错，所以必须or 0；
• 透支码code=2的设计：不直接拒绝请求，而是标记透支，让网关层根据租户等级决定是放行（VIP 客户）、降级（用 cheaper model）、还是拦截（免费用户）。这比简单返回错误更灵活；
• JSON 日志写入：用cjson.encode生成结构化日志，方便 ELK 分析透支模式，比如发现某租户连续 3 天透支，自动触发运营介入。

我们还做了性能优化：脚本里避免循环、避免大对象创建。测试发现，每多一次cjson.encode调用，P99 延迟增加 0.3ms。所以透支日志只在真正透支时写，正常请求绝不 encode。上线后，脚本平均执行时间稳定在 0.8ms，比基础INCRBY多花 0.2ms，完全在可接受范围内。

3.3 多租户隔离策略：Key 命名规范、命名空间与权限管控

Key 命名不是小事，它决定了运维的便捷性和安全的底线。我们制定的命名规范有三条铁律：

1. 租户前缀强制小写+下划线：quota:tenant_123，禁用quota:Tenant123或quota:tenant123。原因：Redis key 是二进制安全的，但运维工具（如 RedisInsight）对大小写敏感，小写统一降低排查成本；下划线比驼峰更易读，tenant_123_api比tenant123Api更清晰。

2. 业务域分层：quota:是配额域，rate:是限流域，cache:是业务缓存域。绝不混用，比如不能把配额存在cache:tenant_123下。这样在 Redis 监控里，可以按前缀统计各域内存占比，快速定位异常。

3. 敏感信息脱敏：租户 ID 绝不直接用明文邮箱或手机号。我们生成 8 位随机字符串t_8a3f2b1c作为内部 ID，映射表存在 MySQL 里。这样即使 Redis 被未授权访问，攻击者也无法关联到真实客户。

权限管控上，我们给网关服务分配的 Redis 用户只有@read和@write权限，明确禁止@admin权限。具体 ACL 规则如下：

ACL SETUSER gateway on >password123 ~quota:* ~rate:* +get +hget +hincrby +zadd +eval -flushdb -keys -config

这条规则的意思是：用户gateway只能操作quota:和rate:开头的 key，只能执行GET/HGET/HINCRBY/ZADD/EVAL命令，禁止FLUSHDB（清空库）、KEYS（遍历 key）、CONFIG（修改配置）。我们曾因忘记禁用KEYS，导致某次运维误操作KEYS quota:*扫描了 200 万个 key，阻塞 Redis 12 秒，所有 API 请求超时。ACL 是最后一道防线，必须前置配置。

对于超大规模租户（>100 万），我们还做了分片设计：按租户 ID 的 hash 值路由到不同 Redis 集群。公式是shard_id = crc32(tenant_id) % 8，8 个分片足够支撑 500 万租户。分片键必须是租户 ID，不能是 API Key，因为一个租户可能有多个 Key，必须保证同一租户的所有额度数据落在同一分片，否则跨分片事务无法实现。

4. 实操过程详解：从 Redis 部署到网关集成的完整链路

4.1 Redis 环境准备：版本选择、配置调优与高可用部署

我们锁定Redis 7.0.12作为生产版本，而非最新版 7.2。原因很实在：7.0.x 是 LTS（长期支持版），社区补丁成熟，而 7.2 新增的COPY命令对我们无用，反而增加兼容性风险。安装时坚持源码编译，禁用make test（耗时且非必需），关键编译参数：

make MALLOC=jemalloc USE_SYSTEMD=yes BUILD_TLS=yes

jemalloc内存分配器比 libc malloc 减少 23% 内存碎片；SYSTEMD支持优雅重启；TLS保证客户端连接加密，避免 API Key 在网络中明文传输。

核心配置redis.conf调优项：

# 内存管理 maxmemory 16gb maxmemory-policy allkeys-lru # LRU 驱逐，避免 OOM # 网络与性能 tcp-keepalive 300 # 5分钟心跳，及时发现断连 timeout 0 # 永不超时，由客户端控制 # 持久化（配额数据不依赖持久化，RDB 关闭） save "" # 禁用 RDB appendonly no # 禁用 AOF # Lua 安全 lua-time-limit 5000 # 脚本最长执行 5s，防死循环

特别说明：配额数据不开启持久化。因为配额是实时计费数据，如果 Redis 宕机，重启后从 MySQL 同步初始额度即可。开启 AOF/RDB 反而会拖慢写入速度，且增加磁盘 I/O 压力。我们用BGREWRITEAOF会导致 300ms 的阻塞，这是不能接受的。

高可用采用Redis Cluster模式，6 节点（3 主 3 从），跨 AZ 部署。主节点分布在不同可用区，确保单 AZ 故障不影响整体。Cluster 的ASK重定向机制对 Lua 脚本透明，EVAL命令会自动路由到目标 slot，无需网关层做分片逻辑。我们禁用了cluster-require-full-coverage no，允许部分节点故障时继续服务，避免小故障引发大面积雪崩。

监控指标我们重点盯三个：

• instantaneous_ops_per_sec：持续 > 50000 表示接近性能瓶颈；
• used_memory_rss：超过maxmemory的 85% 触发告警；
• rejected_connections：非零值说明连接池满，需扩容。

4.2 Lua 脚本注册与加载：避免每次 EVAL 的性能损耗

EVAL命令每次执行都需传输脚本字符串，网络开销大。我们采用SCRIPT LOAD预加载 +EVALSHA调用的方式。流程如下：

1. 预加载脚本（部署时执行一次）：

redis-cli --no-auth-warning -h redis-cluster -p 6379 \ SCRIPT LOAD "$(cat quota_check.lua)" # 返回 SHA1 哈希值：234a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2

2. 网关代码中调用（Java 示例）：

String scriptSha = "234a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2"; Object result = jedis.evalsha(scriptSha, Arrays.asList("tenant_123"), Arrays.asList("3", "gpt4")); // result 是 Lua 的 return 值，解析为 Map

这个方案的优势是：脚本只传输一次 SHA 值（40 字节），比传输几百字节的 Lua 字符串快 10 倍。我们压测发现，EVALSHA的 P99 延迟比EVAL低 0.4ms。缺点是脚本更新需重新SCRIPT LOAD，所以我们把脚本版本号写在注释里，部署脚本自动检测版本并 reload。

脚本热更新有个技巧：用SCRIPT FLUSH清空所有脚本，再SCRIPT LOAD新版本。但FLUSH会导致正在执行的脚本中断，所以必须选在低峰期（凌晨 2-4 点），并配合网关的降级开关——开启开关后，网关跳过配额校验，直连大模型 API，保证服务可用性。

4.3 网关层集成：Spring Cloud Gateway 的 Filter 实现与熔断策略

我们在 Spring Cloud Gateway 上实现了一个QuotaCheckFilter，核心逻辑如下：

public class QuotaCheckFilter implements GlobalFilter, Ordered { private final RedisTemplate<String, Object> redisTemplate; private final String scriptSha; // 预加载的 SHA @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { String tenantId = resolveTenantId(exchange); // 从 JWT 或 Header 解析 String model = resolveModel(exchange); // 从请求 body 解析 model 字段 int tokens = estimateTokens(exchange); // 估算 token 数（见下文） // 构造 Lua 参数 List<String> keys = Arrays.asList(tenantId); List<String> args = Arrays.asList(String.valueOf(tokens), model); // 执行 Lua 脚本 RedisScript<Object> script = RedisScript.of(scriptSha, (Class<Object>) Object.class); Object result = redisTemplate.execute(script, keys, args); if (result instanceof Map) { Map<String, Object> resMap = (Map<String, Object>) result; int code = Integer.parseInt(resMap.get("code").toString()); switch (code) { case 0: // 成功 return chain.filter(exchange); case 1: // 不足 return writeError(exchange, "insufficient quota"); case 2: // 透支 log.warn("Tenant {} overdraft for {}", tenantId, model); return chain.filter(exchange); // 放行，但打日志 default: return writeError(exchange, "quota check error"); } } return writeError(exchange, "invalid quota response"); } }

关键难点是token 数估算。大模型 API 的配额通常按 token 计费，而非请求数。我们不能等请求体到达再解析（太慢），而是用ServerWebExchange的getFormData()提前获取messages字段，用开源库tiktoken-java快速估算：

private int estimateTokens(ServerWebExchange exchange) { try { String body = exchange.getAttributeOrDefault("cachedRequestBody", ""); if (body.isEmpty()) return 100; // 默认值 // 简化版：统计中文字符数 * 2 + 英文字母数，误差 < 15% long chinese = body.codePoints().filter(c -> c >= 0x4e00 && c <= 0x9fff).count(); long english = body.codePoints().filter(Character::isLetter).count(); return (int) (chinese * 2 + english); } catch (Exception e) { return 100; } }

这个估算虽不精确，但足够用于配额拦截。精确 token 数由大模型 API 响应头x-ratelimit-remaining-token返回，我们用它做二次校准，写入 Redis 修正额度。

熔断策略我们设了三级：

• 一级熔断：Redis 响应超时（> 50ms）或失败率 > 5%，自动切换到“无配额校验”模式，保证 API 可用；
• 二级熔断：连续 3 次SCRIPT KILL（脚本超时），触发告警并暂停该租户的配额校验 5 分钟；
• 三级熔断：Redis Cluster 整体不可用，网关降级为“按租户等级限流”，VIP 客户 100 QPS，普通客户 10 QPS。

4.4 配额初始化与同步：MySQL 到 Redis 的双写一致性保障

配额数据源头在 MySQL 的tenant_quota表：

CREATE TABLE tenant_quota ( id BIGINT PRIMARY KEY, tenant_id VARCHAR(32) NOT NULL, model_type VARCHAR(20) NOT NULL, -- 'gpt4', 'claude3' total_quota BIGINT NOT NULL, -- 总额度 used_quota BIGINT DEFAULT 0, -- 已用额度 reset_time DATETIME, -- 重置时间 UNIQUE KEY uk_tenant_model (tenant_id, model_type) );

Redis 配额初始化不是简单INSERT INTO ... SELECT，而是用变更数据捕获（CDC）实现最终一致性。我们用 Debezium 监听 MySQL binlog，当tenant_quota表有INSERT/UPDATE时，发送消息到 Kafka，消费端执行：

// Kafka 消费逻辑 public void onMessage(QuotaUpdateEvent event) { String key = "quota:" + event.getTenantId(); String field = event.getModelType(); String value = event.getTotalQuota() + "|" + event.getResetTime().getTime(); redisTemplate.opsForHash().put(key, field, value); // 设置主 key 过期时间（30天） redisTemplate.expire(key, 30, TimeUnit.DAYS); }

这个方案避免了定时任务的延迟（如每小时同步一次，最大延迟 1 小时），保证 MySQL 更新后 200ms 内 Redis 生效。我们还加了幂等校验：Kafka 消息带event_id，Redis 用SETNX quota_sync_lock:tenant_123 event_id EX 60防止重复消费。

对于历史数据迁移，我们写了专用脚本，分批次导出（每次 1000 行），用Pipeline批量写入 Redis，避免单条命令的网络往返开销。100 万租户数据迁移耗时 8 分钟，比单条HSET快 17 倍。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪经验

5.1 典型问题速查表：从报错现象到根因定位

5.2 独家避坑技巧：来自三次线上事故的教训

技巧一：给 Lua 脚本加“心跳探针”，提前发现潜在阻塞
我们写了一个守护进程，每 30 秒执行一次轻量脚本：

-- probe.lua return {time=os.time(), version="1.0"}

如果EVALSHA耗时 > 5ms，立即告警。这比等用户投诉快 10 分钟。上线后，我们提前发现了一次lua-time-limit被误设为 100ms 的配置错误，避免了大规模超时。

技巧二：用DEBUG SEGFAULT测试脚本健壮性（仅限测试环境）
在测试 Redis 上执行DEBUG SEGFAULT会强制崩溃，然后观察脚本是否能在重启后正确恢复。我们发现旧版脚本在崩溃后，HINCRBY的中间状态丢失，