[请教]：关于Nginx全局限速的解决方案

yunthanatos · 2015-10-30T10:38:13+00:00

http://jinnianshilongnian.iteye.com/blog/2190343 刚看到这个。在 2015年10月29日星期&#x...

[请教]：关于Nginx全局限速的解决方案

yunthanatos

问题：

如何实现Nginx精确的全局出口带宽限顶？

在下目前知道的三种方案:

第一:limit_rate是针对单个连接上的限速 所以通过反馈的方式可以次最优地解决上述问题但无法完美解决而且要考虑到流量分摊的问题

第二:直接修改http/ngx_http_write_filter_module.c的源码在发包前直接从全局shm中申请limit来控制发包大小但是这样修改了ngx核心的代码

第三:挂个body_filter的钩子函数并且在filter中的位置是ngx_http_write_filter_module之前的第一个然后此filter通过控制向下传递的in chain的大小 来间接严格地控制发包的速率上限

综合以上在下觉得第三种方案最理想但是目前我对nginx核心的理解要实现它还需要深入学习

不知道诸位前辈有简洁的方法不？

期待得到您的指点 :)

gwill.buzz

以前做过类似的事情，就是按照设定的阈值流量分流请求，我的思路比较简单后台跑一个脚本计算当前的流量，然后把这个流量值写到 redis 里，请求来了以后 openresty 根据 redis 里的流量值判断触发 rewrite 行为，具体可以看： http://ieqi.net/2012/07/16/%E4%BD%BF%E7%94%A8-openresty-%E5%AE%9E%E7%8E%B0%E6%8C%89%E6%B5%81%E9%87%8F%E9%98%88%E5%80%BC%E8%BF%9B%E8%A1%8C%E8%AF%B7%E6%B1%82%E5%88%86%E6%B5%81/

在 2015年10月30日上午10:38，Yun Thanatos <yunth...@gmail.com>写道：

问题：
如何实现Nginx精确的全局出口带宽限顶？

在下目前知道的三种方案:

第一:limit_rate是针对单个连接上的限速 所以通过反馈的方式可以次最优地解决上述问题但无法完美解决而且要考虑到流量分摊的问题

第二:直接修改http/ngx_http_write_filter_module.c的源码在发包前直接从全局shm中申请limit来控制发包大小但是这样修改了ngx核心的代码

第三:挂个body_filter的钩子函数并且在filter中的位置是ngx_http_write_filter_module之前的第一个然后此filter通过控制向下传递的in chain的大小 来间接严格地控制发包的速率上限

综合以上在下觉得第三种方案最理想但是目前我对nginx核心的理解要实现它还需要深入学习

不知道诸位前辈有简洁的方法不？

期待得到您的指点 :)

--

yunthanatos

多谢您!我仔细地看了这篇文章这种方法很好但不太适用于当前的应用场景

目前我们的应用场景是比较复杂的:

1.一台server是集群中的一个RS 而且server上的网卡不只是ngx在使用还有其它大流量的服务

2.ngx上面有很多业务要实现对具体某个业务的所有worker的全局速度限制

3.重定向的场景是大粒度的任务均衡分摊但是却无法实现所有ngx-worker的全局速度限制

在 2015年10月30日星期五 UTC+8上午11:16:26，G_will写道：

以前做过类似的事情，就是按照设定的阈值流量分流请求，我的思路比较简单后台跑一个脚本计算当前的流量，然后把这个流量值写到 redis 里，请求来了以后 openresty 根据 redis 里的流量值判断触发 rewrite 行为，具体可以看： http://ieqi.net/2012/07/16/%E4%BD%BF%E7%94%A8-openresty-%E5%AE%9E%E7%8E%B0%E6%8C%89%E6%B5%81%E9%87%8F%E9%98%88%E5%80%BC%E8%BF%9B%E8%A1%8C%E8%AF%B7%E6%B1%82%E5%88%86%E6%B5%81/

在 2015年10月30日上午10:38，Yun Thanatos <yunth...@gmail.com>写道：
问题：
如何实现Nginx精确的全局出口带宽限顶？

在下目前知道的三种方案:

第一:limit_rate是针对单个连接上的限速 所以通过反馈的方式可以次最优地解决上述问题但无法完美解决而且要考虑到流量分摊的问题

