lua-resty-worker-events
ua-resty-worker-events
$ opm get fffonion/lua-resty-worker-eventslua-resty-worker-events
Nginx 工作进程之间的进程间事件
状态
该库已准备好投入生产。
概要
http {
lua_package_path "/path/to/lua-resty-worker-events/lib/?.lua;;";
# the size depends on the number of event to handle:
lua_shared_dict process_events 1m;
init_worker_by_lua_block {
local ev = require "resty.worker.events"
local handler = function(data, event, source, pid)
print("received event; source=",source,
", event=",event,
", data=", tostring(data),
", from process ",pid)
end
ev.register(handler)
local ok, err = ev.configure {
shm = "process_events", -- defined by "lua_shared_dict"
timeout = 2, -- life time of unique event data in shm
interval = 1, -- poll interval (seconds)
wait_interval = 0.010, -- wait before retry fetching event data
wait_max = 0.5, -- max wait time before discarding event
shm_retries = 999, -- retries for shm fragmentation (no memory)
}
if not ok then
ngx.log(ngx.ERR, "failed to start event system: ", err)
return
end
}
server {
...
# example for polling:
location = /some/path {
default_type text/plain;
content_by_lua_block {
-- manually call `poll` to stay up to date, can be used instead,
-- or together with the timer interval. Polling is efficient,
-- so if staying up-to-date is important, this is preferred.
require("resty.worker.events").poll()
-- do regular stuff here
}
}
}
}描述
该模块提供了一种向 Nginx 服务器中的其他工作进程发送事件的方法。通信通过共享内存区域进行，事件数据将存储在其中。
所有工作进程中事件的顺序**保证**相同。
工作进程将在后台设置一个计时器来检查事件。该模块遵循单例模式，因此每个工作进程只运行一次。但是，如果需要保持最新状态，则可以将间隔设置为较低的频率，并对每个收到的请求调用 poll，以确保尽快处理所有事件。
该设计允许 3 种用例；
向所有工作进程广播事件，请参见 post。在这种情况下，所有工作进程中事件的顺序保证相同。例如：在一个工作进程中运行的健康检查，但通知所有工作进程上游节点出现故障。
仅向本地工作进程广播事件，请参见 post_local。
将外部事件合并到一个动作中。例如：所有工作进程都监视指示需要刷新内存缓存的外部事件。收到事件后，它们都会使用唯一的事件哈希值（所有工作进程生成相同的哈希值）将其发布，请参见 post 的
unique参数。现在，只有 1 个工作进程会 _只_ 接收该事件一次，因此只有 1 个工作进程会命中上游数据库以刷新内存数据。
该模块本身将使用 source="resty-worker-events" 触发两个事件；
event="started"，当模块首次配置时（注意：事件处理程序必须在调用 configure 之前注册，才能捕获该事件）event="stopping"，当工作进程退出时（基于计时器premature设置）
请参见 event_list，了解如何在没有硬编码魔术值/字符串的情况下使用事件。
故障排除
为了正确地调整 shm 大小，了解其使用方法非常重要。事件数据存储在 shm 中，以便将其传递给其他工作进程。因此，shm 中有 2 种类型的条目
仅由单个工作进程执行的事件（请参见
post方法的unique参数）。这些条目在 shm 中获得ttl，因此将过期。所有其他事件（本地事件除外，本地事件不使用 SHM）。在这些情况下，没有设置
ttl。
上述结果是 SHM 将始终处于满载状态！因此，这不是要调查的指标。
如何防止问题
SHM 大小必须至少是预期最大有效载荷的倍数。它必须能够容纳在一个
interval（请参见configure）内可能发送的所有事件。no memory错误 _不能_ 通过增大 SHM 来解决。解决这些错误的唯一方法是增加传递给configure的shm_retries选项。这是因为错误是由于碎片化而不是内存不足造成的。如果事件数据在所有工作进程处理它之前被逐出，则会出现
waiting for event data timed out错误。如果出现大量（大负载）事件，则可能会发生这种情况。为了解决这些问题
lua-resty-worker-events =======================
Nginx 工作进程之间的进程间事件
目录 =================
* [名称](#name) * [状态](#status) * [概要](#synopsis) * [描述](#description) * [故障排除](#troubleshooting) * [方法](#methods) * [configure](#configure) * [configured](#configured) * [event_list](#event_list) * [poll](#poll) * [post](#post) * [post_local](#post_local) * [register](#register) * [register_weak](#register_weak) * [unregister](#unregister) * [安装](#installation) * [待办事项](#todo) * [错误和补丁](#bugs-and-patches) * [作者](#author) * [版权和许可](#copyright-and-license) * [历史](#history) * [另请参见](#see-also)
状态 ======
该库已准备好投入生产。
概要 ========
```nginx http { lua_package_path "/path/to/lua-resty-worker-events/lib/?.lua;;";
# the size depends on the number of event to handle:
lua_shared_dict process_events 1m;
init_worker_by_lua_block {
local ev = require "resty.worker.events"
local handler = function(data, event, source, pid)
print("received event; source=",source,
", event=",event,
", data=", tostring(data),
", from process ",pid)
end
ev.register(handler)
local ok, err = ev.configure {
shm = "process_events", -- defined by "lua_shared_dict"
timeout = 2, -- life time of unique event data in shm
interval = 1, -- poll interval (seconds)
wait_interval = 0.010, -- wait before retry fetching event data
wait_max = 0.5, -- max wait time before discarding event
shm_retries = 999, -- retries for shm fragmentation (no memory)
}
if not ok then
ngx.log(ngx.ERR, "failed to start event system: ", err)
return
end
}
server {
...
# example for polling:
location = /some/path {
default_type text/plain;
content_by_lua_block {
-- manually call `poll` to stay up to date, can be used instead,
-- or together with the timer interval. Polling is efficient,
-- so if staying up-to-date is important, this is preferred.
require("resty.worker.events").poll()
-- do regular stuff here
}
}
}
}
```描述 ===========
[返回目录](#table-of-contents)
该模块提供了一种向 Nginx 服务器中的其他工作进程发送事件的方法。通信通过共享内存区域进行，事件数据将存储在其中。
所有工作进程中事件的顺序 __保证__ 相同。
工作进程将在后台设置一个计时器来检查事件。该模块遵循单例模式，因此每个工作进程只运行一次。但是，如果需要保持最新状态，则可以将间隔设置为较低的频率，并对每个收到的请求调用 [poll](#poll) ，以确保尽快处理所有事件。
该设计允许 3 种用例；
1. 向所有工作进程广播事件，请参见 [post](#post) 。在这种情况下，所有工作进程中事件的顺序保证相同。例如：在一个工作进程中运行的健康检查，但通知所有工作进程上游节点出现故障。 2. 仅向本地工作进程广播事件，请参见 [post_local](#post_local) 。 3. 将外部事件合并到一个动作中。例如：所有工作进程都监视指示需要刷新内存缓存的外部事件。收到事件后，它们都会使用唯一的事件哈希值（所有工作进程生成相同的哈希值）将其发布，请参见 [post](#post) 的 `unique` 参数。现在，只有 1 个工作进程会 _只_ 接收该事件一次，因此只有 1 个工作进程会命中上游数据库以刷新内存数据。
该模块本身将使用 `source="resty-worker-events"` 触发两个事件； * `event="started"`，当模块首次配置时（注意：事件处理程序必须在调用 [configure](#configure) 之前 [注册](#register) ，才能捕获该事件） * `event="stopping"`，当工作进程退出时（基于计时器 `premature` 设置）
请参见 [event_list](#event_list) ，了解如何在没有硬编码魔术值/字符串的情况下使用事件。
故障排除 ================
为了正确地调整 shm 大小，了解其使用方法非常重要。事件数据存储在 shm 中，以便将其传递给其他工作进程。因此，shm 中有 2 种类型的条目
1. 仅由单个工作进程执行的事件（请参见 `post` 方法的 `unique` 参数）。这些条目在 shm 中获得 ttl，因此将过期。 2. 所有其他事件（本地事件除外，本地事件不使用 SHM）。在这些情况下，没有设置 ttl。
上述结果是 SHM 将始终处于满载状态！因此，这不是要调查的指标。
如何防止问题
* SHM 大小必须至少是预期最大有效载荷的倍数。它必须能够容纳在一个 `interval`（请参见 `configure`）内可能发送的所有事件。 * `no memory` 错误 _不能_ 通过增大 SHM 来解决。解决这些错误的唯一方法是增加传递给 configure 的 shm_retries 选项。这是因为错误是由于碎片化而不是内存不足造成的。 * 如果事件数据在所有工作进程处理它之前被逐出，则会出现 waiting for event data timed out 错误。如果出现大量（大负载）事件，则可能会发生这种情况。为了解决这些问题
* try to avoid big event payloads
* use a smaller `interval`, so workers check for (and deal with) events
more frequently (see `interval` option as passed to `configure`)
* increase the SHM size, such that it can hold all the event data that
might be send within 1 interval.方法 =======
[返回目录](#table-of-contents)
configure --------- `语法：success, err = events.configure(opts)`
将初始化事件监听器。opts 参数是一个带有命名选项的 Lua 表
* `shm`：（必需）要使用的共享内存的名称。事件数据不会过期，因此该模块依赖于 shm lru 机制从 shm 中逐出旧事件。因此，shm 可能不应用于其他目的。 * `shm_retries`：（可选）当 shm 在发布事件时返回“no memory”时的重试次数，默认值为 999。每次尝试插入而没有可用内存（没有可用空间或内存可用但已碎片化）时，都会逐出“最多十个”旧条目。之后，如果仍然没有可用内存，则会返回“no memory”错误。重试插入操作会多次触发逐出阶段，从而增加可用内存，以及找到足够大的连续内存块的可能性。 * `interval`：（可选）轮询事件的间隔（以秒为单位），默认值为 1。设置为 0 将禁用轮询。 * `wait_interval`：（可选）两次尝试之间的间隔，当找到新的 eventid 但数据尚未可用时（由于工作进程的异步行为） * `wait_max`：（可选）在丢弃事件之前，找到事件 id 后等待数据的最大时间。这是一个保险设置，以防出现问题。 * `timeout`：（可选）存储在 shm 中的唯一事件数据的超时时间（以秒为单位），默认值为 2。请参见 [post](#post) 方法的 `unique` 参数。
返回值将为 `true`，或为 `nil` 和错误消息。
该方法可以重复调用以更新设置，但 `shm` 值除外，该值在初始配置后不能更改。
注意：wait_interval 使用 ngx.sleep 函数执行。在 ngx.sleep 函数不可用（例如 init_worker）的上下文中，它将执行繁忙等待以执行延迟。
[返回目录](#table-of-contents)
configured ---------- `语法：is_already_configured = events.configured()`
事件模块在每个工作进程中作为一个 singelton 运行。configured 函数允许检查它是否已启动并运行。建议在启动任何依赖项之前进行检查；```lua local events = require "resty.worker.events"
local initialization_of_my_module = function() assert(events.configured(), "Please configure the 'lua-resty-worker-events' ".. "module before using my_module")
-- do initialization here
end
```[返回目录](#table-of-contents)
event_list ---------- `语法：_M.events = events.event_list(sourcename, event1, event2, ...)`
实用程序函数，用于生成事件列表并防止魔术字符串中的拼写错误。访问返回表中不存在的事件将导致“未知事件错误”。第一个参数 sourcename 是一个唯一的名称，用于标识事件源，该名称将作为字段 _source 可用。所有后续参数都是事件源生成的命名事件。
示例用法；```lua local ev = require "resty.worker.events"
-- 事件源示例
local events = ev.event_list( "my-module-event-source", -- 作为 _M.events._source 可用 "started", -- 作为 _M.events.started 可用 "event2" -- 作为 _M.events.event2 可用 )
local raise_event = function(event, data) return ev.post(events._source, event, data) end
-- 发布我自己的“started”事件 raise_event(events.started, nil) -- 为清晰起见为 nil，没有传递 eventdata
-- 定义我的模块表 local _M = { events = events -- 导出事件表
-- implementation goes here
}
return _M-- 事件客户端示例； local mymod = require("some_module") -- 带有“events”表的模块
-- 定义回调并使用源模块的事件表 local my_callback = function(data, event, source, pid) if event == mymod.events.started then -- “started” 是事件名称
-- started event from the resty-worker-events module
elseif event == mymod.events.stoppping then -- 'stopping' is the event name
-- the above will throw an error because of the typo in `stoppping`
end
endev.register(my_callback, mymod.events._source)
```
[返回目录](#table-of-contents)
poll ---- `语法：success, err = events.poll()`
将轮询新事件并处理所有事件（调用已注册的回调）。该实现非常高效，它只会检查单个共享内存值，如果没有任何新事件可用，则会立即返回。
返回值将为“done”，当它处理完所有事件时，为“recursive”，当它已在轮询循环中时，或为 `nil + error`，当出现错误时。“recursive” 结果发生在从事件处理程序发布事件时。事件处理程序从 `poll` 中调用，当发布事件时，发布方法也会在发布事件后调用 `poll`，从而导致循环。“recursive” 结果只是表示事件已成功发布，但尚未处理，因为还有其他事件需要先处理。
[返回目录](#table-of-contents)
post ---- `语法：success, err = events.post(source, event, data, unique)`
将发布一个新事件。`source` 和 `event` 都是字符串。`data` 可以是任何内容（包括 `nil`），只要它可以通过 cjson 模块进行（反）序列化即可。
如果提供了 `unique` 参数，则只有一个工作进程会执行该事件，其他工作进程将忽略它。此外，任何具有相同 `unique` 值的后续事件都将被忽略（对于传递给 [configure](#configure) 的 `timeout` 周期）。执行该事件的进程不一定发布该事件的进程。
在返回之前，它将调用 [poll](#poll) 来处理所有事件，直到并包括新发布的事件。检查返回值以确保它已完成，请参见 `poll`。
返回值将是 `poll` 的结果。
*注意*: 发送事件的 worker 进程也会收到事件！因此，如果 eventsource 也会对事件采取行动，它不应该从事件发布代码中执行此操作，而应该只在接收事件时执行。
[返回目录](#table-of-contents)
post_local ---------- `语法: success, err = events.post_local(source, event, data)`
与 [post](#post) 相同，但事件将局限于 worker 进程，不会广播到其他 worker。使用此方法，`data` 元素不会被 json 化。
在返回之前，它将调用 [poll](#poll) 首先处理发布的事件，然后处理所有其他新发布的事件。检查返回值以确保它已完成，请参阅 `poll`。
返回值将是 `poll` 的结果。
[返回目录](#table-of-contents)
register -------- `语法: events.register(callback, source, event1, event2, ...)`
将注册一个回调函数来接收事件。如果省略了 `source` 和 `event`，则回调将在 _每个_ 事件上执行；如果提供了 `source`，则只传递与源匹配的事件。如果给出了 (一个或多个) 事件名称，则只有在 `source` 和 `event` 都匹配时才会调用回调。
回调应该具有以下签名；
`语法: callback = function(data, event, source, pid)`
参数将与提供给 [post](#post) 的参数相同，除了额外的值 `pid`，它将是源 worker 进程的 pid，如果是本地事件，则为 `nil`。`callback` 的任何返回值都将被丢弃。*注意*: `data` 可能是数据类型的引用类型（例如 Lua `table` 类型）。相同的值传递给所有回调，_因此不要在您的处理程序中更改该值，除非您知道自己在做什么！_
`register` 的返回值将为 `true`，或者如果 `callback` 不是函数值，则会抛出错误。
*警告*: 事件处理程序必须快速返回。如果处理程序花费的时间超过配置的 `timeout` 值，事件将被丢弃！
*注意*: 要接收进程自己的 `started` 事件，必须在调用 [configure](#configure) 之前注册处理程序。
[返回目录](#table-of-contents)
register_weak ------------- `语法: events.register_weak(callback, source, event1, event2, ...)`
此函数与 `register` 相同，唯一的例外是该模块只会对 `callback` 函数保留 _弱引用_。
[返回目录](#table-of-contents)
unregister ---------- `语法: events.unregister(callback, source, event1, event2, ...)`
将注销回调函数并阻止它接收更多事件。参数的工作原理与 [register](#register) 完全相同。
返回值将为 `true` 如果它被移除，`false` 如果它不在处理程序列表中，或者如果 `callback` 不是函数值，则会抛出错误。
[返回目录](#table-of-contents)
安装 ============
不需要任何特殊的操作，像任何其他纯 Lua 模块一样安装。只需确保它的位置在模块搜索路径中即可。
[返回目录](#table-of-contents)
待办事项 ====
[返回目录](#table-of-contents)
* 在修复“停止”事件后，激活并实现第一个测试
错误和补丁 ================
请通过在 [GitHub 问题跟踪器](http://github.com/Kong/lua-resty-worker-events/issues) 上创建一个票证来报告错误或提交补丁，
[返回目录](#table-of-contents)
作者 ======
Thijs Schreijer <thijs@konghq.com>，Kong Inc.
[返回目录](#table-of-contents)
版权和许可 =====================
该模块是根据 [Apache 2.0 许可](https://open-source.org.cn/licenses/Apache-2.0) 授权的。
版权所有 (C) 2016-2019，由 Thijs Schreijer，Kong Inc. 所有。
保留所有权利。
[返回目录](#table-of-contents)
历史 =======
注意: 请在发布新版本时更新代码中的版本号！
1.1.0，未发布
- 修复: 在无法写入 shm 时改进日志记录（添加有效负载大小以进行故障排除）- 修复: 不要再记录有效负载，因为它可能会通过日志公开敏感数据 - 更改: 将 `shm_retries` 默认值更新为 999
1.0.0，2019 年 7 月 18 日
- 中断性变更: `poll`（因此也是 `post` 和 `post_local`）的返回值已更改为更类似于 Lua，在一切顺利时为真值。- 功能: 新选项 `shm_retries` 用于修复在发布事件时由 shm 中的内存碎片造成的“无内存”错误。- 修复: 修复了变量名称中的两个拼写错误（边缘情况）
0.3.3，2018 年 5 月 8 日
- 修复: 初始化阶段的超时，通过删除超时设置，请参阅问题 #9
0.3.2，2018 年 4 月 11 日
- 更改: 在处理程序错误中添加堆栈跟踪 - 修复: 如果值不可序列化，则错误处理程序失败，请参阅问题 #5 - 修复: 修复了弱处理程序的测试
[返回目录](#table-of-contents)
另请参阅 ======== * OpenResty: https://openresty.org.cn
[返回目录](#table-of-contents)
尝试避免大型事件有效负载 使用更小的 `interval`，这样 worker 可以更频繁地检查（和处理）事件（请参阅传递给 `configure` 的 `interval` 选项） 增加 SHM 大小，这样它可以容纳在一个间隔内可能发送的所有事件数据。
方法
configure
语法: success, err = events.configure(opts)
将初始化事件侦听器。opts 参数是一个具有命名选项的 Lua 表
shm: (必需) 要使用的共享内存的名称。事件数据不会过期，因此模块依赖于 shm lru 机制来从 shm 中驱逐旧事件。因此，shm 可能不应该用于其他目的。shm_retries: (可选) 当 shm 在发布事件时返回“无内存”时的重试次数，默认值为 999。每次尝试插入但没有内存可用（没有可用空间或内存可用但已碎片化）时，将驱逐“最多十几个”旧条目。之后，如果仍然没有可用内存，则返回“无内存”错误。重试插入会触发驱逐阶段多次，从而增加可用内存以及找到足够大的连续内存块的可能性，以供新的事件数据使用。interval: (可选) 轮询事件的间隔（以秒为单位），默认值为 1。设置为 0 以禁用轮询。wait_interval: (可选) 找到新的 eventid 但数据尚未可用（由于 worker 进程的异步行为）时，两次尝试之间的间隔wait_max: (可选) 在丢弃事件之前，找到事件 id 后等待数据的最长时间。这是一个故障安全设置，以防出现问题。timeout: (可选) 存储在 shm 中的唯一事件数据的超时（以秒为单位），默认值为 2。请参阅 post 方法的 `unique` 参数。
返回值将为 `true` 或 `nil` 和错误消息。
此方法可以重复调用以更新设置，除了 `shm` 值，该值在初始配置后无法更改。
注意: wait_interval 是使用 `ngx.sleep` 函数执行的。在该函数不可用的上下文中（例如 `init_worker`），它将执行一个忙等待以执行延迟。
configured
语法: is_already_configured = events.configured()
事件模块在每个 worker 进程中作为一个单例运行。configured 函数允许检查它是否已启动并运行。建议在启动任何依赖项之前进行检查；
local events = require "resty.worker.events"
local initialization_of_my_module = function()
assert(events.configured(), "Please configure the 'lua-resty-worker-events' "..
"module before using my_module")
-- do initialization here
endevent_list
语法: _M.events = events.event_list(sourcename, event1, event2, ...)
实用函数用于生成事件列表并防止魔术字符串中的拼写错误。访问返回表中不存在的事件会导致“未知事件错误”。第一个参数 `sourcename` 是一个唯一名称，用于标识事件源，该名称将作为字段 `_source` 可用。所有后续参数都是事件源生成的命名事件。
示例用法；
local ev = require "resty.worker.events"
-- Event source example
local events = ev.event_list(
"my-module-event-source", -- available as _M.events._source
"started", -- available as _M.events.started
"event2" -- available as _M.events.event2
)
local raise_event = function(event, data)
return ev.post(events._source, event, data)
end
-- Post my own 'started' event
raise_event(events.started, nil) -- nil for clarity, no eventdata is passed
-- define my module table
local _M = {
events = events -- export events table
-- implementation goes here
}
return _M
-- Event client example;
local mymod = require("some_module") -- module with an `events` table
-- define a callback and use source modules events table
local my_callback = function(data, event, source, pid)
if event == mymod.events.started then -- 'started' is the event name
-- started event from the resty-worker-events module
elseif event == mymod.events.stoppping then -- 'stopping' is the event name
-- the above will throw an error because of the typo in `stoppping`
end
end
ev.register(my_callback, mymod.events._source)
poll
语法: success, err = events.poll()
将轮询新事件并处理所有事件（调用已注册的回调）。该实现非常高效，它只会检查单个共享内存值，如果没有任何新事件可用，则会立即返回。
返回值将为 `“done”` 当它处理完所有事件时，如果它已经在轮询循环中，则为 `“recursive”`，或者如果出现问题，则为 `nil + error`。“recursive”` 结果发生在从事件处理程序发布事件时。事件处理程序是从 `poll` 中调用的，并且在发布事件时，post 方法也会在发布事件后调用 `poll`，从而导致循环。“recursive”` 结果只是意味着事件已成功发布，但尚未处理，因为其他需要首先处理的事件排在它前面。
post
语法: success, err = events.post(source, event, data, unique)
将发布一个新事件。source 和 `event` 都是字符串。data 可以是任何东西（包括 `nil`），只要它可以被 cjson 模块（反）序列化即可。
如果提供了 `unique` 参数，则只有一个 worker 将执行事件，其他 worker 将忽略它。此外，任何具有相同 `unique` 值的后续事件也将被忽略（对于传递给 configure 的 `timeout` 时间段）。执行事件的进程不一定是发布事件的进程。
在返回之前，它将调用 poll 处理直到新发布事件的所有事件。检查返回值以确保它已完成，请参阅 `poll`。
返回值将是 `poll` 的结果。
注意: 发送事件的 worker 进程也会收到事件！因此，如果 eventsource 也会对事件采取行动，它不应该从事件发布代码中执行此操作，而应该只在接收事件时执行。
post_local
语法: success, err = events.post_local(source, event, data)
与 post 相同，但事件将局限于 worker 进程，不会广播到其他 worker。使用此方法，`data` 元素不会被 json 化。
在返回之前，它将调用 poll 首先处理发布的事件，然后处理所有其他新发布的事件。检查返回值以确保它已完成，请参阅 `poll`。
返回值将是 `poll` 的结果。
register
语法: events.register(callback, source, event1, event2, ...)
将注册一个回调函数来接收事件。如果省略了 `source` 和 `event`，则回调将在 _每个_ 事件上执行；如果提供了 `source`，则只传递与源匹配的事件。如果给出了 (一个或多个) 事件名称，则只有在 `source` 和 `event` 都匹配时才会调用回调。
回调应该具有以下签名；
语法: callback = function(data, event, source, pid)
参数将与提供给 post 的参数相同，除了额外的值 `pid`，它将是源 worker 进程的 pid，如果是本地事件，则为 `nil`。`callback` 的任何返回值都将被丢弃。注意: `data` 可能是数据类型的引用类型（例如 Lua `table` 类型）。相同的值传递给所有回调，_因此不要在您的处理程序中更改该值，除非您知道自己在做什么！_
`register` 的返回值将为 `true`，或者如果 `callback` 不是函数值，则会抛出错误。
警告: 事件处理程序必须快速返回。如果处理程序花费的时间超过配置的 `timeout` 值，事件将被丢弃！
注意: 要接收进程自己的 `started` 事件，必须在调用 configure 之前注册处理程序。
register_weak
语法: events.register_weak(callback, source, event1, event2, ...)
此函数与 `register` 相同，唯一的例外是该模块只会对 `callback` 函数保留 _弱引用_。
unregister
语法: events.unregister(callback, source, event1, event2, ...)
将注销回调函数并阻止它接收更多事件。参数的工作原理与 register 完全相同。
返回值将为 `true` 如果它被移除，`false` 如果它不在处理程序列表中，或者如果 `callback` 不是函数值，则会抛出错误。
安装
不需要任何特殊的操作，像任何其他纯 Lua 模块一样安装。只需确保它的位置在模块搜索路径中即可。
待办事项
在修复“停止”事件后，激活并实现第一个测试
错误和补丁
请通过在 GitHub 问题跟踪器 上创建一个票证来报告错误或提交补丁，
作者
Thijs Schreijer <thijs@konghq.com>，Kong Inc.
版权和许可
该模块是根据 Apache 2.0 许可 授权的。
版权所有 (C) 2016-2019，由 Thijs Schreijer，Kong Inc. 所有。
保留所有权利。
历史
注意: 请在发布新版本时更新代码中的版本号！
1.1.0，未发布
修复: 改善了无法写入共享内存时的日志记录（添加了有效载荷大小以进行故障排除）
修复: 不再记录有效载荷，因为它可能会通过日志泄露敏感数据
更改: 将 `shm_retries` 的默认值更新为 999
1.0.0，2019 年 7 月 18 日
重大变更: `poll`（以及 `post` 和 `post_local`）的返回值已更改为更 Lua 化，在一切正常时为真值。
功能: 新选项 `shm_retries` 用于解决在发布事件时由于共享内存碎片化导致的“内存不足”错误。
修复: 修正了变量名称中的两个拼写错误（边缘情况）
0.3.3，2018 年 5 月 8 日
修复: 初始化阶段的超时问题，通过删除超时设置解决，参见 issue #9
0.3.2，2018 年 4 月 11 日
更改: 在处理程序错误中添加堆栈跟踪
修复: 如果值不可序列化，则修复失败的错误处理程序，参见 issue #5
修复: 修正了弱处理程序的测试
另请参见
OpenResty: https://openresty.org.cn
作者
Kong
许可证
apache2
版本
-
ua-resty-worker-events 2019-09-20 22:00:42