nginx的I/O worker玩法，伙伴们一起来看看它有什么弊端没 :)

yunthanatos

缘起:

毕业设计是做一个分布的元数据存储系统，并希望使用openresty与lua来完成 :)

权衡:

nginx的I/O阻塞是个比较麻烦的问题，如果涉及到大数据块的写入，经典的解法是使用cosocket将I/O任务分给另外独立的存储进程，自己则异步"等待"，以此来优化全局request响应时间。

但是这种方法会带来以下的一些缺点:

1.部署、运维麻烦（要维护两组服务）；

2.nginx要与后端的存储进程完成准确的状态同步：

0.nginx需要对进行存储初始化，确定何时；

1.存储崩溃时，nginx需要从其他节点成员处对其进行数据恢复；

2.严格的fsync语义，以防数据丢失。

所以，为了避开以上的若干问题，理想的方法是将繁重的I/O任务放到nginx里面去。

但是好像没见过有人这么玩，但是，WHY NOT？

解法：

归根结底，需要对nginx完成P0约束，才能这么玩：

P0:

让指定的某一些nginx workers永远不accept连接

P0的间接实现：(借助现有机制)

P0.1:

在每个worker的init_worker阶段，它们一起去抢若干把全局锁，只要成功地抢到一把，这个worker就是I/O worker(它接着就一直死循环(等待脏活任务、干脏活))。

如果连一把锁都没有抢到，那它就是正常的worker，accept新连接，处理之，如果有脏活了，就发给I/O worker，异步等待轮询结果，然后拿到结果，继续处理。

P0.11:

对于P0.1中所用的这若干把全局锁，如果锁的占有进程被杀了，内核必须能够为其立即进行锁回收(不能阻碍新I/O worker的重生)。

任务的发送与反馈:

normal worker

POST

{

src:dict.xx.content

desc:store

ret:dict.yy.unique_name

}

to msg-queue

then

I/O worker:

GET

store the content in src:dict.xx.content

set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

yuansheng

虽然我也很喜欢 OpenResty，但是这不代表我们要用我们喜欢的工具完成所有的事情。

比如我们很喜欢某把精致的小锤子，手感舒适，做工豪华，用它来给墙上钉钉子，简直是享受。但是用这把精致的锤子用来拆房子，显然有点使不上劲，就不如来个大号、笨重甚至丑陋的锤子痛快。

所以我更建议 OpenResty 还是采用常规玩法，更容易和大家交流切磋。

如果需要某个 I/O 或 CPU 比较重的业务，尽量拆分出去。如果你想在 OpenResty 世界并只使用 lua 语言，是否可以考虑 nginx_server + resty_cli（发型版本中默认就带了，目录 openresty/bin/resty）的组合？

2016-03-13 12:13 GMT+08:00 Yun Thanatos <yunth...@gmail.com>:

缘起:

毕业设计是做一个分布的元数据存储系统，并希望使用openresty与lua来完成 :)

权衡:

nginx的I/O阻塞是个比较麻烦的问题，如果涉及到大数据块的写入，经典的解法是使用cosocket将I/O任务分给另外独立的存储进程，自己则异步"等待"，以此来优化全局request响应时间。

但是这种方法会带来以下的一些缺点:

1.部署、运维麻烦（要维护两组服务）；

2.nginx要与后端的存储进程完成准确的状态同步：

0.nginx需要对进行存储初始化，确定何时；

1.存储崩溃时，nginx需要从其他节点成员处对其进行数据恢复；

2.严格的fsync语义，以防数据丢失。

所以，为了避开以上的若干问题，理想的方法是将繁重的I/O任务放到nginx里面去。

但是好像没见过有人这么玩，但是，WHY NOT？

解法：

归根结底，需要对nginx完成P0约束，才能这么玩：

P0:

让指定的某一些nginx workers永远不accept连接

P0的间接实现：(借助现有机制)

P0.1:

在每个worker的init_worker阶段，它们一起去抢若干把全局锁，只要成功地抢到一把，这个worker就是I/O worker(它接着就一直死循环(等待脏活任务、干脏活))。

如果连一把锁都没有抢到，那它就是正常的worker，accept新连接，处理之，如果有脏活了，就发给I/O worker，异步等待轮询结果，然后拿到结果，继续处理。

P0.11:

对于P0.1中所用的这若干把全局锁，如果锁的占有进程被杀了，内核必须能够为其立即进行锁回收(不能阻碍新I/O worker的重生)。

任务的发送与反馈:

normal worker

POST
{
src:dict.xx.content
desc:store
ret:dict.yy.unique_name
}

to msg-queue

then

I/O worker:

GET
store the content in src:dict.xx.content
set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

--

YuanSheng Wang

---------------------------------------

My Github: https://github.com/membphis

OpenResty lover ^_^

kytexzy

