Comment nginx utilise ctx pour réaliser le partage de données

Environnement : 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

Cette table Lua peut être utilisée pour stocker des données d'environnement Lua basées sur des requêtes, et sa durée de vie est la même que celle de la requête actuelle (similaire aux variables Nginx).

Référez-vous à l'exemple ci-dessous,

localisation/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)

}

}

Accédez à la sortie GET /test

79

Autrement dit, les entrées ngx.ctx.foo sont cohérentes tout au long des étapes de réécriture, d'accès et de traitement du contenu d'une requête.

Chaque requête, y compris les sous-requêtes, possède sa propre table ngx.ctx. Par exemple :

emplacement /sous {

Content_by_lua_block {

        ngx.say("sub pré: ", ngx.ctx.blah)

       ngx.ctx.blah = 32

        ngx.say("sous-post : ", ngx.ctx.blah)

}

}

emplacement / principal {

Content_by_lua_block {

       ngx.ctx.blah = 73

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

Res locale = ngx.location.capture("/sub")

       ngx.print(res.body)

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

}

}

Accédez à GET /sortie principale

pré-principal : 73

sous pré : nul

sous-post : 32

message principal : 73

Ici, la modification de l'entrée ngx.ctx.blah dans la requête enfant n'affecte pas l'entrée du même nom dans la requête parent, car elles maintiennent chacune une version différente de ngx.ctx.blah.

La redirection interne détruira les données ngx.ctx (le cas échéant) dans la requête d'origine et la nouvelle requête aura une table ngx.ctx vide. Par exemple,

emplacement /nouveau {

Content_by_lua_block {

       ngx.say(ngx.ctx.foo)

}

}

emplacement /origine {

Content_by_lua_block {

      ngx.ctx.foo = "bonjour"

      ngx.exec("/new")

}

}

L'accès à GET /orig affichera

nul

au lieu de la valeur originale "bonjour".

Des valeurs de données arbitraires, y compris des fermetures Lua et des tables imbriquées, peuvent être insérées dans cette table « magique », qui permet également d'enregistrer des métaméthodes personnalisées.

Il est également possible d'écraser ngx.ctx en tant que nouvelle table Lua, par exemple

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

Lorsqu'elle est utilisée dans un environnement init_worker_by_lua*, cette table est identique à la durée de vie actuelle du handle Lua.

Les requêtes de table ngx.ctx nécessitent des appels de méta-méthode relativement coûteux, qui sont beaucoup plus lents que la transmission de données basées sur des requêtes directement via les propres paramètres de fonction de l'utilisateur. N'abusez donc pas de cette API uniquement pour enregistrer les paramètres des fonctions utilisateur, car cela peut avoir un impact significatif sur les performances.

Et à cause de la méta-méthode "magique", n'essayez pas d'utiliser le niveau "local" ngx.ctx au niveau du module lua, par exemple le partage de données au niveau du travailleur. L'exemple suivant est terrible :

-- monmodule.lua

local _M = {}

-- Le ngx.ctx dans la ligne suivante appartient à une seule requête, mais la variable ctx est au niveau du module Lua

-- et appartient à un seul travailleur.

ctx local = ngx.ctx

fonction _M.main()

ctx.foo = "bar"

fin

retour _M

Ce qui suit doit être utilisé à la place :

-- monmodule.lua

local _M = {}

fonction _M.main(ctx)

ctx.foo = "bar"

fin

retour _M

C'est-à-dire que l'appel de l'appelant à la table ctx doit être complété en passant des paramètres de fonction.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!