openresty

关于 OpenResty 的两三事

基础原理

Nginx 采用的是 master-worker 模型,一个 master 进程管理多个 worker 进程,基本的事件处理都是放在 woker 中,master 负责一些全局初始化,以及对 worker 的管理。

每个 woker 使用一个 LuaVM,当请求被分配到 woker 时,将在这个 LuaVM 里创建一个 coroutine。协程之间数据隔离,每个协程具有独立的全局变量 _G

关于 lua_code_cache

关闭 lua_code_cache 时,require 的处理方式是每次都强制重新加载和解析,也就是说,你对代码的任何修改的效果,都将在上传后立即体现。

开启 lua_code_cache 时,在同一个 LuaVM 中,模块将在首次加载并解析后被缓存,之后再次 require 将直接返回缓存的内容。换句话说,同一 worker 上的所有请求将共享已加载的模块,任意一个请求对于模块属性的修改,都将影响到同一 worker 上的其他请求。

不应使用模块级的局部变量以及模块属性,存放任何请求级的数据。否则在 lua_code_cache 开启时,会造成请求间相互影响和数据竞争,产生不可预知的异常状况。

关闭 lua_code_cache 会极大的降低性能,在生产环境中应开启 lua_code_cache

虽然开发环境中关闭 lua_code_cache 会有一些便利性,但我强烈建议开启 lua_code_cache ,与线上保持一致,以减少不必要的差异性问题和额外测试需求。

开启 lua_code_cache 时,可用 nginx -s reload kill -HUP masterPID 方式热重载代码,无需重启 Nginx。

关于 path 和 cpath

OpenResty 会将它的 lib 目录加入 package.pathpackage.cpath,但你的项目目录需要自己处理。

在入口文件中,将项目目录加入 package.path package.cpath 是不可取的。因为 lua_code_cache 开启时,package 模块是同一 worker 上所有请求共享的,如果无条件追加,package.path package.cpath 将不断变长,并最终导致内存溢出。

以下是我采用的解决方案:

关于 lua-resty-mysql 和 lua-resty-redis

不应使用模块级的局部变量以及模块属性,存放 resty.mysqlresty.redis 实例。否则,在 lua_code_cache 开启时,同一 worker 的所有请求将共享该实例,造成数据竞争问题。建议将 resty.mysqlresty.redis 实例存放到 ngx.ctx 中。

不能在 require 过程中实例化 resty.mysqlresty.redis 实例,否则会报错。例如,模块返回一个 function,此 function 直接或间接调用实例化 resty.mysqlresty.redis 的代码,将会导致报错。

在首次查询时实例化是一个比较好的解决方案:

使用 set_keepalive(max_idle_timeout, pool_size) 替代 close() 将启用连接池特性。set_keepalive 的意思可以理解为,保持连接,并将连接归还到连接池内。这样在下次连接时,会首先会尝试从连接池获取连接,获取不成功才会创建新的连接。在高并发下,连接池能大大的减少连接 MySQL 和 Redis 的次数,明显的提升性能。

使用模块缓存静态数据

利用 lua_code_cache 开启时模块会被缓存的特性,我们可以使用模块来缓存静态数据,其效率接近于将数据缓存在内存中。

存储方法:

读取方法:

清理方法:

数据存储

_G

请求级 table 变量,生命周期为本次请求,可存储请求级任意 Lua 数据。

ngx.ctx

请求级 table 变量,生命周期为本次请求,可存储请求级任意 Lua 数据。

ngx.shared.DICT

全局级 key-value 字典,使用共享内存实现,实现了读写锁,所有请求均可安全读写。
value 只能为布尔值、数字和字符串。Reload Nginx 时不会受影响,只有当 Nginx 被关闭时才会丢失。

模块属性和模块级局部变量

worker 级变量,同一 worker 的所有请求共享,没有读写锁,多个请求同时写入时不安全。


转自;http://zivn.me/?p=157

你可能感兴趣的:(lua,openresty)