不知道能否在nginx的线程池中开一个线程来完成你的工作。

doujiang24

Hello,

在 2016年3月13日下午12:13，Yun Thanatos <yunth...@gmail.com>写道：

缘起:

毕业设计是做一个分布的元数据存储系统，并希望使用openresty与lua来完成 :)

权衡:

nginx的I/O阻塞是个比较麻烦的问题，如果涉及到大数据块的写入，经典的解法是使用cosocket将I/O任务分给另外独立的存储进程，自己则异步"等待"，以此来优化全局request响应时间。

但是这种方法会带来以下的一些缺点:

1.部署、运维麻烦（要维护两组服务）；

2.nginx要与后端的存储进程完成准确的状态同步：

0.nginx需要对进行存储初始化，确定何时；

1.存储崩溃时，nginx需要从其他节点成员处对其进行数据恢复；

2.严格的fsync语义，以防数据丢失。

所以，为了避开以上的若干问题，理想的方法是将繁重的I/O任务放到nginx里面去。

但是好像没见过有人这么玩，但是，WHY NOT？

解法：

归根结底，需要对nginx完成P0约束，才能这么玩：

P0:

让指定的某一些nginx workers永远不accept连接

P0的间接实现：(借助现有机制)

P0.1:

在每个worker的init_worker阶段，它们一起去抢若干把全局锁，只要成功地抢到一把，这个worker就是I/O worker(它接着就一直死循环(等待脏活任务、干脏活))。

如果连一把锁都没有抢到，那它就是正常的worker，accept新连接，处理之，如果有脏活了，就发给I/O worker，异步等待轮询结果，然后拿到结果，继续处理。

P0.11:

对于P0.1中所用的这若干把全局锁，如果锁的占有进程被杀了，内核必须能够为其立即进行锁回收(不能阻碍新I/O worker的重生)。

我的理解，你把 nginx 的 worker 进程分成了，normal 进程和 I/O 进程

normal 进程和 I/O 进程通过共享内存通讯（用以替代常规的 socket 通讯）

这里有个小问题：

共享内存通讯并没有事件通知机制， A worker 写入，B worker 并不能收到可读事件，如此 B 只能定时轮询，这就存在一个固定延时（虽然可以很短，或者再加一个 woker 之间的 socket 通讯）

另外，nginx 线程池方案，或许也值得对比一下

任务的发送与反馈:

normal worker

POST
{
src:dict.xx.content
desc:store
ret:dict.yy.unique_name
}

to msg-queue

then

I/O worker:

GET
store the content in src:dict.xx.content
set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

--

yunthanatos

2016-03-14 17:44 GMT+08:00 DeJiang Zhu <douj...@gmail.com>:

Hello,

在 2016年3月13日下午12:13，Yun Thanatos <yunth...@gmail.com>写道：

缘起:

毕业设计是做一个分布的元数据存储系统，并希望使用openresty与lua来完成 :)

赞

权衡:

nginx的I/O阻塞是个比较麻烦的问题，如果涉及到大数据块的写入，经典的解法是使用cosocket将I/O任务分给另外独立的存储进程，自己则异步"等待"，以此来优化全局request响应时间。

但是这种方法会带来以下的一些缺点:

1.部署、运维麻烦（要维护两组服务）；

2.nginx要与后端的存储进程完成准确的状态同步：

0.nginx需要对进行存储初始化，确定何时；

1.存储崩溃时，nginx需要从其他节点成员处对其进行数据恢复；

2.严格的fsync语义，以防数据丢失。

所以，为了避开以上的若干问题，理想的方法是将繁重的I/O任务放到nginx里面去。

但是好像没见过有人这么玩，但是，WHY NOT？

解法：

归根结底，需要对nginx完成P0约束，才能这么玩：

P0:

让指定的某一些nginx workers永远不accept连接

P0的间接实现：(借助现有机制)

P0.1:

在每个worker的init_worker阶段，它们一起去抢若干把全局锁，只要成功地抢到一把，这个worker就是I/O worker(它接着就一直死循环(等待脏活任务、干脏活))。

如果连一把锁都没有抢到，那它就是正常的worker，accept新连接，处理之，如果有脏活了，就发给I/O worker，异步等待轮询结果，然后拿到结果，继续处理。

P0.11:

对于P0.1中所用的这若干把全局锁，如果锁的占有进程被杀了，内核必须能够为其立即进行锁回收(不能阻碍新I/O worker的重生)。

我的理解，你把 nginx 的 worker 进程分成了，normal 进程和 I/O 进程
normal 进程和 I/O 进程通过共享内存通讯（用以替代常规的 socket 通讯）

是的，正是如此：）

（当然，更准确的说，是msg-queue与共享内存，msg用来传递“调用”的元信息，共享内存相当于指针所指向的数据存储区）

