游戏服务器架构

Posted 2020-11-21 raindrop

 http://blog.51cto.com/rangercyh/1673922

https://zhuanlan.zhihu.com/p/26252412

 

登录服务器

 

只是负责验证用户名和密码，验证之后返回token，token是有有效时间的，在有效时间内，并没有保持连接的必要，所以，这里的RequestResponse可以做成短连接（http请求响应模式），提升并发。


如果超过了有效时间还没有进入游戏，令牌失效，在登录验证时将被踢回重新获取令牌。


登录服务器和网关之间需要有一个固定的连接传递新生成的令牌。

 

 

网关服务器(中心服务器)

 

负责所有客户端的长连接的维护。每一个连接都会对应一个session，只有通过登录验证的session才能将报文传入游戏服务器群的消息队列中。没验证登录的session需要发送之前从登录服务器获得的token来验证登录。


token会和账号绑定，一旦验证通过，网关将通知游戏服务器新玩家进入，游戏服务器从数据库读取玩家的角色列表数据，再通过网关发送给客户端。


上述的操作可能是游戏中最耗时的一步。所以可能增加的策略是异步推送，多人排队等。

游戏服务器

玩家确实进入游戏之后，每一个玩家都会有一个对应的Agent来维护。包括玩家的即时游戏数据，存档游戏数据。所有与游戏内容相关的都称为游戏服务器。这部分的工作量将是游戏开发过程中最大的。


主要就是从网关发送的消息队列中不断读取消息，然后进行处理。对于游戏来说，整个世界是在一个循环体中的，所以首先肯定会有一个大的世界循环体，然后是每个Agent的存在更新。鉴于现在的网游都没有存档的设计，全是数据统一入库的，所以，Agent还需要负责玩家数据的持久化。我只打算做定期持久化，如果像王者那样即时持久化，需要的代码量和代码的耦合让人不太舒服。




需要的类库
服务器内部的通讯，消息队列，因为没有什么需要持久化稳定之类的需求，速度可以提上来，ZeroMQ是极好的。
数据库还是继续使用mysql