第二:直接修改http/ngx_http_write_filter_module.c的源码在发包前直接从全局shm中申请limit来控制发包大小但是这样修改了ngx核心的代码

第三:挂个body_filter的钩子函数并且在filter中的位置是ngx_http_write_filter_module之前的第一个然后此filter通过控制向下传递的in chain的大小 来间接严格地控制发包的速率上限

综合以上在下觉得第三种方案最理想但是目前我对nginx核心的理解要实现它还需要深入学习

不知道诸位前辈有简洁的方法不？

期待得到您的指点 :)

--

agentzh

Hello!

2015-10-30 10:38 GMT+08:00 Yun Thanatos:
>     如何实现Nginx精确的全局出口带宽限顶？
>

这里假设你说的全局还是每 nginx server 实例级别的，而不是跨机器的集群级别。

简单说来，实时精确不太可能，因为要考虑新进来的连接需要*立即*“稀释”所有 worker
进程里面的所有现有连接当前的速度限制（这意味着动态修改已经创建的 timer 的过期时间）。

近似地来实现还是可能的。即你可以在 lua_shared_dict 里面维护当前的并发数，然后分摊到各个连接上，作为 $rate_limit
变量的值。可以在 body_filter_by_lua 里面以数据块为单位来修改和调整 $rate_limit 值。通过
lua_shared_dict 动态维护当前的活动下游连接数，可以参考 lua-resty-limit-traffic 库里的
limit.conn 模块的做法：

    https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/conn.md

Regards，
-agentzh

agentzh

Hello!

2015-10-30 11:57 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:
> 近似地来实现还是可能的。即你可以在 lua_shared_dict 里面维护当前的并发数，然后分摊到各个连接上，作为 $rate_limit
> 变量的值。可以在 body_filter_by_lua 里面以数据块为单位来修改和调整 $rate_limit 值。通过
> lua_shared_dict 动态维护当前的活动下游连接数，可以参考 lua-resty-limit-traffic 库里的
> limit.conn 模块的做法：
>

笔误：这里的变量名写错了，应是 $limit_rate，而不是 $rate_limit，不好意思。

Regards,
-agentzh

yunthanatos

多谢您的详细方案！！这是一种四两拨千斤的解决方法！

我详细地看了下http/ngx_http_write_filter_module.c的代码,其limit_rate的关键实现部分摘录如下:

209 if (r->limit_rate) {

210 limit = (off_t) r->limit_rate * (ngx_time() - r->start_sec + 1)

211 - (c->sent - clcf->limit_rate_after);

212

213 if (limit <= 0) {

214 c->write->delayed = 1;

215 ngx_add_timer(c->write,

216 (ngx_msec_t) (- limit * 1000 / r->limit_rate + 1));

217

218 c->buffered |= NGX_HTTP_WRITE_BUFFERED;

219

220 return NGX_AGAIN;

221 }

222

223 if (clcf->sendfile_max_chunk

224 && (off_t) clcf->sendfile_max_chunk < limit)

225 {

226 limit = clcf->sendfile_max_chunk;

227 }

228

229 }

所以,这种方案,当在body_filter中调整r->limit_rate时,必须依靠r->start_sec、c->sent、ngx_time()这三个的变量,而且要不断地反馈调节,这样就可以间接地近似控制c->send_chain函数的size参数值(如下代码中):

233 sent = c->sent;

234

235 ngx_log_debug1(NGX_LOG_DEBUG_HTTP, c->log, 0,

236 "http write filter limit %O", limit);

237

238 chain = c->send_chain(c, r->out, limit);

239

240 ngx_log_debug1(NGX_LOG_DEBUG_HTTP, c->log, 0,

241 "http write filter %p", chain);

242

但是这种方案也是有弊端的:

因为单个连接的 rate = (total_quota / total_request_concurrency)

如果有黑客使用高并发的下载方式,由于其配额分配时占总体比例变大,但是其带宽是有限的,会导致大部分配额被其浪费掉了,如此服务的整体质量就会下降

又或者这是机制与策略的问题?

另外 关于第三种方案 您是怎么看的呢?

在 2015年10月30日星期五 UTC+8上午11:57:39，agentzh写道：