这里有个小问题：
共享内存通讯并没有事件通知机制， A worker 写入，B worker 并不能收到可读事件，如此 B 只能定时轮询，这就存在一个固定延时（虽然可以很短，或者再加一个 woker 之间的 socket 通讯）

这种“调用”的返回目前只能通过定时轮询，这样的话压力都会落到timer上面。

最关键的原因是，现在ngx-lua上还没有类似<resty.event>的实现（一种更高层的事件抽象），它是个假想的库，描述如下:

local lib_event = require"resty.event"

local event_notify = lib_event.new()

assert( set_dict_key_value(unique_key, event_notify.name) )

-- other i/o worker will processes this task and trigger the event_notify finally

assert( send_task_queue(task_name, unique_key) )

local ret = event_notify.wait()

-- ret process
-- timeout or
-- other status ...

如你所说，如果使用socket进行事件触发，就又回到了nginx的经典模式，它问题是：

单个worker的阻塞怎么才能保证不会影响（来自外部的 && 本应能够被及时处理并返回的）短连接请求的响应时间呢？

这又回到了原点。

所以，如果存在一个理想的resty.event实现，能够实现跨worker的事件通知，就可以不再使用ngx.sleep进行轮询，而是能够用更高效的事件wait。

但是，由于：

大部分存储类(如sql查询、键值存储、cache service)的web服务端的耗时热点都在I/O上，它才是影响系统吞吐率与平均响应的关键。

所以，这种从90分到100分的优化，到底有没有必要呢？

另外，nginx 线程池方案，或许也值得对比一下

关于nginx线程池，我认为它只是I/O任务异步化的一种具体实现，但是更多时候，我们更需要的是一种机制，而非策略。事实上，又有多少人在生产中选用了(nginx+I/O线程池)组合的cache server呢？

系统工程师面临的问题大部分都是I/O不对称的问题：

register -- cache -- ddr memory -- ssd -- disk -- network

如果如果采用 normal worker + i/o worker 的组合:

我们就可以使用lua脚本分分钟钟地写出一个类似redis、memcache的简陋实现，可以迅速地基于BDB、leveldb等存储引擎开发出高效的存储服务。

Why not :)

任务的发送与反馈:

normal worker

POST
{
src:dict.xx.content
desc:store
ret:dict.yy.unique_name
}

to msg-queue

then

I/O worker:

GET
store the content in src:dict.xx.content
set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

--

--

yunthanatos

线程池的机制确实是一种将阻塞的调用异步化的很好实现，但是它不能够自定义阻塞调用的内容：

如果想要通过一个自定义的存储引擎将一块数据存储起来还要自己专门写一套类似于(nginx的线程池)的ngx c addon实现

那么，为什么不能在lua层面提供一个这样的机制，让我们以后都能够愉快地、轻松地写自己的阻塞调用的具体定义呢？

On Mon, Mar 14, 2016 at 2:34 PM, Nero.Ping <kyt...@gmail.com> wrote:

不知道能否在nginx的线程池中开一个线程来完成你的工作。

--

yunthanatos

2016-03-14 13:23 GMT+08:00 YuanSheng Wang <yuan...@openresty.org>:

虽然我也很喜欢 OpenResty，但是这不代表我们要用我们喜欢的工具完成所有的事情。

赞同你的看法 :)

比如我们很喜欢某把精致的小锤子，手感舒适，做工豪华，用它来给墙上钉钉子，简直是享受。但是用这把精致的锤子用来拆房子，显然有点使不上劲，就不如来个大号、笨重甚至丑陋的锤子痛快。

所以我更建议 OpenResty 还是采用常规玩法，更容易和大家交流切磋。

如果需要某个 I/O 或 CPU 比较重的业务，尽量拆分出去。如果你想在 OpenResty 世界并只使用 lua 语言，是否可以考虑 nginx_server + resty_cli（发型版本中默认就带了，目录 openresty/bin/resty）的组合？

resty_cli确实很好用，前一段时间我甚至使用它写了一个简陋的爬虫系统，确实很好玩 :)

这里，可以把lua比作是个小锤子，将python、go、c++、c等比作大锤子，于是，我们知道：

lua在诞生时，就注定是把精致的小锤子，那是因为它的设计者手中正缺一把小锤子。

那为什么当初选定lua作为openresty的脚本语言呢？

那是因为openresty正需要一把小锤子，看到了lua，于是就自然地拿来用了 :)

在这里，我们心中完美的“小锤子”语言的其实是DSL。

openresty为这个DSL语言实现了很多底层机制，于是我们可以很开心地、很轻松地写出足以胜任C10K的web应用。

那么，为什么不能为这个DSL引入更酷的机制，让我们以后可以很开心地、很轻松地写出足以胜任C10K的web应用、可以自定义存储引擎的存储服务呢？

