对于网络上面很重要的一部分内容——在线游戏来说，服务器的负载均衡是非常非常重要的。数以万计的用户同时在一个平台上进行游戏，那么数据的交换和传递，以及每一个用户的浏览速度，游戏质量都是有一定标准的。那么，我们就来以QQ的在线游戏为例，说一下这方面的负载均衡问题。
近日在与业内人士讨论时,提到QQ游戏的实现方式并不是我原来所想的那样,于是,今天又认真抓了一下QQ游戏的包,结果确如这位兄弟所言,QQ 游戏的架构与我当初所设想的那个架构相差确实不小｡下面,我重新给出QQ***在线的技术实现方案,并以此展开,谈谈大型在线系统中的负载均衡机制的设计｡
从QQ游戏的登录及游戏过程来看,QQ游戏中,也至少分为三类服务器｡它们是:
***层:登陆/账号服务器(Login Server),负责验证用户身份､向客户端传送初始信息,从QQ聊天软件的封包常识来看,这些初始信息可能包括"会话密钥"此类的信息,以后客户端与后续服务器的通信就使用此会话密钥进行身份验证和信息加密;
第二层:大厅服务器(估且这么叫吧, Game Hall Server),负责向客户端传递当前游戏中的所有房间信息,这些房间信息包括:各房间的连接IP,PORT,各房间的当前在线人数,房间名称等等｡
第三层:游戏逻辑服务器(Game Logic Server),负责处理房间逻辑及房间内的桌子逻辑｡
从静态的表述来看,以上的三层结构似乎与我以前写的那篇文章相比并没有太大的区别,事实上,重点是它的工作流程,QQ游戏的通信流程与我以前的设想可谓大相径庭,其设计思想和技术水平确实非常优秀｡具体来说,QQ游戏的通信过程是这样的:
1.由Client向Login Server发送账号及密码等登录消息,Login Server根据校验结果返回相应信息｡可以设想的是,如果Login Server通过了Client的验证,那么它会通知其它Game Hall Server或将通过验证的消息以及会话密钥放在Game Hall Server也可以取到的地方｡总之,Login Server与Game Hall Server之间是可以共享这个校验成功消息的｡一旦Client收到了Login Server返回成功校验的消息后,Login Server会主动断开与Client的连接,以腾出socket资源｡Login Server的IP信息,是存放在QQGame\config\QQSvrInfo.ini里的｡
2.Client收到Login Server的校验成功等消息后,开始根据事先选定的游戏大厅入口登录游戏大厅,各个游戏大厅Game Hall Server的IP及Port信息,是存放在QQGame\Dirconfig.ini里的｡Game Hall Server收到客户端Client的登录消息后,会根据一定的策略决定是否接受Client的登录,如果当前的Game Hall Server已经到了上限或暂时不能处理当前玩家登录消息,则由Game Hall Server发消息给Client,以让Client重定向到另外的Game Hall Server登录｡重定向的IP及端口信息,本地没有保存,是通过数据包或一定的算法得到的｡如果当前的Game Hall Server接受了该玩家的登录消息后,会向该Client发送房间目录信息,这些信息的内容我上面已经提到｡目录等消息发送完毕后,Game Hall Server即断开与Client的连接,以腾出socket资源｡在此后的时间里,Client每隔30分钟会重新连接Game Hall Server并向其索要***的房间目录信息及在线人数信息｡
3.Client根据列出的房间列表,选择某个房间进入游戏｡根据我的抓包结果分析,QQ游戏,并不是给每一个游戏房间都分配了一个单独的端口进行处理｡在QQ游戏里,有很多房间是共用的同一个IP和同一个端口｡比如,在斗地主一区,前50个房间,用的都是同一个IP和Port信息｡这意味着,这些房间,在QQ游戏的服务器上,事实上,可能是同一个程序在处理!!!QQ游戏房间的人数上限是400人,不难推算,QQ游戏单个服务器程序的用户承载量是2万,即QQ的一个游戏逻辑服务器程序最多可同时与2万个玩家保持TCP连接并保证游戏效率和品质,更重要的是,这样可以为腾讯省多少money 呀!!!哇哦!QQ确实很牛｡以2万的在线数还能保持这么好的游戏品质,确实不容易!QQ游戏的单个服务器程序,管理的不再只是逻辑意义上的单个房间,而可能是许多逻辑意义上的房间｡其实,对于服务器而言,它就是一个大区服务器或大区服务器的一部分,我们可以把它理解为一个庞大的游戏地图,它实现的也是分块处理｡而对于每一张桌子上的打牌逻辑,则是有一个统一的处理流程,50个房间的50*100张桌子全由这一个服务器程序进行处理(我不知道QQ游戏的具体打牌逻辑是如何设计的,我想很有可能也是分区域的,分块的)｡当然,以上这些只是服务器作的事,针对于客户端而言,客户端只是在表现上,将一个个房间单独罗列了出来,这样作,是为便于玩家进行游戏以及减少服务器的开销,把这个大区中的每400人放在一个集合内进行处理(比如聊天信息,"向400人广播"和"向2万人广播",这是完全不同的两个概念，那么具体的负载均衡问题我们也会分开来谈)｡
4.需要特别说明的一点｡进入QQ游戏房间后,直到点击某个位置坐下打开另一个程序界面,客户端的程序,没有再创建新的socket,而仍然使用原来大厅房间客户端跟游戏逻辑服务器交互用的socket｡也就是说,这是两个进程共用的同一个socket!不要小看这一点｡如果你在创建桌子客户端程序后又新建了一个新的socket与游戏逻辑服务器进行通信,那么由此带来的玩家进入､退出､逃跑等消息会带来非常麻烦的数据同步问题,俺在刚开始的时候就深受其害｡而一旦共用了同一个socket后,你如果退出桌子,服务器不涉及释放socket的问题,所以,这里就少了很多的数据同步问题｡关于多个进程如何共享同一个socket的问题,请去google以下内容:WSADuplicateSocket｡
以上便是我根据***的QQ游戏抓包结果分析得到的QQ游戏的通信流程,当然,这个流程更多的是客户端如何与服务器之间交互的,却没有涉及到服务器彼此之间是如何通信和作数据同步的｡关于服务器之间的通信流程,我们只能基于自己的经验和猜想,得出以下想法:
1.Login Server与Game Hall Server之前的通信问题｡Login Server是负责用户验证的,一旦验证通过之后,它要设法让Game Hall Server知道这个消息｡它们之前实现信息交流的途径,我想可能有这样几条:a. Login Server将通过验证的用户存放到临时数据库中;b. Login Server将验证通过的用户存放在内存中,当然,这个信息,应该是全局可访问的,就是说所有QQ的Game Hall Server都可以通过服务器之间的数据包通信去获得这样的信息｡
2.Game Hall Server的***房间目录信息的取得｡这个信息,是全局的,也就是整个游戏中,只保留一个目录｡它的信息来源,可以由底层的房间服务器逐级报上来,报给谁?我认为就如保存的全局登录列表一样,它报给保存全局登录列表的那个服务器或数据库｡
3.在QQ游戏中,同一类型的游戏,无法打开两上以上的游戏房间｡这个信息的判定,可以根据全局信息来判定｡
以上关于服务器之间如何通信的内容,均属于个人猜想,QQ到底怎么作的,恐怕只有等大家中的某一位进了腾讯之后才知道了｡呵呵｡不过,有一点是可以肯定的,在整个服务器架构中,应该有一个地方是专门保存了全局的登录玩家列表,只有这样才能保证玩家不会重复登录以及进入多个相同类型的房间｡
在前面的描述中,我曾经提到过一个问题:当登录当前Game Hall Server不成功时,QQ游戏服务器会选择让客户端重定向到另位的服务器去登录,事实上,QQ聊天服务器和MSN服务器的登录也是类似的,它也存在登录重定向问题｡
那么,这就引出了另外的问题,由谁来作这个策略选择?以及由谁来提供这样的选择资源?这样的处理,便是负责负载均衡的服务器的处理范围了｡由 QQ游戏的通信过程分析派生出来的针对负责均衡及***在线系统的更进一步讨论,将在下篇文章中继续｡
