问一个redis事务兼开房间逻辑的问题

fatfatson

感觉redis的事务就是个批处理而已啊。。。

而且说2.6以后可以执行lua脚本了，那原来的事务就更没啥用处了？

第一次用nginx+lua，搞个开房间的逻辑，在加入房间前检查是否人满的判断上，做得很蛋疼

因为可能2个人同时进一个快满的房间，但他们的请求在不同的进程处理，这就会有并发问题

因为“检查人数是不是满了；然后把自己加进去”这个逻辑必须是原子的

如果不用redis的内嵌lua脚本搞定这问题，纯在nginx端解决的话，就变成这样：

1.客户端A、B分别连上它们的服务端websocket:WA、WB

2.A建主，B加入，则WB收到请求时，不能自己去操作redis里由list表示的房间，因为如果这样就会有WC、WD同时操作，并发冲突的问题

3.于是只好WB通过redis给WA发消息，WA作为主机，是惟一操作房间数据的人才不会有冲突，然后WA把结果发给WB，WB再发给客户端B

4.在这种模式下，WB成了一个中转站。。而且凭空多了好多交互协议。。

难道用nginx这种分布式宿主，就意味着大量的内部捣腾把数据转来转去吗。。。

doujiang24

还是在 redis 里搞合适吧

WATCH is used to provide a check-and-set (CAS) behavior to Redis transactions

http://redis.io/topics/transactions

在 2014年2月28日下午3:15，小冶 <fatf...@gmail.com>写道：

感觉redis的事务就是个批处理而已啊。。。
而且说2.6以后可以执行lua脚本了，那原来的事务就更没啥用处了？

第一次用nginx+lua，搞个开房间的逻辑，在加入房间前检查是否人满的判断上，做得很蛋疼
因为可能2个人同时进一个快满的房间，但他们的请求在不同的进程处理，这就会有并发问题
因为“检查人数是不是满了；然后把自己加进去”这个逻辑必须是原子的

如果不用redis的内嵌lua脚本搞定这问题，纯在nginx端解决的话，就变成这样：
1.客户端A、B分别连上它们的服务端websocket:WA、WB
2.A建主，B加入，则WB收到请求时，不能自己去操作redis里由list表示的房间，因为如果这样就会有WC、WD同时操作，并发冲突的问题
3.于是只好WB通过redis给WA发消息，WA作为主机，是惟一操作房间数据的人才不会有冲突，然后WA把结果发给WB，WB再发给客户端B

4.在这种模式下，WB成了一个中转站。。而且凭空多了好多交互协议。。

难道用nginx这种分布式宿主，就意味着大量的内部捣腾把数据转来转去吗。。。

--

fatfatson

谢谢提醒！watch我也看了，就是觉得redis的事务太弱了，完全只是个批处理而已。现在我是用eval指令去执行lua脚本搞定的，相比事务，lua脚本里还能搞if else各种逻辑，方便多了。

但是，又发现另外一个问题：

在nginx reload后，原有websocket里打开的redis connection是不是不能用了？

因为我一边写代码一边调，经常会修改过后就reload一下，这时websocket并没有断，但很多redis相关逻辑不正常了

如退出时本会用redis_db:del(house_key)把房间清了，但实际结果是有时候清了有时候没清，还是不固定的！

检查这个del命令的返回值，也没有发生错误。太奇怪了！

在 2014年2月28日星期五UTC+8下午4时48分29秒，doujiang写道：

还是在 redis 里搞合适吧

WATCH is used to provide a check-and-set (CAS) behavior to Redis transactions

http://redis.io/topics/transactions

在 2014年2月28日下午3:15，小冶 <fatf...@gmail.com>写道：

感觉redis的事务就是个批处理而已啊。。。
而且说2.6以后可以执行lua脚本了，那原来的事务就更没啥用处了？