I/O worker - - - - - normal worker

| |

(luajit ffi <--> leveldb | bdb | ... ) new tcp/udp request

其实，openresty并不需要为这个机制的实现做多大牺牲，它只需要保证能完成P0.1这个约束即可(目前已实现)：

另外，一个很酷的DSL自定义事件机制<resty.event>是可选的 :)

-- -- -- -- --

当然，不一定只能是存储，任何阻塞调用都可以，甚至是如下：（这个有点过了：）

           I/O worker
                  |
    ---           |        --
|                                |

python go

image process other stuff

（使用IPC完成过程调用语义）

2016-03-13 12:13 GMT+08:00 Yun Thanatos <yunth...@gmail.com>:

缘起:

毕业设计是做一个分布的元数据存储系统，并希望使用openresty与lua来完成 :)

权衡:

nginx的I/O阻塞是个比较麻烦的问题，如果涉及到大数据块的写入，经典的解法是使用cosocket将I/O任务分给另外独立的存储进程，自己则异步"等待"，以此来优化全局request响应时间。

但是这种方法会带来以下的一些缺点:

1.部署、运维麻烦（要维护两组服务）；

2.nginx要与后端的存储进程完成准确的状态同步：

0.nginx需要对进行存储初始化，确定何时；

1.存储崩溃时，nginx需要从其他节点成员处对其进行数据恢复；

2.严格的fsync语义，以防数据丢失。

所以，为了避开以上的若干问题，理想的方法是将繁重的I/O任务放到nginx里面去。

但是好像没见过有人这么玩，但是，WHY NOT？

解法：

归根结底，需要对nginx完成P0约束，才能这么玩：

P0:

让指定的某一些nginx workers永远不accept连接

P0的间接实现：(借助现有机制)

P0.1:

在每个worker的init_worker阶段，它们一起去抢若干把全局锁，只要成功地抢到一把，这个worker就是I/O worker(它接着就一直死循环(等待脏活任务、干脏活))。

如果连一把锁都没有抢到，那它就是正常的worker，accept新连接，处理之，如果有脏活了，就发给I/O worker，异步等待轮询结果，然后拿到结果，继续处理。

P0.11:

对于P0.1中所用的这若干把全局锁，如果锁的占有进程被杀了，内核必须能够为其立即进行锁回收(不能阻碍新I/O worker的重生)。

任务的发送与反馈:

normal worker

POST
{
src:dict.xx.content
desc:store
ret:dict.yy.unique_name
}

to msg-queue

then

I/O worker:

GET
store the content in src:dict.xx.content
set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

--

--

YuanSheng Wang
---------------------------------------
My Github: https://github.com/membphis
OpenResty lover ^_^

--

yunthanatos

是的，使用ngx.sleep轮询来模拟事件通知的不足之处是：

不好优化外部请求的最低响应时间。

但是，任何开环的控制问题都能够通过引入闭环的控制来进行自适应地优化：

i/o worker公开(负载、估计返回时间)等状态信息，normal worker依此确定要多久轮询一次 :)

2016-03-14 17:44 GMT+08:00 DeJiang Zhu <douj...@gmail.com>:

Hello,

在 2016年3月13日下午12:13，Yun Thanatos <yunth...@gmail.com>写道：

缘起:

毕业设计是做一个分布的元数据存储系统，并希望使用openresty与lua来完成 :)

赞

权衡:

nginx的I/O阻塞是个比较麻烦的问题，如果涉及到大数据块的写入，经典的解法是使用cosocket将I/O任务分给另外独立的存储进程，自己则异步"等待"，以此来优化全局request响应时间。

但是这种方法会带来以下的一些缺点:

1.部署、运维麻烦（要维护两组服务）；

2.nginx要与后端的存储进程完成准确的状态同步：

0.nginx需要对进行存储初始化，确定何时；

1.存储崩溃时，nginx需要从其他节点成员处对其进行数据恢复；

2.严格的fsync语义，以防数据丢失。

所以，为了避开以上的若干问题，理想的方法是将繁重的I/O任务放到nginx里面去。

但是好像没见过有人这么玩，但是，WHY NOT？

解法：

归根结底，需要对nginx完成P0约束，才能这么玩：

P0:

让指定的某一些nginx workers永远不accept连接

P0的间接实现：(借助现有机制)

P0.1:

在每个worker的init_worker阶段，它们一起去抢若干把全局锁，只要成功地抢到一把，这个worker就是I/O worker(它接着就一直死循环(等待脏活任务、干脏活))。

如果连一把锁都没有抢到，那它就是正常的worker，accept新连接，处理之，如果有脏活了，就发给I/O worker，异步等待轮询结果，然后拿到结果，继续处理。

P0.11:

对于P0.1中所用的这若干把全局锁，如果锁的占有进程被杀了，内核必须能够为其立即进行锁回收(不能阻碍新I/O worker的重生)。

