Shulou(Shulou.com)06/01 Report--

This article mainly introduces nginx how to use ctx to achieve data sharing related knowledge, the content is detailed and easy to understand, the operation is simple and fast, has a certain reference value, I believe that everyone after reading this nginx how to use ctx to achieve data sharing article will have a harvest, let's take a look.

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 with the same lifetime as the current request (similar to the Nginx variable).

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

seventy-nine

That is, the ngx.ctx.foo entry is consistent across the rewrite (rewrite), access (access), and content (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, because they each maintain different versions of ngx.ctx.blah.

The internal redirection will destroy the ngx.ctx data (if any) in the original request, and the new request will have a blank 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")

}

}

Access to GET / orig will output

Nil

Instead of the original "hello" value.

Any data value, including Lua closures and nested tables, can be inserted into this "magic" table and custom meta-methods can be registered.

You can also overwrite ngx.ctx as a new Lua table, such as

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

When used in an init_worker_by_lua* environment, this table is the same as the current Lua handle life cycle.

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

And because meta-methods are "magic", don't try to use ngx.ctx at the "local" level at the lua module level, such as 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 methods should be used instead:

-- mymodule.lua

Local _ M = {}

Function _ M.main (ctx)

Ctx.foo = "bar"

End

Return _ M

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

This is the end of the article on "how nginx uses ctx to achieve data sharing". Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "how nginx uses ctx to achieve data sharing". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.