服务器的分布式部署

两周前使用redis-benchmark测了一下silly的并发请求响应速度， 开1000个客户端， 平均大概每秒能响应6W个请求。
但是这些请求仅仅是PING/PONG协议，也就是说这基本上就是纯网络I/O的性能，如果考虑到逻辑处理、数据压缩、加密、解密等时间， 可能一个silly都不一定能够撑得起5000人的访问量。

所以最近两周除了在研究redis之外， 就是在研究怎么给silly增加cluster支持，以便可以将计算分摊到不同的计算机上来降低客户端的请求的响应延迟，silly应该怎么增加对cluster的支持。

直到昨天下班的路上我才想通，其实对于silly的模型来讲，他的任务应该相当的KISS，仅仅只是用coroutine的方式来处理数据即可。分布式功能应该在应用层实现，并不需要silly做额外的支持。

首先给定这样一个命题：
所有玩家在同一张地图上游戏，一台物理server能支持5000人的并发量，那么如何才能支撑百万级的玩家在同一张地图上游戏。

首先将服务器分为auth_server, channel_server, scene_server, ctrl_server这四种服务器。

整个服务器集群由一个auth_server、一个ctrl_server、若干channel_server、若干scene_server组成。

所有server在启动时主动向ctrl_server建立一条socket链接， 以便可以定时向ctrl_server汇报和查询状态（如当前负载情况等），另外在停服时可以直接操作ctrl_server， 然后ctrl_server通过建立的socket连接来通知所有server停服，这样可以避免人工操作出现的各种差错。

auth_server服务器的作用仅仅用来做用户认证，和负载均衡。在客户端用户登陆验证正确后，auth_server根据向ctrl_server查询到的所有channel_server的负载状态，挑选出各适的channel_server服务器的ip及端口号，然后将其和临时通行证一并发给客户端。 当客户端得到临时通行证和相应的channel_server地址/端口号之后，随即与auth_server断开连接以便auth_server可以有更多的资源处理其他客户的认证请求。

每一个scene_server管理地图上的一部分场景，并用来处理这块游戏场景内的游戏逻辑，这样所有的scene_server组合起来的集群就是一张大的地图，和完整的游戏逻辑。

每一个channel_server与所有的scene_server相连接，并将每一个scene_server负责的区域信息与此scene_server的socket连接做hash映射，每一个客户端只会与一个channel_server相连接。

channel_server所做的事仅仅是根据当前客户端的人物的位置，自行转发到不同的scene_server服务器中去， 具体逻辑由scene_server进行处理。 当客户端在地图中行走时，如果channel_server判断超出了当前的scene_server的范围， 则根据客户端的当前位置从映射表中查出当前区域信息所在的scene_server的socket链接， 并将数据转到的新的scene_server服务器中去。

这样看来只需要一个常量的代价（数据被中转一次，hash查询），channel_server和scene_server几乎可以无限扩展，那么整个逻辑的响应速度也会是常量。惟一受限的将会是auth_server的响应速度。

ps.集群的思想参考自redis的集群，由于我并没有参与过RPG游戏开发，因此上述观点均为理论推测。