文档介绍：[zz]游戏服务器架构探讨（上）.txt今天心情不好。我只有四句话想说。包括这句和前面的两 句。我的话说完了对付凶恶的人，就要比他更凶恶；对付卑鄙的人，就要比他更卑鄙没有情 人味，哪来人情味 拿什么整死你，我的爱人。收银员说：没零钱了，找你，验证成功则进入了该游戏世界。但是，如果玩家想要切换游 戏世界，他只能先退出当前游戏世界，然后进入新的游戏世界重新进行帐号验证。
早期的游戏大都采用的是这种结构，有些游戏在实现时采用了一些技术手段使得在切换游戏 服时不需要再次验证帐号，但整体结构还是未做改变。
该结构存在一个服务器资源配置的问题。因为登录服处理的逻辑相对来说比较简单，就是将 玩家提交的帐号和密码送到数据库进行验证，和生成会话密钥发送给游戏服和客户端，操作 完成后连接就会立即断开，而且玩家在以后的游戏过程中不会再与登录服打任何交道。这样 处理短连接的过程使得系统在大多数情况下都是比较空闲的，但是在某些时候，由于请求比 较密集，比如开新服的时候，登录服的负载又会比较大，甚至会处理不过来。
另外在实际的游戏运营中，有些游戏世界很火爆，而有些游戏世界却非常冷清，甚至没有多 少人玩的情况也是很常见的。所以，我们能否更合理地配置登录服资源，使得整个大区内的
登录服可以共享就成了下一步改进的目标。
服务器结构探讨一登录服的负载均衡
回想一下我们在玩wow时的操作流程：运行wow. exe进入游戏后，首先就会要求我们输入用 户名和密码进行验证，验证成功后才会出来游戏世界列表，之后是排队进入游戏世界，开始 游戏...
可以看到跟前面的描述有个很明显的不同，那就是要先验证帐号再选择游戏世界。这种结构 也就使得登录服不是固定配备给个游戏世界，而是全区共有的。
我们可以试着从实际需求的角度来考虑一下这个问题。正如我们之前所描述过的那样，登录 服在大多数情况下都是比较空闲的，也许我们的一个拥有20个游戏世界的大区仅仅使用10 台或更少的登录服即可满足需求。而当在开新区的时候，或许要配备40台登录服才能应付那 如潮水般涌入的玩家登录请求。所以，登录服在设计上应该能满足这种动态增删的需求，我 们可以在任何时候为大区增加或减少登录服的部署。
当然，在这里也不会存在要求添加太多登录服的情况。还是拿开新区的情况来说，即使新增 加登录服满足了玩家登录的请求，游戏世界服的承载能力依然有限，玩家一样只能在排队系 统中等待，或者是进入到游戏世界中导致大家都卡。
另外，当我们在增加或移除登录服的时候不应该需要对游戏世界服有所改动，也不会要求重 启世界服，当然也不应该要求客户端有什么更新或者修改，一切都是在背后自动完成。
最后，有关数据持久化的问题也在这里考虑一下。一般来说，使用现有的商业数据库系统比 自己手工技术先进要明智得多。我们需要持久化的数据有玩家的帐号及密码，玩家创建的角 色相关信息，另外还有一些游戏世界全局共有数据也需要持久化。
好了，需求已经提出来了，现在来考虑如何将其实现。
对于负载均衡来说，已有了成熟的解决方案。一般最常用，也最简单部署的应该是基于DNS 的负载均衡系统了，其通过在DNS中为一个域名配置多个IP地址来实现。最新的DNS服务已 实现了根据服务器系统状态来实现的动态负载均衡，也就是实现了真正意义上的负载均衡， 这样也就有效地解决了当某台登