我的理解，你把 nginx 的 worker 进程分成了，normal 进程和 I/O 进程
normal 进程和 I/O 进程通过共享内存通讯（用以替代常规的 socket 通讯）

这里有个小问题：
共享内存通讯并没有事件通知机制， A worker 写入，B worker 并不能收到可读事件，如此 B 只能定时轮询，这就存在一个固定延时（虽然可以很短，或者再加一个 woker 之间的 socket 通讯）

另外，nginx 线程池方案，或许也值得对比一下

任务的发送与反馈:

normal worker

POST
{
src:dict.xx.content
desc:store
ret:dict.yy.unique_name
}

to msg-queue

then

I/O worker:

GET
store the content in src:dict.xx.content
set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

--

--

doujiang24

Hello,

在 2016年3月14日下午9:53，燕云 <yunth...@gmail.com>写道：

这里有个小问题：
共享内存通讯并没有事件通知机制， A worker 写入，B worker 并不能收到可读事件，如此 B 只能定时轮询，这就存在一个固定延时（虽然可以很短，或者再加一个 woker 之间的 socket 通讯）

这种“调用”的返回目前只能通过定时轮询，这样的话压力都会落到timer上面。

这个给 timer 带来的压力倒不大，主要是给业务上带来的固定延时

最关键的原因是，现在ngx-lua上还没有类似<resty.event>的实现（一种更高层的事件抽象），它是个假想的库，描述如下:

没有跨 worker 的事件通知机制，更多的处于性能上的考量

worker 内的事件通知机制，可以做到完全用户态，例如 ngx.semaphore

如果要跨 worker 的话，不可避免的要用到内核态的进程通讯手段（例如，内核态的 semaphore）

如果通讯频繁的话，性能应该是会有问题的，不过在你描述的这种场景里，似乎也还可以考虑（这一点我还没有测试研究过）

另外，nginx 线程池方案，或许也值得对比一下

关于nginx线程池，我认为它只是I/O任务异步化的一种具体实现，但是更多时候，我们更需要的是一种机制，而非策略。事实上，又有多少人在生产中选用了(nginx+I/O线程池)组合的cache server呢？

我想的 nginx 线程池方案，大致是用 nginx 现有的线程池来替代你的 I/O worker

我不太确定这两种的通讯成本优劣

系统工程师面临的问题大部分都是I/O不对称的问题：

    register -- cache -- ddr memory -- ssd -- disk -- network

如果如果采用 normal worker + i/o worker 的组合:

    我们就可以使用lua脚本分分钟钟地写出一个类似redis、memcache的简陋实现，可以迅速地基于BDB、leveldb等存储引擎开发出高效的存储服务。

Why not :)


任务的发送与反馈:

normal worker

POST
{
src:dict.xx.content
desc:store
ret:dict.yy.unique_name
}

to msg-queue

then

I/O worker:

GET
store the content in src:dict.xx.content
set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

--

--

--

yunthanatos

2016-03-15 19:43 GMT+08:00 DeJiang Zhu <douj...@gmail.com>:

Hello,

在 2016年3月14日下午9:53，燕云 <yunth...@gmail.com>写道：

这里有个小问题：
共享内存通讯并没有事件通知机制， A worker 写入，B worker 并不能收到可读事件，如此 B 只能定时轮询，这就存在一个固定延时（虽然可以很短，或者再加一个 woker 之间的 socket 通讯）

这种“调用”的返回目前只能通过定时轮询，这样的话压力都会落到timer上面。

这个给 timer 带来的压力倒不大，主要是给业务上带来的固定延时

是的，在沒有优雅、高效的跨worker事件通知之前，固定延时的问题很难完美解决。

也许，这个问题的解决思路可以参考tcp中超时重试发包的时间间隔的取法，由快到慢的去适应，甚至再加上i/o worker的负载与处理时间预估等来综合评定。

这个固定的延时，让我想到了berkeley db中的组提交延迟 :)

最关键的原因是，现在ngx-lua上还没有类似<resty.event>的实现（一种更高层的事件抽象），它是个假想的库，描述如下:

没有跨 worker 的事件通知机制，更多的处于性能上的考量

worker 内的事件通知机制，可以做到完全用户态，例如 ngx.semaphore
如果要跨 worker 的话，不可避免的要用到内核态的进程通讯手段（例如，内核态的 semaphore）

如果从内核设计者的角度，要实现一个高效、简洁的进程间事件通知机制，并不是没有可能，只是现在还没有类似的实现而已。

如果通讯频繁的话，性能应该是会有问题的，不过在你描述的这种场景里，似乎也还可以考虑（这一点我还没有测试研究过）

是的 :)

实际测试一下方案的效果，会更加真实和更有说服力，我最近在一直做这方面的尝试。

