Apache APISIX是如何实现高性能与低延迟特性的？

APISIX的性能优势不是靠单点优化堆出来的，是从底层选型到链路细节全栈做了裁剪和针对性设计，核心设计和落地逻辑可以分成几部分：

底层底座选型：从基础层砍掉不必要的性能损耗 #

• 核心运行在OpenResty生态之上，完全复用Nginx沉淀了十几年的epoll/kqueue异步非阻塞事件驱动模型，没有用多线程/多进程 per request 的并发模型，从根源上避免了高并发下的线程上下文切换、内核态用户态切换、锁竞争带来的延迟毛刺。单Worker进程就能稳定承载数万QPS，进程间通过共享内存做高频数据交互，没有跨进程内存拷贝的额外开销。
• 所有业务逻辑跑在LuaJIT运行时上，热路径代码会被JIT即时编译为本地机器码执行，性能接近原生C代码，比解释型脚本语言快一个数量级；同时LuaJIT采用增量GC机制，不会出现长时间STW阻塞请求处理的问题，内存占用也仅为Go/Java类网关的1/10左右。

路由匹配引擎：专门为网关场景做的定向优化 #

• 没有沿用传统网关遍历路由表的线性匹配逻辑，自研了基于Radix Tree（基数树）的路由匹配引擎，路由匹配的时间复杂度稳定在O(k)（k为请求路径长度），和配置的路由总条数完全无关——哪怕集群配置了上万条路由规则，匹配耗时也不会出现明显上涨。
• 匹配链路做了多层前置过滤：优先按Host、请求方法、路由优先级做粗筛，再做路径前缀匹配，把性能开销最高的正则匹配放在链路最后一步。线上90%以上的请求在粗筛、前缀匹配阶段就能命中目标路由，根本走不到正则匹配的高开销环节。
• 配置更新时采用增量构建路由树的逻辑，不需要全量重建整个匹配树，配置发布的毫秒级窗口内不会阻塞正常请求的转发。

数据面运行时：全链路砍掉阻塞点 #

• 数据面完全无状态，服务启动时全量拉取所有配置到本地内存，请求处理全流程不需要访问远端etcd、数据库等控制面组件，不存在外部网络IO带来的延迟；配置更新通过长连接watch机制做增量推送，不需要定时轮询拉取，配置同步延迟稳定在毫秒级，也不会给控制面造成额外压力。
• 请求处理链路严格对齐Nginx的11个处理阶段做插件挂载，每个插件只在需要的阶段执行对应逻辑，没有多余的流程判断。高频操作比如JSON编解码、正则匹配、加解密、请求头处理，全部通过LuaJIT FFI直接调用高度优化的C实现，避免Lua栈和C栈之间频繁数据拷贝的开销。
• 内存层面做了全链路池化复用：请求上下文、table对象、网络缓冲区全部走预分配的内存池，避免频繁申请释放内存带来的碎片和GC压力；静态资源、大响应体走sendfile零拷贝机制，直接从内核缓冲区发送到网卡，不需要拷贝到用户态内存做二次处理。

插件扩展机制：避免无意义的性能开销 #

• 插件执行链路做了热路径动态裁剪：请求命中路由后，会根据当前路由绑定的插件列表，动态生成只包含必要执行逻辑的代码片段，没有绑定的插件逻辑完全不会进入执行链路，不会像很多网关那样，不管路由有没有用到插件，都要遍历所有插件做初始化、条件判断。
• 扩展能力做了分层支持：常规业务插件用Lua开发足够高效，对性能和隔离性要求高的场景支持C、Wasm插件，Wasm插件经过AOT编译后性能接近原生代码，既实现了插件和主进程的故障隔离，又不会带来明显的性能损耗。
• 可观测相关的能力（日志上报、指标采集、链路追踪）全部做了异步化处理：数据先写入本地共享内存缓冲区攒批，再由后台协程异步发送，不会阻塞当前请求的转发流程。

生产落地的配套性能调优方案 #

• 部署时默认按CPU核数绑定Worker进程，每个Worker单线程跑事件循环，避免CPU跨核调度带来的L1/L2缓存失效；默认裁剪掉不必要的Nginx模块，减少核心链路的冗余逻辑。
• 内置连接池能力，和客户端、上游服务之间默认开启keepalive长连接复用，避免每次请求都做TCP握手、TLS握手的开销，连接池大小支持动态调整，适配不同上游的负载情况。
• 内置分层缓存能力，鉴权结果、服务发现地址、高频请求的响应内容都可以按规则缓存到网关本地内存，命中缓存的请求直接在网关层返回，不需要转发到上游服务。

从实际生产压测数据看，在同等硬件配置下，APISIX的单核心QPS可以达到1.8万以上，平均转发延迟在亚毫秒到1毫秒级别，延迟毛刺率远低于基于Go、Java开发的同类型网关产品。

内容的提问来源于stack exchange，提问作者guoqqqi