负载均衡－－大型在线系统实现的关键（服务器集群架构的设计与选择）

 

作者：sodme

网站：http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx

 

要了解此篇文章中引用的本人写的另一篇文章，请到以下地址：
http://blog.csdn.net/sodme/archive/2004/12/12/213995.aspx
以上的这篇文章是早在去年的时候写的了，当时正在作休闲平台，一直在想着如何实现一个可扩充的支持百万人在线的游戏平台，后来思路有了，就写了那篇总结。文章的意思，重点在于阐述一个百万级在线的系统是如何实施的，倒没真正认真地考察过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游戏的通信过程分析派生出来的针对负责均衡及百万级在线系统的更进一步讨论，将在下篇文章中继续。

在此，特别感谢网友tilly及某位不便透露姓名的网友的讨论，是你们让我决定认真再抓一次包探个究竟。

 

      在网络应用中，“负载均衡”已经不能算是什么新鲜话题了，从硬件到软件，也都有了很多的方法来实现负载均衡。我们这里讨论的负载均衡，并不是指依靠DNS转向或其它硬件设备等所作的负载均衡，而是指在应用层所作的负载均衡。

一般而言，只有在大型在线系统当中才有必要引入负载均衡，那么，多大的系统才能被称为大型系统呢？比如动辄同时在线数十万的网络游戏，比如同时在线数在10万以上的WEB应用，这些我们都可以理解为大型系统，这本身就是一个宽泛的概念。

设计再好的服务器程序，其单个程序所能承载的同时访问量也是有限的，面对一个庞大且日益增长的网络用户群，如何让我们的架构能适应未来海量用户访问，这 自然就牵涉到了负载均衡问题。支持百万级以上的大型在线系统，它的架构核心就是如何将“百万”这么大的一个同时在线量分摊到每个单独的服务器程序上去。真 正的逻辑处理应该是在这最终的底层的服务器程序（如QQ游戏平台的游戏房间服务器）上的，而在此之前所存在的那些服务器，都可以被称为“引路者”，它们的 作用就是将客户端一步步引导到这最终的负责真正逻辑的底层服务器上去，我们计算“百万级在线”所需要的服务器数量，也是首先考虑这底层的逻辑服务器单个可 承载的客户端连接量。

比如：按上篇我们所分析QQ游戏架构而言，假设每个服务器程序最高支持2W的用户在线（假设一台机子只运行一个 服务器程序），那么实现150万的在线量至少需要多少台服务器呢？如果算得简单一点的话，就应该是：150/2=75台。当然，这样算起来，可能并不能代 表真正的服务器数量，因为除了这底层的服务器外，还要包括登录/账号服务器以及大厅服务器。但是，由于登录/账号服务器和大厅服务器，它们与客户端的连接 都属于短连接（即：取得所需要信息后，客户端与服务器即断开连接），所以，客户端给这两类服务器带来的压力相比于长连接（即：客户端与服务器始终保持连 接）而言就要轻得多，它们的压力主要在处理瞬间的并发访问上。

“短连接”，是实现应用层负载均衡的基本手段！！！如果客户端要始终与登录/账号服务器以及大厅服务器保持连接，那么这样作的分层架构将是无意义的，这也没有办法从根本上解决用户量不断增长与服务器数量有限之间的矛盾。

当然，短连接之所以可以被使用并能维护正常的游戏逻辑，是因为在玩家看不到的地方，服务器与服务器之间进行了大量的数据同步操作。如果一个玩家没有登录 到登录服务器上去而是直接连接进了游戏房间服务器并试图进行游戏，那么，由于游戏房间服务器与大厅服务器和登录/账号服务器之间都会有针对于玩家登录的逻 辑维护，游戏房间服务器会检测出来该玩家之前并没有到登录服务器进行必要的账号验证工作，它便会将玩家踢下线。由此看来，各服务器之间的数据同步，又是实 现负载均衡的又一必要条件了。