另外，nginx 线程池方案，或许也值得对比一下

关于nginx线程池，我认为它只是I/O任务异步化的一种具体实现，但是更多时候，我们更需要的是一种机制，而非策略。事实上，又有多少人在生产中选用了(nginx+I/O线程池)组合的cache server呢？

我想的 nginx 线程池方案，大致是用 nginx 现有的线程池来替代你的 I/O worker
我不太确定这两种的通讯成本优劣

是的，这样就等于是直接在线程池的基础上做开发定制。

但是，这个还有个问题：

分别隶属于各个worker的线程，它们之间可能也要同步和通讯，这样就等于将worker的循环等待移到线程的阻塞上了，如果并发要求很高的话，这么多线程的资源消耗应该也是不容忽视的。

如果我们的nginx是直接面向用户进行提供服务的，这个ngx.sleep所额外增加的50ms左右延迟是不是就会对服务质量的影响不是那么关键了呢？

系统工程师面临的问题大部分都是I/O不对称的问题：

    register -- cache -- ddr memory -- ssd -- disk -- network

如果如果采用 normal worker + i/o worker 的组合:

    我们就可以使用lua脚本分分钟钟地写出一个类似redis、memcache的简陋实现，可以迅速地基于BDB、leveldb等存储引擎开发出高效的存储服务。

Why not :)


任务的发送与反馈:

normal worker

POST
{
src:dict.xx.content
desc:store
ret:dict.yy.unique_name
}

to msg-queue

then

I/O worker:

GET
store the content in src:dict.xx.content
set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

--

--

--

--

yunthanatos

2016-03-16 23:54 GMT+08:00 燕云 <yunth...@gmail.com>:

2016-03-15 19:43 GMT+08:00 DeJiang Zhu <douj...@gmail.com>:
Hello,

在 2016年3月14日下午9:53，燕云 <yunth...@gmail.com>写道：

这里有个小问题：
共享内存通讯并没有事件通知机制， A worker 写入，B worker 并不能收到可读事件，如此 B 只能定时轮询，这就存在一个固定延时（虽然可以很短，或者再加一个 woker 之间的 socket 通讯）

这种“调用”的返回目前只能通过定时轮询，这样的话压力都会落到timer上面。

这个给 timer 带来的压力倒不大，主要是给业务上带来的固定延时

是的，在沒有优雅、高效的跨worker事件通知之前，固定延时的问题很难完美解决。

也许，这个问题的解决思路可以参考tcp中超时重试发包的时间间隔的取法，由快到慢的去适应，甚至再加上i/o worker的负载与处理时间预估等来综合评定。

这个固定的延时，让我想到了berkeley db中的组提交延迟 :)

最关键的原因是，现在ngx-lua上还没有类似<resty.event>的实现（一种更高层的事件抽象），它是个假想的库，描述如下:

没有跨 worker 的事件通知机制，更多的处于性能上的考量

worker 内的事件通知机制，可以做到完全用户态，例如 ngx.semaphore
如果要跨 worker 的话，不可避免的要用到内核态的进程通讯手段（例如，内核态的 semaphore）

如果从内核设计者的角度，要实现一个高效、简洁的进程间事件通知机制，并不是没有可能，只是现在还没有类似的实现而已。

如果通讯频繁的话，性能应该是会有问题的，不过在你描述的这种场景里，似乎也还可以考虑（这一点我还没有测试研究过）

是的 :)

实际测试一下方案的效果，会更加真实和更有说服力，我最近在一直做这方面的尝试。

另外，nginx 线程池方案，或许也值得对比一下

关于nginx线程池，我认为它只是I/O任务异步化的一种具体实现，但是更多时候，我们更需要的是一种机制，而非策略。事实上，又有多少人在生产中选用了(nginx+I/O线程池)组合的cache server呢？

我想的 nginx 线程池方案，大致是用 nginx 现有的线程池来替代你的 I/O worker
我不太确定这两种的通讯成本优劣

是的，这样就等于是直接在线程池的基础上做开发定制。

但是，这个还有个问题：

分别隶属于各个worker的线程，它们之间可能也要同步和通讯，这样就等于将worker的循环等待移到线程的阻塞上了，如果并发要求很高的话，这么多线程的资源消耗应该也是不容忽视的。

如果我们的nginx是直接面向用户进行提供服务的，这个ngx.sleep所额外增加的50ms左右延迟是不是就会对服务质量的影响不是那么关键了呢？

因为传统是nginx需要再用socket将存储数据从别处拉过来（可能是本地或其他机器），再返回给用户，而现在的一部分就变成了本机ipc与异步轮询返回状态，这二者延迟也许相差并太不多 :)

系统工程师面临的问题大部分都是I/O不对称的问题：

    register -- cache -- ddr memory -- ssd -- disk -- network

