一、为什么高并发场景下请求会阻塞
当我们在使用OpenResty处理高并发请求时，经常会遇到请求阻塞的问题。这就像是在高峰期的高速公路收费站，如果收费员处理速度跟不上，车辆就会排起长队。在技术层面，这种阻塞通常发生在以下几个环节：
- 数据库查询耗时过长
- 外部API调用响应慢
- 复杂的业务逻辑处理
- 共享资源的锁竞争
举个典型的例子，我们来看一个简单的商品查询接口：
location /api/product {
content_by_lua_block {
local id = ngx.var.arg_id
local db = require "resty.mysql"
local mysql, err = db:new()
-- 连接数据库
local ok, err, errcode, sqlstate = mysql:connect{
host = "127.0.0.1",
port = 3306,
database = "shop",
user = "root",
password = "password",
max_packet_size = 1024 * 1024
}
-- 查询商品信息
local res, err, errcode, sqlstate = mysql:query("SELECT * FROM products WHERE id = " .. id)
-- 释放连接
mysql:close()
ngx.say(cjson.encode(res))
}
}
这个看似简单的实现在高并发场景下会出现严重问题。每个请求都会创建新的数据库连接，当并发量上来时，数据库连接池很快就会被耗尽，后续请求只能排队等待。
二、OpenResty的并发处理机制
OpenResty基于Nginx的事件驱动模型，采用非阻塞I/O处理请求。这种架构天生适合高并发场景，但前提是我们要正确使用它。关键在于理解以下几个核心概念：
- 非阻塞I/O：所有I/O操作都应该以非阻塞方式进行
- 协程调度：OpenResty通过Lua协程实现轻量级线程切换
- 连接池：重用昂贵的资源连接
- 异步处理：将耗时操作交给后台处理
让我们改造上面的商品查询接口，加入连接池和查询缓存：
location /api/product {
content_by_lua_block {
local id = ngx.var.arg_id
local redis = require "resty.redis"
local red = redis:new()
-- 先尝试从Redis获取缓存
local ok, err = red:connect("127.0.0.1", 6379)
if not ok then
ngx.log(ngx.ERR, "failed to connect to redis: ", err)
return ngx.exit(500)
end
local cache_key = "product:" .. id
local product, err = red:get(cache_key)
-- 缓存命中
if product and product ~= ngx.null then
red:set_keepalive(10000, 100) -- 归还连接到连接池
return ngx.say(product)
end
-- 缓存未命中，查询数据库
local db = require "resty.mysql"
local mysql, err = db:new()
local ok, err = mysql:connect{
host = "127.0.0.1",
port = 3306,
database = "shop",
user = "root",
password = "password",
pool = "product_pool", -- 使用连接池
pool_size = 100 -- 连接池大小
}
local res, err, errcode, sqlstate = mysql:query("SELECT * FROM products WHERE id = " .. id)
mysql:set_keepalive(10000, 100) -- 归还连接到连接池
-- 将结果存入Redis，设置5分钟过期
red:setex(cache_key, 300, cjson.encode(res))
red:set_keepalive(10000, 100)
ngx.say(cjson.encode(res))
}
}
这个改进版本使用了连接池和Redis缓存，大大减少了数据库的直接访问压力。
三、高级优化技巧
除了基本的连接池和缓存，我们还可以采用更高级的优化策略：
- 请求合并：将多个相似的请求合并处理
- 异步日志：避免同步写日志造成的阻塞
- 限流保护：防止系统被突发流量冲垮
- 预热机制：提前加载热点数据
来看一个请求合并的示例：
-- 定义共享内存存储待处理的请求
lua_shared_dict batch_requests 10m;
location /api/batch_product {
content_by_lua_block {
local id = ngx.var.arg_id
local batch = require "resty.batch"
-- 创建批处理对象
local batch_processor = batch.new()
-- 添加第一个查询
batch_processor:add("/api/product?id=1001")
-- 添加第二个查询
batch_processor:add("/api/product?id=1002")
-- 执行批处理
local results = batch_processor:execute()
-- 返回合并后的结果
ngx.say(cjson.encode(results))
}
}
这个批处理接口可以显著减少网络往返次数，特别适合移动端场景。
四、实战中的注意事项
在实际项目中应用这些优化技巧时，有几个关键点需要注意：
- 连接池大小设置：不是越大越好，需要根据实际负载测试
- 缓存一致性：处理好缓存与数据库的数据同步问题
- 超时设置：所有外部调用都必须设置合理的超时
- 错误处理：优雅地处理各种异常情况
来看一个带有完善错误处理的示例：
location /api/safe_product {
content_by_lua_block {
local id = ngx.var.arg_id
local redis = require "resty.redis"
local red = redis:new()
-- 设置超时时间
red:set_timeout(1000) -- 1秒超时
-- 尝试连接Redis
local ok, err = pcall(function()
return red:connect("127.0.0.1", 6379)
end)
if not ok then
ngx.log(ngx.ERR, "Redis connection failed: ", err)
-- 降级处理，直接查询数据库
return query_database(id)
end
-- 尝试获取缓存
local product, err = red:get("product:" .. id)
if product and product ~= ngx.null then
red:set_keepalive(10000, 100)
return ngx.say(product)
end
-- 缓存未命中，查询数据库
local db_result = query_database(id)
-- 异步更新缓存，不阻塞当前请求
ngx.timer.at(0, function()
local red_async = redis:new()
red_async:set_timeout(1000)
local ok, err = red_async:connect("127.0.0.1", 6379)
if ok then
red_async:setex("product:" .. id, 300, db_result)
red_async:set_keepalive(10000, 100)
end
end)
ngx.say(db_result)
}
}
-- 数据库查询函数
local function query_database(id)
local db = require "resty.mysql"
local mysql, err = db:new()
mysql:set_timeout(2000) -- 2秒超时
local ok, err = mysql:connect{
host = "127.0.0.1",
port = 3306,
database = "shop",
user = "root",
password = "password",
pool = "product_pool",
pool_size = 100
}
if not ok then
ngx.log(ngx.ERR, "MySQL connection failed: ", err)
return ngx.exit(500)
end
local res, err, errcode, sqlstate = mysql:query("SELECT * FROM products WHERE id = " .. id)
mysql:set_keepalive(10000, 100)
if not res then
ngx.log(ngx.ERR, "MySQL query failed: ", err)
return ngx.exit(500)
end
return cjson.encode(res)
end
这个示例展示了完整的错误处理流程和降级策略，确保系统在部分组件故障时仍能提供基本服务。
五、性能优化效果评估
实施上述优化后，我们需要评估实际效果。通常可以从以下几个维度衡量：
- 吞吐量：单位时间内处理的请求数
- 响应时间：请求从发起到收到响应的时间
- 错误率：失败请求占总请求的比例
- 资源利用率：CPU、内存、网络等资源的使用情况
我们可以使用OpenResty自带的ngx.location.capture进行基准测试：
location /benchmark {
content_by_lua_block {
local start = ngx.now()
local total_requests = 1000
local success = 0
for i = 1, total_requests do
local res = ngx.location.capture("/api/product?id=" .. math.random(1, 100))
if res.status == 200 then
success = success + 1
end
end
local elapsed = ngx.now() - start
local qps = total_requests / elapsed
ngx.say(string.format("Total requests: %d\nSuccess: %d\nElapsed: %.3f seconds\nQPS: %.2f",
total_requests, success, elapsed, qps))
}
}
通过对比优化前后的测试结果，可以直观地看到性能提升效果。
六、总结与最佳实践
经过以上分析和实践，我们可以总结出OpenResty在高并发场景下的性能优化最佳实践：
- 始终使用连接池管理数据库和Redis连接
- 合理设置各级缓存，减少IO操作
- 所有外部调用都要设置超时
- 采用异步处理耗时操作
- 实现完善的错误处理和降级策略
- 定期进行性能测试和调优
记住，性能优化是一个持续的过程，需要根据实际业务场景和负载特点不断调整。OpenResty提供了强大的工具集，关键在于我们如何正确使用它们。
评论