Hello!

2015-10-30 10:38 GMT+08:00 Yun Thanatos:
> 如何实现Nginx精确的全局出口带宽限顶？
>

这里假设你说的全局还是每 nginx server 实例级别的，而不是跨机器的集群级别。

简单说来，实时精确不太可能，因为要考虑新进来的连接需要*立即*“稀释”所有 worker
进程里面的所有现有连接当前的速度限制（这意味着动态修改已经创建的 timer 的过期时间）。

近似地来实现还是可能的。即你可以在 lua_shared_dict 里面维护当前的并发数，然后分摊到各个连接上，作为 $rate_limit
变量的值。可以在 body_filter_by_lua 里面以数据块为单位来修改和调整 $rate_limit 值。通过
lua_shared_dict 动态维护当前的活动下游连接数，可以参考 lua-resty-limit-traffic 库里的
limit.conn 模块的做法：

https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/conn.md

Regards，
-agentzh

agentzh

Hello!

2015-10-30 15:32 GMT+08:00 Yun Thanatos:
> 但是这种方案也是有弊端的:
>
>   因为单个连接的 rate = (total_quota / total_request_concurrency)
>
>   如果有黑客使用高并发的下载方式,由于其配额分配时占总体比例变大,但是其带宽是有限的,会导致大部分配额被其浪费掉了,如此服务的整体质量就会下降
>

这就需要你在 Lua 里面自己实现聪明的分摊策略了。分摊也不一定是均摊。不过我觉得直接限制某个粒度的客户端并发连接数其实更简单更有效一些，当然，看具体的业务要求了。

>   又或者 这是机制与策略的问题?
>

是。

> 另外 关于第三种方案 您是怎么看的呢?
>

你说的第三种方案，说实话，我没看懂如何能实现你要的效果。毕竟 nginx 的输出过滤器是异步的，无论如何都需要 timer 结合
delayed event 来搞下游写的限速，就是 limit_rate 的做法。

Regards,
-agentzh

yunthanatos

是我没有把方案3给描述清楚 :)

方案3是方案2的变体

P2:

直接修改http/ngx_http_write_filter_module.c的源码在发包前直接从全局shm中申请limit来控制发包大小

可以肯定的是方案P2能解决我们的问题但是 P2修改了ngx核心的代码于是我们继续提出P2.1

P2.1:

通过改变ngx_modules.c中filter module的顺序使global_rate_limit_body_filter正好是ngx_http_write_filter_module之前的第一个执行即如下

top_body_filter -> ... -> global_rate_limit_body_filter -> ngx_http_write_filter_module -> NULL

global_rate_limit_body_filter的其它逻辑与P2相同且最后不再调用如下进行返回

return ngx_http_next_body_filter(r, in);

而是它直接return状态码相当于把老的ngx_http_write_filter_module给屏蔽了我们自己实现了个带全局速度限顶的"ngx_http_write_filter_module"

接着对P2.1进一步进行一般化推广,得到P3,也就是方案三

P3:

挂个body_filter的钩子函数并且在filter中的位置如P2.1 但是仍使用如下方式返回

return ngx_http_next_body_filter(r, in);

P3能够很好的解决上述黑客攻击的问题能够进行自适应地限速(因为body_filter链的执行是由写事件触发)

P3的伪代码描述如下:(粗略)

quota data structrue in shm {

quota_max=100000 //时间段总quota

quota=50000 //当前时间段quota剩余

refresh_prets //每隔一段时间

refresh_span //quota=quota_max

spinlock_atomic //quota消费:quota-=delta_sent

}

global_rate_limit_access_phase_handler{

初始化本连接的ctx

ctx->quota=-1024 //可调参数

}

global_rate_limit_body_filter {

如果本连接ctx->quota为负

抢shm中的配额(|ctx->quota|)

如果失败

//delay quota's refresh_span

ngx_add_timer //此处如何实现? <<----难点

return NGX_AGAIN

如果成功

记录当前连接ctx->quota=0

ret=ngx_http_next_body_filter(r, in);

发包完毕之后计算出delta_sent_bytes

抢shm中的配额(delta_sent_bytes)

如果失败

记录当前连接ctx->quota=-delta_sent_bytes

//delay quota's refresh_span

ngx_add_timer

return NGX_AGAIN

如果成功

return NGX_OK

}