如果如果采用 normal worker + i/o worker 的组合:

    我们就可以使用lua脚本分分钟钟地写出一个类似redis、memcache的简陋实现，可以迅速地基于BDB、leveldb等存储引擎开发出高效的存储服务。

Why not :)


任务的发送与反馈:

normal worker

POST
{
src:dict.xx.content
desc:store
ret:dict.yy.unique_name
}

to msg-queue

then

I/O worker:

GET
store the content in src:dict.xx.content
set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

--

--

--

--

yunthanatos

而且这部分返回数据是通过共享内存来传递的，可能要比tcp拥塞控制慢启动要传的更加快速(当然，这会存在一个中间大小的临界值)。

2016-03-17 0:00 GMT+08:00 燕云 <yunth...@gmail.com>:

2016-03-16 23:54 GMT+08:00 燕云 <yunth...@gmail.com>:

2016-03-15 19:43 GMT+08:00 DeJiang Zhu <douj...@gmail.com>:
Hello,

在 2016年3月14日下午9:53，燕云 <yunth...@gmail.com>写道：

这里有个小问题：
共享内存通讯并没有事件通知机制， A worker 写入，B worker 并不能收到可读事件，如此 B 只能定时轮询，这就存在一个固定延时（虽然可以很短，或者再加一个 woker 之间的 socket 通讯）

这种“调用”的返回目前只能通过定时轮询，这样的话压力都会落到timer上面。

这个给 timer 带来的压力倒不大，主要是给业务上带来的固定延时

是的，在沒有优雅、高效的跨worker事件通知之前，固定延时的问题很难完美解决。

也许，这个问题的解决思路可以参考tcp中超时重试发包的时间间隔的取法，由快到慢的去适应，甚至再加上i/o worker的负载与处理时间预估等来综合评定。

这个固定的延时，让我想到了berkeley db中的组提交延迟 :)

最关键的原因是，现在ngx-lua上还没有类似<resty.event>的实现（一种更高层的事件抽象），它是个假想的库，描述如下:

没有跨 worker 的事件通知机制，更多的处于性能上的考量

worker 内的事件通知机制，可以做到完全用户态，例如 ngx.semaphore
如果要跨 worker 的话，不可避免的要用到内核态的进程通讯手段（例如，内核态的 semaphore）

如果从内核设计者的角度，要实现一个高效、简洁的进程间事件通知机制，并不是没有可能，只是现在还没有类似的实现而已。

如果通讯频繁的话，性能应该是会有问题的，不过在你描述的这种场景里，似乎也还可以考虑（这一点我还没有测试研究过）


是的 :)

实际测试一下方案的效果，会更加真实和更有说服力，我最近在一直做这方面的尝试。

另外，nginx 线程池方案，或许也值得对比一下

关于nginx线程池，我认为它只是I/O任务异步化的一种具体实现，但是更多时候，我们更需要的是一种机制，而非策略。事实上，又有多少人在生产中选用了(nginx+I/O线程池)组合的cache server呢？

我想的 nginx 线程池方案，大致是用 nginx 现有的线程池来替代你的 I/O worker
我不太确定这两种的通讯成本优劣

是的，这样就等于是直接在线程池的基础上做开发定制。

但是，这个还有个问题：

    分别隶属于各个worker的线程，它们之间可能也要同步和通讯，这样就等于将worker的循环等待移到线程的阻塞上了，如果并发要求很高的话，这么多线程的资源消耗应该也是不容忽视的。

如果我们的nginx是直接面向用户进行提供服务的，这个ngx.sleep所额外增加的50ms左右延迟是不是就会对服务质量的影响不是那么关键了呢？

因为传统是nginx需要再用socket将存储数据从别处拉过来（可能是本地或其他机器），再返回给用户，而现在的一部分就变成了本机ipc与异步轮询返回状态，这二者延迟也许相差并太不多 :)

系统工程师面临的问题大部分都是I/O不对称的问题：

    register -- cache -- ddr memory -- ssd -- disk -- network

如果如果采用 normal worker + i/o worker 的组合:

    我们就可以使用lua脚本分分钟钟地写出一个类似redis、memcache的简陋实现，可以迅速地基于BDB、leveldb等存储引擎开发出高效的存储服务。

Why not :)


任务的发送与反馈:

normal worker

POST
{
src:dict.xx.content
desc:store
ret:dict.yy.unique_name
}

to msg-queue

then

I/O worker:

GET
store the content in src:dict.xx.content
set ret:dict.yy.unique_name

草图：

Classical Situation:

Solution when using I/O workers:

IPC when using I/O workers:

请大家看看这种玩法的弊端是什么呢？

--

--

--

--

agentzh

Hello!

2016-03-14 8:05 GMT-07:00 燕云:
>   在这里，我们心中完美的“小锤子”语言的其实是DSL。
>

