How nginx uses ctx to achieve data sharing

Environment: init_worker_by_lua, set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua, ngx.timer., balancer_by_lua

This Lua table can be used to store request-based Lua environment data, and its lifetime is the same as the current request (similar to Nginx variables).

Refer to the following example,

location /test {

rewrite_by_lua_block {

ngx.ctx.foo = 76

}

access_by_lua_block {

        ngx.ctx.foo = ngx.ctx.foo 3

}

content_by_lua_block {

        ngx.say(ngx.ctx.foo)

}

}

Access GET /test output

79

That is, ngx.ctx.foo entries are consistent across the rewrite, access, and content processing stages of a request.

Each request, including subrequests, has its own ngx.ctx table. For example:

location /sub {

content_by_lua_block {

      ngx.say("sub pre: ", ngx.ctx.blah)

        ngx.ctx.blah = 32

      ngx.say("sub post: ", ngx.ctx.blah)

}

}

location /main {

content_by_lua_block {

        ngx.ctx.blah = 73

      ngx.say("main pre: ", ngx.ctx.blah)

Local res = ngx.location.capture("/sub")

ngx.print(res.body)

      ngx.say("main post: ", ngx.ctx.blah)

}

}

Access GET /main output

main pre: 73

sub pre: nil

sub post: 32

main post: 73

Here, modifying the ngx.ctx.blah entry in the child request does not affect the entry with the same name in the parent request, since they each maintain a different version of ngx.ctx.blah.

The internal redirect will destroy the ngx.ctx data (if any) in the original request, and the new request will have an empty ngx.ctx table. For example,

location /new {

content_by_lua_block {

        ngx.say(ngx.ctx.foo)

}

}

location /orig {

content_by_lua_block {

        ngx.ctx.foo = "hello"

      ngx.exec("/new")

}

}

Accessing GET /orig will output

nil

instead of the original "hello" value.

Arbitrary data values, including Lua closures and nested tables, can be inserted into this "magic" table, which also allows custom metamethods to be registered.

It is also possible to overwrite ngx.ctx with a new Lua table, for example,

ngx.ctx = { foo = 32, bar = 54 }

When used in an init_worker_by_lua* environment, this table is identical to the current Lua handle lifetime.

ngx.ctx table queries require relatively expensive meta-method calls, which are much slower than passing request-based data directly through the user's own function parameters. So don't abuse this API just to save user function parameters, as it may have a significant impact on performance.

And because of the metamethod "magic", don't try to use "local" level ngx.ctx at the lua module level, for example worker-level data sharing. The following example is bad:

-- mymodule.lua

local _M = {}

-- The ngx.ctx in the following line belongs to a single request, but the ctx variable is at the Lua module level

-- and belongs to a single worker.

local ctx = ngx.ctx

function _M.main()

ctx.foo = "bar"

end

return _M

The following should be used instead:

-- mymodule.lua

local _M = {}

function _M.main(ctx)

ctx.foo = "bar"

end

return _M

That is to say, the caller's call to the ctx table should be completed by passing function parameters.

The above is the detailed content of How nginx uses ctx to achieve data sharing. For more information, please follow other related articles on the PHP Chinese website!