AISIX 1.4.0：启动时 Redis 不可达的降级服务与使用量有界重试

更新时间 9/22/2026

当 AI 应用正在接收请求时，它的网关可能不仅在等待模型提供商：Redis 可以保存共享限流计数器或缓存状态，etcd 可以保存配置，控制面则接收使用量数据。某个依赖发生故障不应自动演变成所有调用方的故障——但只有运维人员能够看清哪些能力已经降级、投递保证如何变化，继续转发流量才有意义。

AISIX 1.4.0 于 2026 年 9 月 22 日发布，让这一运维边界更加清晰。它的核心并不是“依赖不再重要”，而是在特定的启动和投递失败期间，让网关能够继续提供服务，同时暴露这条降级路径的限制。

仍需区分产品与部署边界：AISIX 在你的环境中处理网关流量；AISIX Cloud 提供控制面、控制台、组织管理和集中式使用量视图，并可采用 On-Premises 或 Hybrid Cloud 部署。无论使用哪种模式，网关及其依赖仍由你负责运维。

核心要点

  • AISIX 1.4.0 允许网关在启动时 Redis 限流或缓存后端不可达的情况下绑定监听器并提供服务，但此时是明确的降级行为，不等同于健康的共享后端。
  • 使用量重试有明确上限，并会考虑批次去重信号；但若请求没有收到响应，发送端会沿用最近一次观察到的去重信号。依赖重试前，应完成所有控制面副本的 1.4.0 升级；混合版本副本或回滚期间不能保证幂等写入。
  • 使用凭据连接 etcd 的部署现在默认有 5 秒连接超时；升级前应检查任何正常但更慢的路径，或显式设置 etcd.dial_timeout_ms。
  • 配置错误、已满的遥测队列、耗尽的重试预算和旧控制面仍是重要失败路径。控制面故障时，AISIX Cloud 预算检查也可能拒绝流量。应把本次发布视为需要验证的韧性升级，而不是泛化的可用性承诺。

先启动网关，再识别哪些能力已经降级

设想一个生产部署：网关重启时，它所依赖的 Redis 暂时不可达。1.4.0 之前，Redis 限流或缓存连接可能让网关在启动过程中没有任何已绑定的监听器。1.4.0 中，网关会先绑定并提供服务，同时在后台重试连接共享后端。

1flowchart LR
2  R[启动时 Redis 不可达] --> G[AISIX 网关绑定并提供服务]
3  G --> L[限流：按副本计数]
4  G --> C[Redis 缓存：缓存未命中]
5  G --> B[后台重新连接]
6  B -->|Redis 恢复响应| H[共享后端恢复]

两条降级路径并不能互换：

  • 使用 ratelimit.backend: redis 时，Redis 不可达期间会按副本计数。集群范围的限流在此期间不会生效；AISIX 不会永久切换到 memory 后端。
  • 对 Redis 缓存策略，Redis 不可达期间会按未命中处理。在此状态下，语义策略不会发起嵌入调用或访问 Redis。如果精确匹配所用的 Redis 连接已恢复，但向量搜索探测仍未完成，精确匹配查询可以访问 Redis；语义向量匹配仍需等待探测成功。
  • 如果 Redis 有响应但拒绝凭据或所选数据库，也会进入降级路径，但会标记为 reason=refused；不可达后端则为 reason=unreachable。因此，在 Redis 侧修正凭据后，无需重启网关即可被重新采用。

这并不意味着启动时会放过格式错误的配置。无法解析的 Redis url、无法读取的 TLS 材料、缺少模式必需字段或 timeout_secs: 0，会在网络调用前被本地拒绝，仍会阻止启动。这个区分既保留了配置错误应有的明确信号，也允许可恢复的远端依赖故障不再阻止服务。

限定使用量重试，并明确去重的适用条件

继续服务只是恢复故事的一半。如果网关积累使用量事件后控制面请求失败，AISIX 1.4.0 可以使用相同的批次 ID 重发同一批次。若请求收到了可重试的失败响应，该响应必须声明支持批次去重，网关才会重发。若没有收到响应，发送端则沿用最近一次响应中的去重信号：此前从未收到该信号时会丢弃批次；后续任何不含该信号的响应都会清除已记住的能力状态。

1flowchart LR
2  E[使用量批次] --> S[发送到控制面]
3  S -->|已接受| I[投递成功]
4  S -->|可重试的响应带去重信号| R[使用相同批次 ID 重发]
5  S -->|无响应；此前信号仍有效| R
6  S -->|无信号或不可重试的响应| D[按原因指标丢弃]
7  R -->|兼容控制面接受| I
8  R -->|信号缺失或重试预算耗尽| D

1.4.0 控制面会在写入行记录的同一事务中占用批次 ID，因此再次收到该批次时，可以直接回应而不重复写入。但这不意味着混合版本的控制面副本可以安全地重试：较新副本声明支持去重后，发往旧副本的请求可能在未收到响应时失败；即使旧副本无法去重，网关也可能依据此前的信号重发。发送端记住的信号不能证明究竟是哪个副本处理了失败的请求。混合版本升级或回滚期间，不应依赖使用量写入的幂等性。

重试窗口有明确上限：30 分钟预算从批次中最早事件的发生时间算起；连续出现八次带响应的失败也会耗尽重试预算。最后一次尝试可能在截止时刻开始，并在稍后完成。如果控制面表明某个批次永远无法存储，会返回 422，该批次会立即被丢弃。后续批次会等待正在重发的批次，因此控制面故障期间控制台中的使用量可能延迟数分钟出现。应跟踪 aisix_usage_event_drops_total 及新增的 send_failed 与 retry_budget_exhausted 原因，而不是假设每个事件最终都会被投递。