赞，我现在也在这么搞。

>   openresty为这个DSL语言实现了很多底层机制，于是我们可以很开心地、很轻松地写出足以胜任C10K的web应用。
>

完全同意。

>   那么，为什么不能为这个DSL引入更酷的机制，让我们以后可以很开心地、很轻松地写出足以胜任C10K的web应用、可以自定义存储引擎的存储服务呢？
>
>             I/O worker    -      -           -            -       -    normal worker
>                   |                                                               |
> (luajit ffi <--> leveldb | bdb | ... )                             new tcp/udp request
>
>   其实，openresty并不需要为这个机制的实现做多大牺牲，它只需要保证能完成P0.1这个约束即可(目前已实现)：

我建议这里的 I/O worker 与 normal worker 之间通过 unix domain socket
进行通信。貌似在此之前，我们需要让 ngx_lua 的 cosocket 支持 bind() :) 欢迎贡献补丁。

>
>   另外，一个很酷的DSL自定义事件机制<resty.event>是可选的 :)
>

嗯嗯，我觉得 datagram 类型的 unix domain socket 在这里用于跨 worker
的消息传递还是挺爽的。如果能做到连接内 session 的多路复用就更好了（当然了，这对于 ngx_lua 核心来说，属于应用层的逻辑了）。

> 当然，不一定只能是存储，任何阻塞调用都可以，甚至是如下：（这个有点过了：）
>
>            I/O worker
>                   |
>     ---           |        --
> |                                |
> python                      go
> |
> image process         other stuff
>
> （使用IPC完成过程调用语义）

我其实在这里想的是让 I/O worker 直接调用 systemtap 之类的东西，哈哈！

当然了，直接阻塞一个普通的 nginx worker 进程来做 I/O worker 太 hacky 了。nginx
其实是支持启动不服务客户端的特殊 worker 进程的，比如现有的 cache manager worker 就是这样的例子。我觉得
ngx_lua 模块也可以支持这种玩法。欢迎贡献补丁 :)

P.S. 我其实一直有点儿想把 LMDB 整合进 OpenResty/NGINX：http://symas.com/mdb/

Regards,
-agentzh

yunthanatos

2016-03-17 4:29 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2016-03-14 8:05 GMT-07:00 燕云:
> 在这里，我们心中完美的“小锤子”语言的其实是DSL。
>

赞，我现在也在这么搞。

> openresty为这个DSL语言实现了很多底层机制，于是我们可以很开心地、很轻松地写出足以胜任C10K的web应用。
>

完全同意。

> 那么，为什么不能为这个DSL引入更酷的机制，让我们以后可以很开心地、很轻松地写出足以胜任C10K的web应用、可以自定义存储引擎的存储服务呢？
>
> I/O worker - - - - - normal worker
> | |
> (luajit ffi <--> leveldb | bdb | ... ) new tcp/udp request
>
> 其实，openresty并不需要为这个机制的实现做多大牺牲，它只需要保证能完成P0.1这个约束即可(目前已实现)：

我建议这里的 I/O worker 与 normal worker 之间通过 unix domain socket
进行通信。貌似在此之前，我们需要让 ngx_lua 的 cosocket 支持 bind() :) 欢迎贡献补丁。

>
> 另外，一个很酷的DSL自定义事件机制<resty.event>是可选的 :)
>

嗯嗯，我觉得 datagram 类型的 unix domain socket 在这里用于跨 worker
的消息传递还是挺爽的。如果能做到连接内 session 的多路复用就更好了（当然了，这对于 ngx_lua 核心来说，属于应用层的逻辑了）。

cosocket的bind，是我们每个人梦寐以求的好东西 :-)

> 当然，不一定只能是存储，任何阻塞调用都可以，甚至是如下：（这个有点过了：）
>
> I/O worker
> |
> --- | --
> | |
> python go
> |
> image process other stuff
>
> （使用IPC完成过程调用语义）

我其实在这里想的是让 I/O worker 直接调用 systemtap 之类的东西，哈哈！

当然了，直接阻塞一个普通的 nginx worker 进程来做 I/O worker 太 hacky 了。nginx
其实是支持启动不服务客户端的特殊 worker 进程的，比如现有的 cache manager worker 就是这样的例子。我觉得
ngx_lua 模块也可以支持这种玩法。欢迎贡献补丁 :)

P.S. 我其实一直有点儿想把 LMDB 整合进 OpenResty/NGINX：http://symas.com/mdb/

这里，关于LMDB有个问题没有弄明白，它是怎么能做到crash-proof的哩？（如果考虑到在系统异常掉电的情况下）

或者说，它的意思只是能保证在系统正常运行情况之下的crash-proof，例如正常关机，但是不包括异常掉电，这里的crash针对的只是用户进程？

Regards,
-agentzh

--