第一次用nginx+lua，搞个开房间的逻辑，在加入房间前检查是否人满的判断上，做得很蛋疼
因为可能2个人同时进一个快满的房间，但他们的请求在不同的进程处理，这就会有并发问题
因为“检查人数是不是满了；然后把自己加进去”这个逻辑必须是原子的

如果不用redis的内嵌lua脚本搞定这问题，纯在nginx端解决的话，就变成这样：
1.客户端A、B分别连上它们的服务端websocket:WA、WB
2.A建主，B加入，则WB收到请求时，不能自己去操作redis里由list表示的房间，因为如果这样就会有WC、WD同时操作，并发冲突的问题
3.于是只好WB通过redis给WA发消息，WA作为主机，是惟一操作房间数据的人才不会有冲突，然后WA把结果发给WB，WB再发给客户端B

4.在这种模式下，WB成了一个中转站。。而且凭空多了好多交互协议。。

难道用nginx这种分布式宿主，就意味着大量的内部捣腾把数据转来转去吗。。。

--

agentzh

Hello!

2014-02-28 1:16 GMT-08:00 小冶:
> 但是，又发现另外一个问题：
> 在nginx reload后，原有websocket里打开的redis connection是不是不能用了？
> 因为我一边写代码一边调，经常会修改过后就reload一下，这时websocket并没有断，但很多redis相关逻辑不正常了

这是 NGINX 的一个重要的特性，即优雅退出。当你 reload 或者 quit 时，NGINX
当前正在处理的请求对应的连接并不会立即断开，而会等这些连接都当前请求结束后才退出，以免影响用户。你在开发时可以在 nginx.conf
里配置 master_process off，此时会禁用优雅退出功能。

Regards,
-agentzh

for5million

这个建议使用计数器，incr，decr吧，这个是原子的操作

当然lua脚本还是不错的，具体实现还请发个实现的代码例子，学习一下谢谢。

for5million

发件人： 小冶

发送时间： 2014-02-28 17:16

收件人： openresty

主题： Re: [openresty] 问一个redis事务兼开房间逻辑的问题

但是，又发现另外一个问题：

在nginx reload后，原有websocket里打开的redis connection是不是不能用了？

因为我一边写代码一边调，经常会修改过后就reload一下，这时websocket并没有断，但很多redis相关逻辑不正常了

如退出时本会用redis_db:del(house_key)把房间清了，但实际结果是有时候清了有时候没清，还是不固定的！

检查这个del命令的返回值，也没有发生错误。太奇怪了！

在 2014年2月28日星期五UTC+8下午4时48分29秒，doujiang写道：

还是在 redis 里搞合适吧

WATCH is used to provide a check-and-set (CAS) behavior to Redis transactions

http://redis.io/topics/transactions

在 2014年2月28日下午3:15，小冶 <fatf...@gmail.com>写道：

感觉redis的事务就是个批处理而已啊。。。

而且说2.6以后可以执行lua脚本了，那原来的事务就更没啥用处了？

第一次用nginx+lua，搞个开房间的逻辑，在加入房间前检查是否人满的判断上，做得很蛋疼
因为可能2个人同时进一个快满的房间，但他们的请求在不同的进程处理，这就会有并发问题

因为“检查人数是不是满了；然后把自己加进去”这个逻辑必须是原子的

如果不用redis的内嵌lua脚本搞定这问题，纯在nginx端解决的话，就变成这样：

1.客户端A、B分别连上它们的服务端websocket:WA、WB

2.A建主，B加入，则WB收到请求时，不能自己去操作redis里由list表示的房间，因为如果这样就会有WC、WD同时操作，并发冲突的问题

3.于是只好WB通过redis给WA发消息，WA作为主机，是惟一操作房间数据的人才不会有冲突，然后WA把结果发给WB，WB再发给客户端B

4.在这种模式下，WB成了一个中转站。。而且凭空多了好多交互协议。。

难道用nginx这种分布式宿主，就意味着大量的内部捣腾把数据转来转去吗。。。

--