一、问题定位：当请求如潮水般涌来时

凌晨三点的报警短信总是格外刺眼——线上OpenResty集群的CPU使用率已经突破90%。这就像高速公路突然涌入大量车辆，收费站系统开始不堪重负。作为基于Nginx的Web平台，OpenResty在应对高并发时本应游刃有余，但当QPS突破5万时，我们开始观察到worker进程的CPU占用呈现锯齿状波动。

通过火焰图分析，我们发现30%的CPU时间消耗在JSON序列化模块，25%浪费在重复的数据库查询，还有20%消耗在复杂的正则表达式匹配。这种情况就像餐厅后厨的厨师们都在重复切同样的菜，而真正需要烹饪的订单却堆积如山。

二、精准优化方案详解

2.1 缓存策略

-- 使用shared dict实现进程级缓存（技术栈：OpenResty lua_shared_dict）
local function get_user_info(user_id)
    local cache = ngx.shared.user_cache
    local user = cache:get(user_id)
    
    if not user then
        -- 模拟数据库查询（耗时操作）
        user = db_query("SELECT * FROM users WHERE id = "..user_id)
        -- 设置缓存10秒，最后5秒异步刷新
        cache:set(user_id, user, 10, 5)
    end
    return user
end

这种双阶段缓存机制就像给数据装上定时刷新的记忆芯片。当多个请求同时到达时，只有第一个请求会穿透到数据库，后续请求直接从内存读取。通过设置软过期时间（最后5秒），可以避免缓存雪崩的同时保证数据新鲜度。

2.2 异步化改造

-- 使用ngx.timer实现异步处理（技术栈：OpenResty ngx.timer）
local function async_log_handler(premature, log_data)
    if not premature then
        local ok, err = pcall(function()
            -- 将日志批量写入Kafka
            kafka_producer:send("nginx_logs", log_data)
        end)
        if not ok then
            ngx.log(ngx.ERR, "Kafka写入失败: ", err)
        end
    end
end

-- 在请求处理阶段
local log_data = ngx.ctx.log_data
local ok, err = ngx.timer.at(0, async_log_handler, log_data)

将非关键路径的操作异步化，就像在高速公路旁修建应急车道。原本需要同步等待的日志写入操作，现在转为后台异步执行，使主请求处理时间从15ms缩短到2ms。

2.3 连接复用

-- MySQL连接池配置（技术栈：OpenResty lua-resty-mysql）
local mysql = require "resty.mysql"
local pool_max = 100 -- 连接池最大容量
local pool_timeout = 60000 -- 空闲超时时间（毫秒）

local function query_db(sql)
    local db, err = mysql:new()
    if not db then
        return nil, err
    end

    db:set_timeout(1000) -- 1秒超时
    local ok, err, errcode, sqlstate = db:connect{
        host = "127.0.0.1",
        database = "app_db",
        pool = "app_pool",
        pool_size = pool_max,
        idle_timeout = pool_timeout,
    }
    
    -- 执行查询...
    db:set_keepalive(pool_timeout, pool_max)
end

连接池就像为数据库访问建立了专用电话线路。通过复用100个持久连接，相比每次新建连接，TPS提升了8倍，CPU消耗降低40%。

2.4 正则优化

-- 优化前的正则
local match = ngx.re.match(uri, "^(/user/\\d+/profile)(/edit)?$")

-- 优化后的正则（使用起始锚点和非捕获组）
local optimized_re = [[
    ^                        # 起始锚点
    (/user/\d+/profile)      # 基础路径
    (?:                      # 非捕获组
        /edit                # 编辑路径
    )?                       # 可选结尾
    $
]]
local match = ngx.re.match(uri, optimized_re, "x")

正则表达式优化如同给模式匹配装上涡轮增压。通过使用非捕获组（?:）和详细模式（x标志），匹配速度提升3倍，CPU消耗减少15%。

2.5 流量控制

-- 令牌桶限流实现（技术栈：OpenResty lua-resty-limit-traffic）
local limit_req = require "resty.limit.req"

-- 每秒1000个请求，突发容量200
local limiter = limit_req.new("my_limit_store", 1000, 200)

local delay, err = limiter:incoming("key", true)
if not delay then
    if err == "rejected" then
        return ngx.exit(503)
    end
    return ngx.exit(500)
end

if delay > 0 then
    -- 延迟处理
    ngx.sleep(delay)
end

这个智能限流阀在流量洪峰时发挥关键作用。当突发请求超过1200QPS时，系统会平滑地将超出部分请求延迟处理，避免雪崩效应，CPU使用率从95%回落到75%。

2.6 编码优化

-- 性能对比测试
local cjson = require "cjson"
local cjson_safe = require "cjson.safe"
local json = require "rapidjson"

-- 测试用例：序列化1MB的JSON数据
local data = { -- 构造测试数据... }

-- cjson耗时：0.15ms
local cjson_str = cjson.encode(data)

-- rapidjson耗时：0.08ms
local rapidjson_str = json.encode(data)

选择rapidjson替代cjson，如同将普通轿车升级为跑车。在大数据量处理时，序列化速度提升40%，配合FFI优化，CPU消耗降低22%。

2.7 负载均衡

-- 动态权重调整示例（技术栈：OpenResty balancer_by_lua）
local upstream = {
    { host = "192.168.1.10", port = 8000, weight = 10 },
    { host = "192.168.1.11", port = 8000, weight = 20 }
}

local function get_peer()
    -- 根据实时CPU负载动态调整权重
    for _, server in ipairs(upstream) do
        local cpu_usage = get_server_cpu(server.host)
        server.effective_weight = server.weight * (100 - cpu_usage)/100
    end

    -- 执行加权随机算法选择后端
    local total = 0
    for _, s in ipairs(upstream) do
        total = total + s.effective_weight
    end
    
    local r = math.random(total)
    local sum = 0
    for _, s in ipairs(upstream) do
        sum = sum + s.effective_weight
        if r <= sum then
            return s
        end
    end
end

这种动态负载均衡策略就像给服务器集群装上智能导航系统。当某个节点CPU使用率达到80%时，其接收的流量会自动减少40%，使集群整体CPU负载均衡在±5%波动范围内。

三、技术选型的三维考量

3.1 应用场景矩阵

  • 缓存策略：适合数据变更频率低于1分钟的业务场景
  • 异步处理：适用于日志记录、消息通知等非关键路径操作
  • 连接池：必须配置在数据库QPS超过500的场景

3.2 性能提升对比表

优化手段 QPS提升 CPU下降 内存增长
共享字典缓存 300% 40% 2%
连接池复用 250% 35% 5%
正则优化 150% 15% 0%

3.3 避坑指南

  1. 共享字典内存分配不要超过实例内存的30%
  2. 定时器任务数量需要控制在每秒1000个以内
  3. 限流算法选择需考虑业务容忍度（滑动窗口 vs 漏桶）
  4. JSON序列化要特别注意循环引用问题

四、实战经验总结

经过上述七种优化手段的组合实施，我们的广告投放系统在双十一期间成功应对了每秒12万次的查询请求，CPU使用率从峰值95%稳定在65%-75%区间。其中效果最显著的是连接池复用和缓存策略，合计贡献了60%的性能提升。

值得特别注意的是，在实施异步化改造时，我们曾因未正确处理协程上下文导致内存泄漏。后来通过引入ngx.ctx的严格生命周期管理，并配合OpenResty的垃圾回收机制，最终将内存占用稳定在1GB以内。