如果Master进程不允许则只会在init_by_lua之后调用; 通常用于定时拉取配置/数据,或者后端服务的健康检查 指令: set_by_lua/set_by_lua_file 处理阶段: rewrite 使用范围: server,server if,location,location if 解释: 设置nginx变量,可以实现复杂的赋值逻辑;此处是阻塞的,Lua代码要做到非常快; 指令: rewrite_by...
所以如果你不想在init_by_lua中重复初始化共享数据, 那么你需要在你的共享内存中设置一个标志位并在init_by_lua中进行检查。 因为这个阶段的lua代码是在nginx forks出任何worker进程之前运行, 数据和代码的加载将享受由操作系统提供的copy-on-write的特性,从而节约了大量的内存。 不要在这个阶段初始化你的私有lua...
(1)、init_by_lua* init_by_lua*是 OpenResty 目前唯一运行在 master 进程里的阶段。它运行的时机非常靠前,就在 Nginx 刚解析完配置之后。 这就意味着,只要运行 Nginx 可执行文件,init_by_lua*里面的代码就会被调用。有些时候,我们运行 Nginx 可执行文件,并不是想启动它的服务。比如在调用nginx -t检查配置...
其中, init_by_lua 只会在 Master 进程被创建时执行,init_worker_by_lua 只会在每个 Worker 进程被创建时执行。其他的 *_by_lua 指令则是由终端请求触发,会被反复执行。 所以在 init_by_lua 阶段,我们可以预先加载 Lua 模块和公共的只读数据,这样可以利用操作系统的 COW(copy on write)特性,来节省一些内存。
OpenResty 也有 11 个 *_by_lua指令,它们和 NGINX 阶段的关系如下图所示(图片来 自 lua-nginx-module 文档): 其中, init_by_lua 只会在 Master 进程被创建时执行,init_worker_by_lua 只会在每个 Worker 进程被创建时执行。其他的 *_by_lua 指令则是由终端请求触发,会被反复执行。
如果Lua脚本的缓存是关闭的,那么每一次请求都运行一次init_by_lua处理程序。通过lua_code_cache指令可以关闭Lua脚本缓存,缓存默认是开启的。 注意:在生产场景下都会开启Lua脚本缓存,在init_by_lua调用require所加载的模块文件会缓存在全局的Lua注册表package.loaded中,所以在这里定义的全局变量和函数可能会污染命名空间,...
在init_by_lua等阶段 openresty是在主协程中通过lua_pcall直接执行lua代码 而在access_by_lua content_by_lua等阶段中,openresty创建一个新的协程,通过lua_resume执行lua代码 二者的区别在于能否执行ngx.slepp. ngx.thread ngx.socket 这些有让出操作的函数 ...
init_by_lua*:初始化 nginx 和预加载 lua(nginx 启动和 reload 时执行); init_worker_by_lua*:每个工作进程(worker_processes)被创建时执行,用于启动一些定时任务, 比如心跳检查,后端服务的健康检查,定时拉取服务器配置等; ssl_certificate_by_lua*:对 https 请求的处理,即将启动下游 SSL(https)连接的 SSL 握...
lua_code_cache off的情况下,跟请求有关的阶段,在每次有请求来的时候,都会重新加载最新的lua文件,这样我们修改完代码之后就不用通过reload来更新代码了 而*_by_lua_block、*_by_lua和init_by_lua_file里的代码(init_by_lua阶段和具体请求无关),如果修改的内容涉及这几个,仍需要通过reload来更新代码 ...
在init_by_lua等阶段 openresty是在主协程中通过lua_pcall直接执行lua代码 而在access_by_lua content_by_lua等阶段中,openresty创建一个新的协程,通过lua_resume执行lua代码 二者的区别在于能否执行ngx.slepp. ngx.thread ngx.socket 这些有让出操作的函数 ...