OpenResty 高并发访问 Redis：控制连接数，降低 P99 延迟

流量高峰期，经常会出现这样的尴尬局面：业务平时在大流量下运行得非常丝滑，Redis 实例的 CPU 和内存也明明还有不少余量，但在整点促销或突发洪峰的关键时刻，网关到 Redis 的连接数却突然暴增几十上百倍，瞬间打满配额甚至引发全链路“雪崩”；或者后端的订单服务还能处理更多请求，用户却因为网关侧的会话查询变慢，迟迟刷不出页面。对于依赖 Redis 做身份鉴权、高频限流和实时状态校验的业务来说，这两类瓶颈会直接转化为系统稳定性风险、云资源成本和用户体验问题。

技术团队往往需要权衡：能否在不盲目升配 Redis 实例的前提下，彻底消除突发流量下的“连接风暴”，同时让更多用户在高峰期顺畅地完成操作？ 要解决这个矛盾，既要看客户端在流量洪峰下如何控制连接规模，也要看高并发下查询的吞吐量与尾延迟（P99）。

为此，OpenResty 提供了两个高性能 Redis 私有库，分别针对单实例和集群部署：

平时运行丝滑、关键时刻却“雪崩”？斩断连接暴增与配额焦虑

先看最容易在关键时刻“掉链子”的连接数问题。

不少团队都踩过这样的坑：业务日常访问量已经很大，网关与 Redis 配合得十分顺畅；可一旦遇到秒杀、突发流量，或者网络出现轻微抖动，整个服务就会在短短几秒内迅速瘫痪。

这背后的根源，在于传统客户端采用了“单请求独占连接、用完归还连接池”的模式。平时请求快去快回，几十个长连接不断轮转复用就能扛住很高的 QPS；但在关键时刻，一旦并发流量突然放大，或者某次响应稍有延迟，在途请求没来得及把连接还回池中，后续涌入的请求就会瞬间触发高达几十上百倍的“新建连接风暴”，进而引发连锁雪崩：

1. 本地端口耗尽，连不上服务端：瞬时爆发的海量新建连接，会迅速耗尽网关机器的本地可用端口（Ephemeral Ports），导致后续请求直接报错、无法连接 Redis。
2. 服务端忙于建连，整体响应变慢：Redis 服务端瞬间涌入大量新建连接请求，处理连接接入的开销剧增，直接拖慢了正常读写命令的响应速度。
3. 失去长连接复用，单次请求变慢：相比直接复用已有的长连接，新建连接必须经历完整的 TCP 握手与鉴权流程，完成单次 Redis 请求的耗时大幅增加。
4. 超时重试叠加，最终导致雪崩：由于不能及时回复客户端请求，上游或用户端等待超时后提前断开，并立即发起新的重试请求；重试流量进一步推高并发与新建连接数，形成恶性循环，最终导致业务彻底雪崩。

除了引发单点雪崩，这种不可控的连接数激增在多业务共用 Redis 的架构中还会带来严峻的配额与成本焦虑。为了防范网关在高峰期突然吸干连接数、波及同实例的核心交易服务，团队要么在跨部门协调连接配额时捉襟见肘，要么只能赶在大促前加钱升配 Redis 实例——哪怕此时 Redis 的算力和内存根本没用完，仅仅是被峰值连接数卡住了脖子。

在鉴权、限流、会话校验等常规读写场景中，使用 lua-resty-redis-fast 可以从根源上斩断这一雪崩链条——其占用的连接数不会随业务并发量的增加而增长。 只要网关自身的部署规模（机器数与 Worker 数）不变，哪怕突发在线请求翻倍，连接数也保持稳定，不会触发海量新建连接。

这意味着，面对突发洪峰，网关既不会因为疯狂新建连接而耗尽本地端口、拖垮 Redis 响应，也不会在关键时刻打爆连接配额。如果现有 Redis 实例的 CPU 和内存仍有余量，换用单实例私有库后，团队便有望在现有的连接配额内稳稳承接峰值流量，省下单纯为了“买连接数上限”而升配实例的预算。（注：这里需区分“业务并发增长”与“网关扩容”——若后续增加了网关节点或 Worker 数量，总连接数需求仍需按新规模重新计算。）

此外，lua-resty-redis-fast 沿用了开源 lua-resty-redis 的常用 Lua 接口，方便存量业务平滑评估与迁移；具体支持范围参见单实例版接入文档。

前置查询变慢，用户等的是页面和操作结果

控制住连接数规模，解决的是关键时刻“不因建连风暴而雪崩”和“不超配额”的问题；而在日常高峰期，每一次查询“能不能瞬间完成”，则直接决定了用户的等待时间。这一点对单实例和集群部署同样关键。

以网关层的登录态或令牌（Token）校验为例。当用户打开订单页或提交操作时，网关必须先从 Redis 读取会话或配额状态，校验通过后才能将请求转发给后端服务。哪怕后端的订单服务很空闲，只要网关这一步卡住了，请求就只能干等。

用户感知不到内部的链路细节，他们看到的只是页面一直在转圈、点击提交迟迟没有响应。如果前置的 Redis 查询耗时过长，挤占了整条链路的超时预算，请求就会直接超时失败，迫使用户不断刷新重试。因此，优化网关侧的 Redis 查询，重点不仅在于让单个接口跑出好看的分数，更在于保障核心业务流程的完成率。