在 2015年10月30日星期五 UTC+8下午3:38:00，agentzh写道：

Hello!

2015-10-30 15:32 GMT+08:00 Yun Thanatos:
> 但是这种方案也是有弊端的:
>
> 因为单个连接的 rate = (total_quota / total_request_concurrency)
>
> 如果有黑客使用高并发的下载方式,由于其配额分配时占总体比例变大,但是其带宽是有限的,会导致大部分配额被其浪费掉了,如此服务的整体质量就会下降
>

这就需要你在 Lua 里面自己实现聪明的分摊策略了。分摊也不一定是均摊。不过我觉得直接限制某个粒度的客户端并发连接数其实更简单更有效一些，当然，看具体的业务要求了。

> 又或者这是机制与策略的问题?
>

是。

> 另外关于第三种方案您是怎么看的呢?
>

你说的第三种方案，说实话，我没看懂如何能实现你要的效果。毕竟 nginx 的输出过滤器是异步的，无论如何都需要 timer 结合
delayed event 来搞下游写的限速，就是 limit_rate 的做法。

Regards,
-agentzh

yunthanatos

现在的问题变成了:

位于filter链中间位置的一个body_filter 如何实现延迟一段时间再继续往下走?

写到这儿想到ngx.sleep

ngx.sleep

syntax: ngx.sleep(seconds)

context: rewrite_by_lua, access_by_lua, content_by_lua, ngx.timer.**

但是 ngx.sleep好像不能在body_filter阶段用么 :)

在 2015年10月30日星期五 UTC+8下午3:38:00，agentzh写道：

Hello!

2015-10-30 15:32 GMT+08:00 Yun Thanatos:
> 但是这种方案也是有弊端的:
>
> 因为单个连接的 rate = (total_quota / total_request_concurrency)
>
> 如果有黑客使用高并发的下载方式,由于其配额分配时占总体比例变大,但是其带宽是有限的,会导致大部分配额被其浪费掉了,如此服务的整体质量就会下降
>

这就需要你在 Lua 里面自己实现聪明的分摊策略了。分摊也不一定是均摊。不过我觉得直接限制某个粒度的客户端并发连接数其实更简单更有效一些，当然，看具体的业务要求了。

> 又或者这是机制与策略的问题?
>

是。

> 另外关于第三种方案您是怎么看的呢?
>

你说的第三种方案，说实话，我没看懂如何能实现你要的效果。毕竟 nginx 的输出过滤器是异步的，无论如何都需要 timer 结合
delayed event 来搞下游写的限速，就是 limit_rate 的做法。

Regards,
-agentzh

doujiang24

hello，

在 2015年10月30日下午4:51，Yun Thanatos <yunth...@gmail.com>写道：

现在的问题变成了:
位于filter链中间位置的一个body_filter 如何实现延迟一段时间再继续往下走?

写到这儿想到ngx.sleep

ngx.sleep
syntax: ngx.sleep(seconds)
context: rewrite_by_lua, access_by_lua, content_by_lua, ngx.timer.**

但是 ngx.sleep好像不能在body_filter阶段用么 :)

确实，目前 ngx.sleep 还不能在 body_filter_by_lua 中使用

你说的做法是：在 body_filter 中，对每一个 chunk 都根据 shdict 中的值计算一次？

至于计算部分，似乎类似 limit-req 里的这个算法也可以 [1]

但是，也就意味着每一个 chunk 都需要两次 shdict 操作（get, set)，似乎这个频次会有点高，当然还是具体测试比较好说明问题

或许，应当如春哥所说，可以根据业务逻辑来实现聪明的分摊策略，似乎这样也能满足业务需求？ :)

1> https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/req.lua#L93

在 2015年10月30日星期五 UTC+8下午3:38:00，agentzh写道：
Hello!

2015-10-30 15:32 GMT+08:00 Yun Thanatos:
> 但是这种方案也是有弊端的:
>
> 因为单个连接的 rate = (total_quota / total_request_concurrency)
>
> 如果有黑客使用高并发的下载方式,由于其配额分配时占总体比例变大,但是其带宽是有限的,会导致大部分配额被其浪费掉了,如此服务的整体质量就会下降
>

