排队系统

原文：http://blog.codingnow.com/mt/mt-tb.cgi/341

说回排队系统。大家都说 MMO 里的排队系统是魔兽世界的首创。可是只要是有社会经验的人，一拍脑袋就能想出这个点子来。谁都知道，在大量人拥挤在一起想完成同一件事情时，排队遵守次序是提高整体效率的最佳方案。那么，为什么 MMO 发展了那么多年，只到 wow 才被用于玩家登陆？

理由只有两个：1. 问题（太多玩家同时登陆）不存在，不需要去做。 2. 做这样一个排队系统，有一定的技术难度，不容易做好。

29 号那天下午，天下的排队系统是启动了的。可是似乎不解决任何问题。反而大量不能进入游戏的玩家在排队系统中拥挤着，甚至导致了系统不稳定，进入游戏的玩家纷纷掉线。

到了 1 号，开发组似乎把排队系统关闭了。游戏服务器达到承载上限的时候，干脆拒绝任何新的连接。这个时候玩家看到的只是服务器没有回应。讽刺的是，这个时候，游戏服务器反而稳定下来，至少已进入游戏的玩家可以正常游戏了。

任何能弄清楚到底需要什么的项目，在工程上都是容易实现的。无非克服技术点而已。（反之，需求模糊的东西，就很难顺利完成。这也是 MMO 游戏业抄袭成风的根源。毕竟抄袭让我们知道该做些什么。）我相信排队系统终究可以完美实现。下面分析一下排队系统的需求，和技术难点。

让服务器组可以在短时间接纳大量的连接，并将暂时不能处理的连接分流。分流的连接必须保持住，而不能随意丢掉，避免这些断开的连接重新（人为）回来，再次造成冲击。

这里的难点其实在于，系统如何做这样的分流，让处理排队业务的部分不成为游戏逻辑处理业务的桎梏。btw, bigworld engine 还有一个难点，由于它设计之初的决定，通讯协议采取了 UDP 而没有使用 TCP ，所以保持连接更加困难。我并没有说使用 UDP 协议通讯有任何不好（对于 big world 的整体设计来说，采用 UDP 是正确的），只是这里的确造成了一定的技术困难。

以我有限的技术眼光，能开的药方还是从最近两年在忙的这摊子事中得到的。那就是：

1. 身份认证系统分离。参考我以前写的 多服务器的用户身份认证方案，身份认证系统可以单独想办法做成集群，处理大量并发请求。但由于每通过一次身份认证只能拿到一次性令牌，这样就在身份认证系统和游戏系统之间做了一个缓冲层。

2. 采用连接服务器和逻辑分离的设计。并且为一组服务器增加多个连接入口点。可参考：游戏服务器处理多个连接入口的方案。这样，即使游戏服务器组同时只能处理千级别的玩家，连接服务器组一样可以承受万级别的同时连接数。同时可能方便的留出特殊通道供内部人员使用。据说前两天，天下服务器拥挤的时候，我们自己的 QC 人员都没能登陆进游戏系统。更别说老板想进去看看游戏了 :) （我不赞同内部人员就能比外部玩家有更多的特权，实际上网易的游戏一直也是这么坚持的。但是维护和测试人员在测试期也挤不上游戏服务器就有点搞笑了）

3. 游戏系统尽量使用多进程流水线设计。参考：多进程的游戏服务器设计。把排队系统独立到一个进程里，放在连接服务器之后。在负载过高的时候，单独分配到一台物理机器上工作。游戏排队系统逻辑简单，并可以维持较低的通讯/心跳频率，所以单台机器处理几万逻辑连接（真正的海量 TCP 连接是在连接服务器上做的）是没有什么问题的。

这里，处理排队的进程，实际也担负了监控游戏服务器组的负载的任务。所以它可以在正确的时候放行排在前列的玩家。独立的进程使它不至于影响正常游戏的逻辑处理。这样一个子系统，我们的 engine 中被称为 watchdog ，代码不过几百行。这块设计在 去年底的那次演讲中也讲过了。不知道当时在场的朋友中有没有人关注。 :)

以上提到的诸点，并非在 big world 中全无。只是 engine 开发受制于人，又有些许沟通上的障碍。最终制约了我们自己的技术人员解决问题的粒度和速度。我想，若是欧美厂商购买了 big world ，能够用的更好吧。

现实是复杂的。没做到，没做好，并非我们的程序员不能也。

3 月 3 日补充：

这两天好几个天下组的同事找到我，给我讲这件事情的经过 :) 原来并不是排队系统没有做好。而是别的原因。（包括一些其它 bug ，服务器初期玩家过于拥挤在同一地点等）现在游戏服务器已经很流畅了。