回复：[openresty] Re: 使用 OpenResty 为基础的 game server 架构，请各位提意见

chenweidelphi

无法打开图片，架构图

------------------ 原始邮件 ------------------

发件人: Fei Ai <ai...@openresty.org>

发送时间: 2016年1月6日 11:23

收件人: openresty <openresty@googlegroups.com>

主题: Re: [openresty] Re: 使用 OpenResty 为基础的 game server 架构，请各位提意见

你的架构中组件的选择和我们场景下的选择几乎一样，看到你前面说希望 shared dict 改进是期望在清除掉过期key的时候能被外部 lua api 感知到吗？

2016-01-06 11:07 GMT+08:00 梅晓华 <ziv...@gmail.com>:

有幸已经用Openresty做了三个手游项目了，表现很好，性能超强，感谢agentzh。
推送目前用的Push Stream，感觉还凑合。
websocket一直在考察，也用Redis的pub/sub实现过，但觉得用Redis做推送并不是太好，轮询太密可能影响性能，太稀时效不行。
觉得还是等agentzh改进了share dict再用比较好，现在先用Push Stream凑合着。

个人不太建议使用beanstalkd，原因如下：
减少外部依赖，减少附加模块，降低运维成本。
防止突发事件产生密集队列，短时产生较大压力。

建筑队列这种，可以使用冷却的模式，而不是排队的模式，傲世以后应该大部分都是了。
其他需要计时排队的，也大部分可以改成记录结束时间点，客户端实时检查并调整显示，服务端根据结束时间判断是否可以执行操作。
我们包括体力增长，冷却，排队，都是这么实现的。

在 2013年10月28日星期一 UTC+8上午12:05:24，YuLei Liao写道：
我们是做手游的团队，最近一款游戏有不少实时性，正好看到 OpenResty 已经支持了 WebSockets，所以基于 OpenResty 设计了一个 game server 架构。

PS: 选择 OpenResty 的原因是我们前一款游戏也是用的 OpenResty，感觉很不错（虽然最后游戏没有挣到钱）。

整体架构图：

几点说明：

1. 因为现在版本的 cosocket 还不支持同时读写，所以我使用了这个补丁 https://github.com/aviramc/lua-nginx-module/tree/socket-changes

2. redis 是主数据库，日志类数据则存入 mysql，图里没有画出来

----

整个架构的重点有三部分：请求/响应模型，使用 redis 做消息转发，使用 job server 执行延时任务

1. 请求/响应模型

客户端通过 websockets 发送消息给服务端。每个消息都是 JSON 格式。其中包含 action 和 msgid 两个必须的参数。

- action 用于指示要调用服务端哪一个消息处理函数。例如 action = "" 就表示要调用服务端 UsersAction 模块的 authAction 方法。
- msgid 用于跟踪消息的执行结果，每一个从客户端发往服务端的消息都会带有一个 msgid（累加值）。当服务端的消息处理函数执行后，通过 websockets 发送消息到客户端，其中会包含请求消息中的 msgid。这样客户端就可以知道从服务端发来的消息是属于先前哪一个请求的反馈。这样模拟了 HTTP 的请求/响应模型，简化了客户端的代码实现。

2. 使用 redis 做消息转发

因为现在没有办法从外部取得一个线程的 cosocket 对象，所以也就无法直接向任意客户端发送消息。为了解决这个问题，我利用 redis 的 pub/sub 特性，实现了一个简单的消息中转机制。

每一个客户端连接到 OpenResty 后，就会创建一个子线程（ngx.thread.spawn）。这个子线程会创建一个 redis 连接，并 subscribe channel.id（连接成功的客户端都有一个自己的频道）。当有任何消息进入频道，这个子线程就通过主线程的 cosocket 对象将消息发往客户端（这里就需要前面提到的 cosocket 补丁）。

3. 使用 job server 执行延时任务

选择 beanstalkd 是因为有现成的 lua-resty-beanstalkd 模块，用起来省事儿。而且 beanstalkd 也支持延时消息，非常适合我们游戏中的需求。比如升级一个建筑物需要 10 分钟，那么我添加一个延时 10 分钟的消息到 beanstalkd 里就行了。

当一个消息倒计时结束时，就会由 worker 负责处理消息。worker 取得消息后，进行处理。如果处理后需要将更新后的数据发送到客户端，就通过 redis publish 命令来进行了。

----

整体架构还在开发，目前 1/2 都已经实现，初步测试效果还不错。下一步就是整合 beanstalkd。

由于第一次这样运用 OpenResty，所以还请各位多多提意见，看看有没有什么问题。

谢谢大家 :)

--