这就需要你在 Lua 里面自己实现聪明的分摊策略了。分摊也不一定是均摊。不过我觉得直接限制某个粒度的客户端并发连接数其实更简单更有效一些，当然，看具体的业务要求了。

> 又或者这是机制与策略的问题?
>

是。

> 另外关于第三种方案您是怎么看的呢?
>

你说的第三种方案，说实话，我没看懂如何能实现你要的效果。毕竟 nginx 的输出过滤器是异步的，无论如何都需要 timer 结合
delayed event 来搞下游写的限速，就是 limit_rate 的做法。

Regards,
-agentzh

--

ssdrliu

如果是跨机器集群级别的全局限速，推荐的做法会是怎样？

在 2015年10月30日星期五 UTC+8上午11:57:39，agentzh写道：

Hello!

2015-10-30 10:38 GMT+08:00 Yun Thanatos:
> 如何实现Nginx精确的全局出口带宽限顶？
>

这里假设你说的全局还是每 nginx server 实例级别的，而不是跨机器的集群级别。

简单说来，实时精确不太可能，因为要考虑新进来的连接需要*立即*“稀释”所有 worker
进程里面的所有现有连接当前的速度限制（这意味着动态修改已经创建的 timer 的过期时间）。

近似地来实现还是可能的。即你可以在 lua_shared_dict 里面维护当前的并发数，然后分摊到各个连接上，作为 $rate_limit
变量的值。可以在 body_filter_by_lua 里面以数据块为单位来修改和调整 $rate_limit 值。通过
lua_shared_dict 动态维护当前的活动下游连接数，可以参考 lua-resty-limit-traffic 库里的
limit.conn 模块的做法：

https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/conn.md

Regards，
-agentzh

agentzh

Hello!

2015-10-30 16:51 GMT+08:00 Yun Thanatos:
> 现在的问题变成了:
>     位于filter链中间位置的一个body_filter 如何实现延迟一段时间 再继续往下走?
>
> 写到这儿 想到ngx.sleep
>
>   ngx.sleep
>   syntax: ngx.sleep(seconds)
>   context: rewrite_by_lua, access_by_lua, content_by_lua, ngx.timer.**
>
> 但是 ngx.sleep好像不能在body_filter阶段用么  :)
>

nginx 的输出过滤器并不支持从中间 yield，只能像 limit_rate 机制的实现那样先缓存输出，屏蔽下游写事件，再建 timer
自己进行事件调度。由于其异步的本质，无法高效地实现 ngx.sleep() 这样的同步操作，而需要使用异步的语义，像 limit_rate
那样只是配置一下当前限额，并没有自己进行同步等待。

Regards,
-agentzh

agentzh

Hello!

2015-11-02 11:40 GMT+08:00 牧童:
> 如果是跨机器集群级别的全局限速，推荐的做法会是怎样？
>

这种实时性要求很高的跨机器的状态共享，不可避免地会引入很大的开销，所以不推荐使用。

Regards,
-agentzh

yunthanatos

感谢doujiang的建议！

经过思考最终决定使用body_filter反馈调节limit_rate的方法！这个方案的关键难点:是如何优化并发连接与用户带宽不均衡的问题

春哥所说的:"直接限制某个粒度的客户端并发连接数" 不失为一个简单直接的解决方案！

另外在下决定尝试:对总配额进行不断地一定放大比例的反馈调整看看效果如何！

>确实，目前 ngx.sleep 还不能在 body_filter_by_lua 中使用

>你说的做法是：在 body_filter 中，对每一个 chunk 都根据 shdict 中的值计算一次？

>至于计算部分，似乎类似 limit-req 里的这个算法也可以 [1]
>但是，也就意味着每一个 chunk 都需要两次 shdict 操作（get, set)，似乎这个频次会有点高，当然还是具体测试比较好说明问题

考虑到效率的问题是以ngx-c-addon的方式来实现的 ngx的shm与spinlock效率应会高一些 : )

>或许，应当如春哥所说，可以根据业务逻辑来实现聪明的分摊策略，似乎这样也能满足业务需求？ :)

1> https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/req.lua#L93

仔细看了下这三个模块的实现很简洁的lua : )

