使用lua模块实现comet服务器的问题

hackers365 · 2015-01-15T14:33:29+00:00

非常感谢！在 2015年1月14日星期三 UTC+8下午5:40:27，Xiaohong Zhao&#x...

使用lua模块实现comet服务器的问题

hackers365

这几天一直在想能不能用lua模块的协程来实现长连接服务器。

使用coroutine.create创建一个协程。然后将thread句柄存到ngx.shared.dict中。挂起来。。当有pub数据的时候。从ngx.shared.dict中取出来协程的thread句柄。resume这个协程。返回数据。

不知道这个想是否行的通。

agentzh

Hello!

2015-01-14 22:33 GMT-08:00 shi jingbo:
> 这几天一直在想能不能用lua模块的协程来实现长连接服务器。
>
> 使用coroutine.create创建一个协程。然后将thread句柄存到ngx.shared.dict中。挂起来。。当有pub数据的时候。从ngx.shared.dict中取出来协程的thread句柄。resume这个协程。返回数据。
>

不可行。这是因为

1. Lua 协程是每 Lua VM 的，而 Lua VM 是每 nginx worker 进程的，而 nginx 一般会配置多个
nginx worker 进程。

2. OpenResty 实现的 coroutine 和 ngx.thread 对象本身强制使用每请求的生命期，所以这些 Lua
对象不能跨请求传递和共享。（这种设计主要是为了方便资源管理方面的优化以及避免用户犯许多类型的低级错误。）

建议使用 lua-resty-lock 这样的库来实现不同请求之间的同步：

   https://github.com/openresty/lua-resty-lock

Regards,
-agentzh

kmoving

多个coroutine通过resty-lock同步数据没有问题,不过同一个coroutine通过resty-lock很难把自己block起来,并且通过其他coroutine来唤醒.
因为同一个coroutine block自己需要lock两次同一个key,但是unlock是对象级别的,其他的coroutine很难知道这个coroutine是什么,所以也就没有办法唤醒了.

在 2015年1月16日星期五 UTC+8上午2:40:18，agentzh写道：

Hello!

2015-01-14 22:33 GMT-08:00 shi jingbo:
> 这几天一直在想能不能用lua模块的协程来实现长连接服务器。
>
> 使用coroutine.create创建一个协程。然后将thread句柄存到ngx.shared.dict中。挂起来。。当有pub数据的时候。从ngx.shared.dict中取出来协程的thread句柄。resume这个协程。返回数据。
>

不可行。这是因为

1. Lua 协程是每 Lua VM 的，而 Lua VM 是每 nginx worker 进程的，而 nginx 一般会配置多个
nginx worker 进程。

2. OpenResty 实现的 coroutine 和 ngx.thread 对象本身强制使用每请求的生命期，所以这些 Lua
对象不能跨请求传递和共享。（这种设计主要是为了方便资源管理方面的优化以及避免用户犯许多类型的低级错误。）

建议使用 lua-resty-lock 这样的库来实现不同请求之间的同步：

https://github.com/openresty/lua-resty-lock

Regards,
-agentzh

agentzh

Hello!

2015-01-15 17:00 GMT-08:00 yancl:
> 多个coroutine通过resty-lock同步数据没有问题,不过同一个coroutine通过resty-lock很难把自己block起来,并且通过其他coroutine来唤醒.
> 因为同一个coroutine
> block自己需要lock两次同一个key,但是unlock是对象级别的,其他的coroutine很难知道这个coroutine是什么,所以也就没有办法唤醒了.
>

luck 和 unlock 都不是对象级别的。resty.lock 对象只是一个代理（proxy），锁本身其实位于共享内存字典中，因此不同的
resty.lock 对象可以操作同一个锁。只要是同一个 key，在一个 worker 进程中 unlock 就可以促使另一个 worker
进程中的 lock 返回。

Regards,
-agentzh

hackers365

http://huoding.com/2012/09/28/174

火丁笔记这篇文章轮循本地共享内存的方式(即循环调用ngx.sleep)跟epoll这种事件响应的方式相比。性能上会有多大差距呢？

在 2015年1月16日星期五 UTC+8上午2:40:18，agentzh写道：

Hello!