在这里，高吞吐和**低尾延迟（P99）**直接对应着两个实际的业务收益：

• 吞吐量提上去，解决的是“进得来”：当网关查库成为瓶颈而后端服务仍有余量时，每秒处理更多查询，就能消除入口处的拥堵，让高峰期更多有效请求顺畅地流向后端业务。
• P99 延迟降下来，解决的是“不超时”：压缩慢查询的耗时，能为后续的订单处理等核心逻辑留出更充裕的时间窗口，减少因前置校验过慢而拖垮整个请求的风险，让用户少一些漫长等待与重复尝试。

两组 GET 测试：吞吐大幅提升，P99 均压至 1 毫秒内

当会话或状态数据以键值（Key-Value）形式存储时，网关最核心的操作就是高频 GET。下面通过并发 GET 基准测试来观察两个私有库的读取表现（完整的请求耗时还包含网络与后续业务逻辑，需结合实际链路评估）。

我们将两个私有库分别与对应的开源客户端进行同台对比，下表列出了各组测试结果的中位值：

单实例版：GET 吞吐达到开源客户端的 3.47 倍，P99 延迟降低过半。（对比基线为开源 lua-resty-redis v0.34）

集群版：GET 吞吐达到开源客户端的 7.14 倍，P99 延迟从 6.8ms 降至 1ms 以内。（对比基线为开源 lua-resty-redis-cluster，保持相同的 Lua 并发数）

两组数据表明，私有库在大幅拉升 GET 吞吐量的同时，显著削平了长尾延迟。这正好呼应了前文的两个业务目标：为高峰流量拓宽入口通道，为后端业务处理留出充足时间。

测试说明：以上数据基于纯 GET 基准测试，旨在反映客户端自身的性能差异，未直接测量连接数节省比例。实际业务中的最终收益，还会受具体 Redis 命令、网络环境、读取策略以及网关外其他链路瓶颈的影响。

使用集群版时，还可根据业务对数据一致性的要求选择读取策略，具体配置见集群版接入文档。

如果你的团队正因为连接数配额见底而考虑升配 Redis，或者希望改善高峰期因前置查询变慢导致的请求等待与超时，欢迎联系我们申请试用，在真实业务流量下评估它们能为您节省多少资源成本、提升多少响应体验。

了解更多：同一条请求链路上的其他开销

Redis 查询只是网关处理请求的一环。当 Redis 查询已经足够快，但整体接口响应或服务器负载仍不理想时，不妨排查一下时间和 CPU 是否消耗在了同一链路的其他环节上。在 OpenResty 私有库总览中，还有几个常与 Redis 配合优化的方向：

• 会话数据或接口报文需要高频解析 JSON：从 Redis 取出 JSON 格式的会话或配置数据后，网关通常需要立即解码。如果火焰图显示 JSON 编解码占用了大量 CPU，可以延伸阅读 jit.cjson：当 JSON 成为 OpenResty 服务的隐形瓶颈，通过加速解析为网关实例腾出更多处理业务流量的算力。
• 网关需同时向 Kafka 异步上报日志或业务事件：如果网关在转发请求的同时还要承担风控事件、访问日志的采集上报，就必须防止上报抖动拖慢主链路。lua-resty-kafka-fast 针对 OpenResty 写入 Kafka 的场景进行了深度优化，可在保障高吞吐数据采集的同时，严格控制对用户请求响应的影响。
• 突发流量已逼近网关自身的 CPU 极限：当内部查询与解析都已优化到位，但外部洪峰流量依然超出当前机器的承载上限时，可以关注 lua-resty-limit-traffic-dynamic。它支持根据 CPU 利用率目标动态调整 HTTP 限流阈值，在流量洪峰下保护系统水位，确保已放行的请求能够顺利完成。

这些私有库分别针对序列化处理、消息上报与动态流控，团队可结合自身的性能瓶颈按需选配。完整的组件列表与接入指南可查阅私有库文档。

关于作者

章亦春是开源 OpenResty^® 项目创始人兼 OpenResty Inc. 公司 CEO 和创始人。

章亦春（GitHub ID: agentzh），生于中国江苏，现定居美国湾区。他是中国早期开源技术和文化的倡导者和领军人物，曾供职于多家国际知名的高科技企业，如 Cloudflare、雅虎、阿里巴巴，是“边缘计算”、“动态追踪”和“机器编程”的先驱，拥有二十余年的编程及深厚的开源经验。作为拥有超过 4000 万全球域名用户的开源项目的领导者，他基于其 OpenResty^® 开源项目打造的高科技企业 OpenResty Inc. 位于美国硅谷中心。其主打的两个产品 OpenResty XRay（利用动态追踪技术的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最适合微服务和分布式流量的全能型网关软件），广受全球众多上市及大型企业青睐。在 OpenResty 以外，章亦春为多个开源项目贡献了累计超过百万行代码，其中包括 Linux 内核、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，并编写过 60 多个开源软件库。

关注我们

如果您喜欢本文，欢迎关注我们 OpenResty Inc. 公司的博客网站。也欢迎扫码关注我们的微信公众号：