Openrestry默认性能优化，解决高并发难题

一、OpenResty为什么能成为高并发利器

说到处理高并发请求，很多工程师第一时间会想到Nginx。但你可能不知道，基于Nginx的OpenResty更是个隐藏的"性能怪兽"。它把Nginx和Lua脚本引擎完美结合，让我们可以用Lua语言轻松扩展Nginx的功能。

想象一下，你正在运营一个电商平台，大促时每秒要处理上万订单。传统架构可能在数据库连接这一步就崩溃了，但OpenResty可以直接在网关层完成缓存读取、请求合并、流量控制等操作，把后端保护得妥妥的。这就像在超市收银台前安排了十个预检员，真正到收银台时效率自然就高了。

二、必须掌握的默认性能优化配置

先来看个真实的配置案例（技术栈：OpenResty + Lua）：

# main上下文配置
worker_processes  auto;  # 自动匹配CPU核心数
worker_rlimit_nofile 65535;  # 每个worker能打开的最大文件数

events {
    worker_connections  4096;  # 单个worker最大连接数
    use epoll;  # Linux环境下使用epoll事件模型
    multi_accept on;  # 一次性接受所有新连接
}

http {
    lua_package_path '/usr/local/openresty/lualib/?.lua;;';  # Lua模块搜索路径
    lua_code_cache on;  # 必须开启代码缓存！
    
    # 共享字典定义（内存缓存）
    lua_shared_dict my_cache 100m;  # 100MB大小的共享内存区域
    
    # 关键性能参数
    sendfile on;  # 启用零拷贝传输
    tcp_nopush on;  # 仅在sendfile开启时有效，优化数据包发送
    keepalive_timeout 65;  # 长连接超时时间
    client_max_body_size 50m;  # 最大请求体大小
    
    include /usr/local/openresty/nginx/conf/conf.d/*.conf;
}

这个配置里有几个黄金参数值得特别关注：

1. lua_code_cache on 是性能关键，关闭调试时一定要记得重新打开
2. lua_shared_dict 定义的共享内存区域，是Lua worker间通信的高速通道
3. sendfile 和 tcp_nopush 的组合让静态文件传输飞起来

三、Lua脚本实战优化技巧

让我们用具体场景说话。假设要开发一个秒杀接口（技术栈：OpenResty + Redis）：

-- 限流脚本：使用令牌桶算法
local limit_req = require "resty.limit.req"
-- 每秒100个请求，突发不超过200个
local limiter = limit_req.new("my_limit_store", 100, 200)

-- 商品详情页缓存脚本
local function get_product_info(product_id)
    local cache = ngx.shared.my_cache
    local cache_key = "product_"..product_id
    
    -- 先查本地缓存
    local product = cache:get(cache_key)
    if product then
        return product
    end
    
    -- 缓存未命中，查询Redis
    local redis = require "resty.redis"
    local red = redis:new()
    red:set_timeout(1000)  -- 1秒超时
    
    local ok, err = red:connect("127.0.0.1", 6379)
    if not ok then
        ngx.log(ngx.ERR, "Redis连接失败: ", err)
        return nil
    end
    
    product = red:hmget("products", product_id)
    -- 写入本地缓存，过期时间5秒
    cache:set(cache_key, product, 5)
    
    return product
end

-- 秒杀核心逻辑
local function seckill(sku_id, user_id)
    -- 限流检查
    local delay, err = limiter:incoming(ngx.var.remote_addr, true)
    if not delay then
        if err == "rejected" then
            return ngx.exit(503)
        end
        ngx.log(ngx.ERR, "限流错误: ", err)
        return ngx.exit(500)
    end
    
    -- 库存检查（Redis原子操作）
    local redis = require "resty.redis"
    local red = redis:new()
    local stock_key = "stock_"..sku_id
    
    -- 使用Redis的DECR保证原子性
    local remaining = red:decr(stock_key)
    if remaining < 0 then
        red:incr(stock_key)  -- 恢复库存
        return {code=400, msg="库存不足"}
    end
    
    -- 生成订单（模拟操作）
    local order_id = generate_order()
    return {code=200, data=order_id}
end

这个示例展示了三个关键优化点：

1. 多级缓存策略（本地内存 → Redis → 数据库）
2. 原子性的库存扣减
3. 请求限流保护

四、避坑指南与高级技巧

在实际项目中，我踩过不少坑，这里分享几个典型案例：

内存泄漏陷阱：

-- 错误示例：每次请求都创建新table
local function leak_memory()
    local big_table = {}  -- 这个table不会被释放
    for i=1,10000 do
        big_table[i] = "data"..i
    end
    -- 没有清理操作
end

-- 正确做法：使用对象池
local table_pool = require "tablepool"
local function safe_operation()
    local tbl = table_pool.fetch()
    -- 使用tbl...
    table_pool.recycle(tbl)  -- 用完后归还
end

热代码加载技巧：

# 开发时自动重载Lua代码（生产环境禁用！）
curl http://127.0.0.1/reload_lua?code=user_controller.lua

对应的Nginx配置：

location /reload_lua {
    content_by_lua_block {
        if ngx.var.arg_code then
            package.loaded[ngx.var.arg_code] = nil
            ngx.say("已重载: "..ngx.var.arg_code)
        end
    }
}

五、性能对比与监控方案

想知道优化效果如何？来看组实测数据：

监控推荐使用OpenResty自带的ngx.status模块：

location /metrics {
    default_type text/plain;
    content_by_lua_block {
        local metric = require "resty.metric"
        metric.export()
    }
}

六、完整实战：API网关设计

最后来个完整示例（技术栈：OpenResty + Redis + MySQL）：

# api_gateway.conf
server {
    listen 80;
    
    location ~ ^/api/(\w+) {
        access_by_lua_file /usr/local/openresty/lua/api_router.lua;
        content_by_lua_file /usr/local/openresty/lua/api_dispatcher.lua;
        log_by_lua_file /usr/local/openresty/lua/api_logger.lua;
    }
}

对应的路由脚本：

-- api_router.lua
local router = {
    user = {
        auth = true,
        handler = "user_controller"
    },
    product = {
        auth = false,
        rate_limit = "100r/s",
        handler = "product_controller"
    }
}

local path = ngx.var[1]
local endpoint = ngx.var[2]

-- 路由匹配逻辑
local route = router[path][endpoint]
if not route then
    ngx.exit(404)
end

-- 将路由信息存入ngx.ctx
ngx.ctx.route = route

七、技术选型的思考

为什么选择OpenResty而不是其他方案？看这个对比表：

OpenResty最适合：

• 需要极高并发的API网关
• 流量密集型应用的前置层
• 对响应时间敏感的服务

八、总结与最佳实践

经过多年实战，我总结出这些黄金法则：

1. 始终开启lua_code_cache
2. 共享字典大小要预留30%余量
3. 每个worker的lua_shared_dict要独立配置
4. 使用ngx.timer处理耗时操作
5. 定期检查Lua虚拟机内存使用

记住，OpenResty不是银弹。它最适合作为系统的"前哨站"，把复杂的业务逻辑后移到更适合的运行时环境。当你的QPS突破5万大关时，你会感谢今天做的这个技术选型。