服务器之间的数据同步问题，依据应用的不同，也会呈现不同的实现方案。比如，我们在处理玩家登录这个问 题上。我们首先可以向玩家开放一些默认的登录服务器（服务器的IP及PORT信息），当玩家连接到当前的登录服务器后，由该服务器首先判断自己同时连接的 玩家是不是超过了自定义的上限，如果是，由向与该服务器连接着的“登录服务器管理者”（一般是一个内部的服务器，不直接向玩家开放）申请仲裁，由“登录服 务器管理者”根据当前各登录服务器的负载情况选择一个新的服务器IP和PORT信息传给客户端，客户端收到这个IP和PORT信息之后重定向连接到这个新 的登录服务器上去，完成后续的登录验证过程。

这种方案的一个特点是，在面向玩家的一侧，会提供一个外部访问接口，而在服务器集群的内部，会提供一个“服务器管理者”及时记录各登录服务器的负载情况以便客户端需要重定向时根据策略选择一个新的登录接口给客户端。

采用分布式结构的好处是可以有效分摊整个系统的压力，但是，不足点就是对于全局信息的索引将会变得比较困难，因为每个单独的底层逻辑服务器上都只是存放 了自己这一个服务器上的用户数据，它没有办法查找到其它服务器上的用户数据。解决这个问题，简单一点的作法，就是在集群内部，由一个中介者，提供一个全局 的玩家列表。这个全局列表，根据需要，可以直接放在“服务器管理者”上，也可以存放在数据库中。

对于逻辑相对独立的应用，全局列表的 使用机会其实并不多，最主要的作用就是用来检测玩家是不是重复登录了。但如果有其它的某些应用，要使用这样的全局列表，就会使数据同步显得比较复杂。比 如，我们在超大无缝地图的MMORPG里，如果允许跨服操作(如跨服战斗、跨服交易等)的话，这时的数据同步将会变得异常复杂，也容易使处理逻辑出现不可 预测性。

我认为，对于休闲平台而言，QQ游戏的架构已经是比较合理的，也可以称之为休闲平台的标准架构了。那么，MMORPG一般的架构是什么样的呢？

MMORPG一般是把整个游戏分成若干个游戏世界组，每个组内其实就是一个单独的游戏世界。而不同的组之间，其数据皆是相互独立的，并不象QQ休闲平台 一样所有的用户都会有一个集中的数据存放点，MMORPG的游戏数据是按服务器组的不同而各自存放的。玩家在登录QQ游戏时，QQ游戏相关的服务器会自动 为玩家的登录进行负载均衡，选择相对不忙的服务器为其执行用户验证并最终让用户选择进入哪一个游戏房间。但是，玩家在登录MMORPG时，却没有这样的自 动负载均衡，一般是由玩家人为地去选择要进入哪一个服务器组，之所以这样，是因为各服务器组之间的数据是不相通的。其实，细致想来，MMORPG的服务器 架构思想与休闲平台的架构思想有异曲同工之妙，MMORPG的思想是：可以为玩家无限地开独立的游戏世界（即服务器组），以满足大型玩家在线；而休闲平台 的思想则是：可以为玩家无限地开游戏房间以满足大量玩家在线。这两种应用，可以无限开的都是“具有完整游戏性的游戏世界”，对于MMORPG而言，它的一 个完整的游戏地图就是一个整体的“游戏世界”，而对于休闲平台，它的一个游戏房间就可以描述为一个“游戏世界”。如果MMORPG作成了休闲平台那样的全 服皆通，也不是不可以，但随之而来的，就是要解决众多跨服问题，比如：好友、组队、帮派等等的问题，所有在传统MMORPG里所定义的这些玩家组织形式的 规则可能都会因为“全服皆通”而改变。

架构的选择是多样性的，确实没有一种可以称得上是最好的所谓的架构，适合于当前项目的，不一定就适合于另一个项目。针对于特定的应用，会灵活选用不同的架构。但有一点，是可以说的：不管你如何架构，你所要作的就是－－要以尽可能简单的方案实现尽可能的稳定、高效！