OpenResty Lua脚本调用RabbitMQ性能优化求助

问题根源分析 #

当前代码在Redis查询miss时，每次请求都会新建RabbitMQ STOMP连接，TCP三次握手、STOMP协议握手的额外开销直接导致响应时间飙升至15ms，且连接创建的不确定性带来了极大的响应时间标准差。

具体优化措施 #

1. 复用RabbitMQ STOMP连接池

避免每次请求都新建连接，利用OpenResty的连接池机制复用已有连接：

• 指定连接池名称，增大连接池容量，延长空闲连接超时时间；
• 后续请求调用connect时，客户端会自动从连接池获取空闲连接，无需重新执行握手流程。

修改示例：

-- 初始化MQ客户端时配置连接池
local opts = { 
    username = "guest",
    password = "guest",
    vhost = "/",
    pool = "rabbitmq_stomp_pool", -- 统一连接池名称
    pool_size = 500, -- 连接池容量，根据并发量调整
    idle_timeout = 30000 -- 空闲连接超时30秒
}

local mq, err = rabbitmq:new(opts)
-- 连接时自动复用池内空闲连接
local ok, err = mq:connect("127.0.0.1",61613) 

2. 异步发送RabbitMQ消息

将发送MQ的逻辑放到后台定时器执行，不阻塞请求响应流程，直接把响应时间拉回Redis查询的水平：

• 使用ngx.timer.at(0, function() ... end)将MQ发送逻辑异步执行；
• 提前捕获需要的参数（比如ip），避免闭包变量引用问题。

修改示例：

if res == ngx.null then
    ngx.say("") -- 直接返回空响应，不等待MQ发送完成
    local target_ip = ngx.var.arg_ip -- 提前捕获ip参数
    -- 异步执行MQ发送逻辑
    local ok, err = ngx.timer.at(0, function(premature)
        if premature then return end
        local rabbitmq = require "resty.rabbitmqstomp"
        local opts = { 
            username = "guest",
            password = "guest",
            vhost = "/",
            pool = "rabbitmq_stomp_pool",
            pool_size = 500,
            idle_timeout = 30000
        }
        local mq, err = rabbitmq:new(opts)
        if not mq then return end
        local ok, err = mq:connect("127.0.0.1",61613)
        if not ok then return end
        local headers = {}
        headers["destination"] = "/exchange/ip-data"
        headers["persistent"] = "true"
        headers["content-type"] = "text/plain"
        mq:send(target_ip, headers)
        mq:set_keepalive(30000, 500)
    end)
    return
end

3. 替换为AMQP原生客户端

STOMP是通用消息协议，性能不如RabbitMQ原生的AMQP协议，建议替换为lua-resty-rabbitmq这类AMQP客户端：

• AMQP协议更高效，连接复用和消息发送的开销更低；
• 大部分AMQP客户端原生支持连接池和异步操作，进一步降低延迟波动。

4. 调整Redis连接池配置

当前Redis连接池大小为100，针对每秒数千请求的场景，建议调至500-1000，避免Redis连接成为瓶颈：

-- 修改Redis的keepalive参数
local ok, err = red:set_keepalive(30000, 1000) -- 空闲超时30秒，连接池大小1000

优化后预期效果 #

• 响应时间回到8-10ms以内（Redis查询1-2ms + 异步MQ发送不阻塞请求）；
• 响应时间标准差大幅降低，连接复用消除了新建连接的不确定性；
• 接口吞吐量满足每秒数千请求的业务需求。

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