要使重试不产生重复写入，网关必须运行 1.4.0，且控制面所有副本都支持批次去重。旧副本返回的响应不含去重信号，会停止重试；但此前收到信号后发生无响应故障时，仍存在上述混合版本例外。不能以修改配置代替升级所有副本。

同一版本还区分了控制面暂时无法读取吊销列表与证书不可接受：前者使网关 /dp 路由收到可重试的 503 MTLS_UNAVAILABLE，后者仍为 401。两种情况都不会失效放行。

使用量重发属于遥测投递路径，而不是请求处理前的授权决策；它不能保证控制面故障时所有请求都能通过。对于 AISIX Cloud 预算检查，如果控制面不可达且没有缓存的决策，网关会拒绝请求。网关可在最长沿用时间内使用缓存决策（默认 600 秒）；超过这一时间后，sticky 和 fail-closed 模式会拒绝流量，fail-open 模式则允许流量。这是独立于 1.4.0 使用量投递变化的行为。

在升级前为配置恢复设定边界

AISIX 1.4.0 还避免使用凭据连接 etcd 时无限期阻塞启动。etcd.dial_timeout_ms 现在默认是 5000。单个 etcd 配置提供方的拨号预算为 dial_timeout_ms × max(1, 非空端点数)。启动时会顺序拨号两个这样的提供方——环境前缀和共享价格目录；如果整个集群不可达，两次拨号等待总计可能达到前述预算的两倍。此预算不限制独立的 etcd 请求。

这个默认值影响设置了 etcd.user 的部署；没有凭据时，连接不会执行 I/O。拨号超时后会走既有恢复路径：记录警告、绑定监听器、在存在快照缓存时从该缓存提供服务，并在后台重试。设置 etcd.dial_timeout_ms: 0 可保留以前无限期等待的拨号行为。request_timeout_ms 是独立配置，默认仍不设上限。

这条韧性路径有一个重要前提：必须存在可用于服务的快照。不要把“etcd 超时后可以绑定监听器”理解为“新启动的网关在 etcd 不可达时仍拥有配置”。在将其写入恢复流程前，应使用真实缓存状态和预期故障进行重启测试。

让运维契约可见

一些配套变化强化了同一目标：不要把依赖症状变成不透明的网关故障。

情况AISIX 1.4.0 行为运维检查
stderr 消费者停滞日志事件进入有界队列；队列满时会丢弃并计数新的日志行，而不是阻塞请求工作线程。针对 aisix_log_lines_dropped_total 告警；队列已满意味着日志数据丢失，并非健康日志路径。
Redis 熔断器恢复在 30 秒窗口结束后，由后台探测恢复情况。不要把恢复探测的超时成本归因给下一条业务请求。
未知的配置资源类型该资源与被拒绝资源分开报告。更新把所有 aisix_config_rejected_resources 当成“无法加载”的告警。
新增指标系列1.4.0 增加四组指标系列。在所有网关均升级到 1.4.0 前，不要把它们加入 observability.metrics.labels；旧网关会因未知指标系列在启动时拒绝配置。

这些变化不能替代容量规划或外部依赖监控，但能让降级行为足够清晰，从而便于观测与测试。

执行与部署相匹配的升级演练

上线前，应验证本次发布改变的路径：

  1. 对使用 etcd 凭据的部署，测量每个配置端点的正常连接时间。如果五秒太短，请显式设置 etcd.dial_timeout_ms；只有在有意保留无限期拨号时才使用 0。
  2. 检查 single 模式下的 redis.username 与 redis.password。这些字段现在会生效，并会作为一对覆盖 URL 中的凭据，因此陈旧的显式值可能让原本正常的连接变成被拒绝的降级状态。
  3. 测试启动时 Redis 故障。确认监听器能绑定、限流按副本执行、缓存策略按未命中处理，并且告警可以区分 reason=unreachable 与 reason=refused。
  4. 在依赖使用量重发之前，先完成所有控制面副本的 1.4.0 升级，再升级网关。混合版本升级或回滚期间不要假设写入不会重复。分别测试有失败响应和无响应的故障，并验证延迟写入、批次去重行为和丢弃指标。
  5. 为单独的未知类型指标更新告警，并且只在整个环境都升级到 1.4.0 后再发布新的指标标签配置。对于大型 dpmgr_usage_events 表，应预留 cp-api 一次性的额外索引工作，以及后续的存储和写入维护。
  6. 如果启用了 AISIX Cloud 预算，请测试没有缓存预算决策，以及超过缓存决策最长沿用时间后的控制面故障，并按所配置的故障模式检查结果。不能以使用量重试正常工作作为受预算约束的请求会继续通过的依据。

请将 AISIX 1.4.0 发布说明 与升级流程一同阅读；若跨越多个版本升级，还需阅读中间版本的发布说明。

继续提供服务，但不掩盖取舍

AISIX 1.4.0 的价值在于缩小依赖故障与网关故障之间的差距：短暂的 Redis 丢失不再必须阻止启动，使用凭据连接 etcd 时有了明确的超时边界，兼容的控制面能够接收重发的使用量批次而不重复写入。

这些结果都有条件：共享限流与 Redis 缓存会降级；要避免使用量重发造成重复写入，控制面所有副本都必须兼容；AISIX Cloud 预算检查仍可能拒绝流量；配置错误仍会阻止启动。应把这些条件写进运行手册，再使用你实际运行的依赖和恢复目标进行测试。可先阅读 AISIX 发布说明 和 AISIX 部署文档。

获取方案