yunthanatos

原来如此！受教了！感谢春哥的解惑 ;)

在 2015年11月2日星期一 UTC+8下午12:01:09，agentzh写道：

Hello!

2015-10-30 16:51 GMT+08:00 Yun Thanatos:
> 现在的问题变成了:
> 位于filter链中间位置的一个body_filter 如何实现延迟一段时间再继续往下走?
>
> 写到这儿想到ngx.sleep
>
> ngx.sleep
> syntax: ngx.sleep(seconds)
> context: rewrite_by_lua, access_by_lua, content_by_lua, ngx.timer.**
>
> 但是 ngx.sleep好像不能在body_filter阶段用么 :)
>

nginx 的输出过滤器并不支持从中间 yield，只能像 limit_rate 机制的实现那样先缓存输出，屏蔽下游写事件，再建 timer
自己进行事件调度。由于其异步的本质，无法高效地实现 ngx.sleep() 这样的同步操作，而需要使用异步的语义，像 limit_rate
那样只是配置一下当前限额，并没有自己进行同步等待。

Regards,
-agentzh

agentzh

Hello!

2015-11-02 19:33 GMT+08:00 Yun Thanatos:
>   考虑到效率的问题 是以ngx-c-addon的方式来实现的 ngx的shm与spinlock效率应会高一些 : )

德江先前说的就是 C 级别上的损耗（spinlock, sema_wait 之类）。这一般也不会成为问题。Lua 那一层是极薄的，如果使用
lua-resty-core，Lua 层的损耗可以忽略不计。

Regards,
-agentzh

yunthanatos

这是一个例子，可供牧童参考下:

当时有两个方案:

1.使用paxos的强一致性存储 进行节点总体的配额的发布与版本更新

2.弱一致性使用无限增长的epoch作为配额的版本号 RS之间选举master slave与master之间反馈epoch(这些都是ngx-lua实现的) 自适应

组里最终选的是方案2 因为它简单而且容易部署

如果是计费的话全局实时限速 这个实时只要比运营商的流量计算时的delta_t小 就好了！他们的delta_t好像是一分钟左右(不同运营商计费时是不同的)

在 2015年11月2日星期一 UTC+8上午11:40:26，牧童写道：

如果是跨机器集群级别的全局限速，推荐的做法会是怎样？

在 2015年10月30日星期五 UTC+8上午11:57:39，agentzh写道：
Hello!

2015-10-30 10:38 GMT+08:00 Yun Thanatos:
> 如何实现Nginx精确的全局出口带宽限顶？
>

这里假设你说的全局还是每 nginx server 实例级别的，而不是跨机器的集群级别。

简单说来，实时精确不太可能，因为要考虑新进来的连接需要*立即*“稀释”所有 worker
进程里面的所有现有连接当前的速度限制（这意味着动态修改已经创建的 timer 的过期时间）。

近似地来实现还是可能的。即你可以在 lua_shared_dict 里面维护当前的并发数，然后分摊到各个连接上，作为 $rate_limit
变量的值。可以在 body_filter_by_lua 里面以数据块为单位来修改和调整 $rate_limit 值。通过
lua_shared_dict 动态维护当前的活动下游连接数，可以参考 lua-resty-limit-traffic 库里的
limit.conn 模块的做法：

https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/conn.md

Regards，
-agentzh

yunthanatos

大概看了下lua-resty-core 之前还没有发现有这么个好东西呢 : )

原来德江是这个意思当然如果临界区足够短小 这些开销应是很小的

是的！现在项目的做法就是: c插件来实现新的机制 lua重点做策略的事情 这样既架构清晰又开发迅速而且lua写起来也很舒服

在 2015年11月2日星期一 UTC+8下午7:49:41，agentzh写道：

Hello!

2015-11-02 19:33 GMT+08:00 Yun Thanatos:
> 考虑到效率的问题是以ngx-c-addon的方式来实现的 ngx的shm与spinlock效率应会高一些 : )

德江先前说的就是 C 级别上的损耗（spinlock, sema_wait 之类）。这一般也不会成为问题。Lua 那一层是极薄的，如果使用
lua-resty-core，Lua 层的损耗可以忽略不计。

Regards,
-agentzh