Wie Nginx CTX verwendet, um den Datenaustausch zu erreichen

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

Diese Lua-Tabelle kann zum Speichern anforderungsbasierter Lua-Umgebungsdaten verwendet werden und ihre Lebensdauer entspricht der der aktuellen Anforderung (ähnlich wie bei Nginx-Variablen).

Siehe das Beispiel unten,

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

}

}

Zugriff auf GET/Test-Ausgabe

79

Das heißt, ngx.ctx.foo-Einträge sind in den Phasen des Umschreibens, Zugriffs und der Inhaltsverarbeitung einer Anfrage konsistent.

Jede Anfrage, einschließlich Unteranfragen, verfügt über eine eigene ngx.ctx-Tabelle. Zum Beispiel:

Standort /sub {

Content_by_lua_block {

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

        ngx.ctx.blah = 32

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

}

}

Standort/Haupt {

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("Hauptbeitrag: ", ngx.ctx.blah)

}

}

Zugriff auf GET /Hauptausgabe

Hauptvorlauf: 73

sub pre: nil

Unterbeitrag: 32

Hauptbeitrag: 73

Hier hat die Änderung des ngx.ctx.blah-Eintrags in der untergeordneten Anfrage keine Auswirkungen auf den gleichnamigen Eintrag in der übergeordneten Anfrage, da jeder eine andere Version von ngx.ctx.blah verwaltet.

Durch die interne Umleitung werden die ngx.ctx-Daten (falls vorhanden) in der ursprünglichen Anfrage zerstört und die neue Anfrage wird eine leere ngx.ctx-Tabelle haben. Zum Beispiel

Standort /neu {

Content_by_lua_block {

        ngx.say(ngx.ctx.foo)

}

}

Standort /orig {

Content_by_lua_block {

      ngx.ctx.foo = "Hallo"

      ngx.exec("/new")

}

}

Beim Zugriff auf GET /orig wird

ausgegeben Null

anstelle des ursprünglichen „Hallo“-Werts.

In diese „magische“ Tabelle können beliebige Datenwerte, einschließlich Lua-Verschlüsse und verschachtelte Tabellen, eingefügt werden, was auch die Registrierung benutzerdefinierter Metamethoden ermöglicht.

Es ist auch möglich, ngx.ctx als neue Lua-Tabelle zu überschreiben, zum Beispiel

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

Bei Verwendung in einer init_worker_by_lua*-Umgebung ist diese Tabelle identisch mit der aktuellen Lua-Handle-Lebensdauer.

ngx.ctx-Tabellenabfragen erfordern relativ teure Metamethodenaufrufe, die viel langsamer sind als die direkte Weitergabe anforderungsbasierter Daten über die eigenen Funktionsparameter des Benutzers. Missbrauchen Sie diese API also nicht nur zum Speichern von Benutzerfunktionsparametern, da dies erhebliche Auswirkungen auf die Leistung haben kann.

Und wegen der Metamethode „Magie“ sollten Sie nicht versuchen, ngx.ctx auf „lokaler“ Ebene auf der Ebene des Lua-Moduls zu verwenden, beispielsweise für die Datenfreigabe auf Worker-Ebene. Das folgende Beispiel ist schrecklich:

-- mymodule.lua

local _M = {}

-- Die ngx.ctx in der folgenden Zeile gehört zu einer einzelnen Anfrage, aber die ctx-Variable befindet sich auf Lua-Modulebene

– und gehört einem einzelnen Arbeiter.

lokaler ctx = ngx.ctx

Funktion _M.main()

ctx.foo = "bar"

Ende

return _M

Stattdessen sollte Folgendes verwendet werden:

-- mymodule.lua

local _M = {}

Funktion _M.main(ctx)

ctx.foo = "bar"

Ende

return _M

Das heißt, der Aufruf des Aufrufers an die ctx-Tabelle sollte durch die Übergabe von Funktionsparametern abgeschlossen werden.

Das obige ist der detaillierte Inhalt vonWie Nginx CTX verwendet, um den Datenaustausch zu erreichen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!