2015-01-14 22:33 GMT-08:00 shi jingbo:
> 这几天一直在想能不能用lua模块的协程来实现长连接服务器。
>
> 使用coroutine.create创建一个协程。然后将thread句柄存到ngx.shared.dict中。挂起来。。当有pub数据的时候。从ngx.shared.dict中取出来协程的thread句柄。resume这个协程。返回数据。
>

不可行。这是因为

1. Lua 协程是每 Lua VM 的，而 Lua VM 是每 nginx worker 进程的，而 nginx 一般会配置多个
nginx worker 进程。

2. OpenResty 实现的 coroutine 和 ngx.thread 对象本身强制使用每请求的生命期，所以这些 Lua
对象不能跨请求传递和共享。（这种设计主要是为了方便资源管理方面的优化以及避免用户犯许多类型的低级错误。）

建议使用 lua-resty-lock 这样的库来实现不同请求之间的同步：

https://github.com/openresty/lua-resty-lock

Regards,
-agentzh

agentzh

Hello!

2015-01-15 17:47 GMT-08:00 shi jingbo:
> http://huoding.com/2012/09/28/174
> 火丁笔记这篇文章轮循本地共享内存的方式(即循环调用ngx.sleep)跟epoll这种事件响应的方式相比。性能上会有多大差距呢？
>

ngx.sleep 也是非阻塞的，底层也是使用 epoll_wait 实现，只是不是文件句柄本身的读写事件。

相比基于读写事件的模式，性能上的差别主要在于

1. 额外的 nginx 定时器自身的开销（一般是极小的），
2. 一点点额外的响应延时（这由 sleep 的最小时间区间决定，一般是毫秒级到百毫秒级，对于常规应用而言也足够小了）

在 nginx 的体系结构下，这种设计的优点是更方便在同一台机器上面按多个 CPU 核和多个 nginx worker
进程进行水平扩容，避免了跨越进程边界传递文件句柄和连接的复杂度。

Regards,
-agentzh

hackers365

好的。多谢春哥。

在 2015年1月16日星期五 UTC+8上午10:08:17，agentzh写道：

Hello!

2015-01-15 17:47 GMT-08:00 shi jingbo:
> http://huoding.com/2012/09/28/174
> 火丁笔记这篇文章轮循本地共享内存的方式(即循环调用ngx.sleep)跟epoll这种事件响应的方式相比。性能上会有多大差距呢？
>

ngx.sleep 也是非阻塞的，底层也是使用 epoll_wait 实现，只是不是文件句柄本身的读写事件。

相比基于读写事件的模式，性能上的差别主要在于

1. 额外的 nginx 定时器自身的开销（一般是极小的），
2. 一点点额外的响应延时（这由 sleep 的最小时间区间决定，一般是毫秒级到百毫秒级，对于常规应用而言也足够小了）

在 nginx 的体系结构下，这种设计的优点是更方便在同一台机器上面按多个 CPU 核和多个 nginx worker
进程进行水平扩容，避免了跨越进程边界传递文件句柄和连接的复杂度。

Regards,
-agentzh

kmoving

嗯,不过通过resty-lock实现类似redis blpop那样的操作目前我没有发现代码中如何做到.

我指的lock/unlock是对象级别的是说在获取一个resty-lock对象之后需要先调用lock(key),把key保存在对象中状态中(当然shmdict中会有一份用于同步).

然后unlock()就可以了,而不是unlock(key)这种,换句话说就是只有先lock,才能unlock:D

在 2015年1月16日星期五 UTC+8上午9:30:23，agentzh写道：

Hello!

2015-01-15 17:00 GMT-08:00 yancl:
> 多个coroutine通过resty-lock同步数据没有问题,不过同一个coroutine通过resty-lock很难把自己block起来,并且通过其他coroutine来唤醒.
> 因为同一个coroutine
> block自己需要lock两次同一个key,但是unlock是对象级别的,其他的coroutine很难知道这个coroutine是什么,所以也就没有办法唤醒了.
>

luck 和 unlock 都不是对象级别的。resty.lock 对象只是一个代理（proxy），锁本身其实位于共享内存字典中，因此不同的
resty.lock 对象可以操作同一个锁。只要是同一个 key，在一个 worker 进程中 unlock 就可以促使另一个 worker
进程中的 lock 返回。

Regards,
-agentzh