类似于QQ游戏百万人同时在线的服务器架构实现

鼯鼠

本文作者：sodme　本文出处：http://blog.csdn.net/sodme
版权声明：本文可以不经作者同意任意转载，但转载时烦请保留文章开始前两行的版权、作者及出处信息。

　　QQ游戏于前几日终于突破了百万人同时在线的关口，向着更为远大的目标迈进，这让其它众多传统的棋牌休闲游戏平台黯然失色，相比之下，联众似乎已经根本不是QQ的对手，因为QQ除了这100万的游戏在线人数外，它还拥有3亿多的注册量（当然很多是重复注册的）以及QQ聊天软件900万的同时在线率，我们已经可以预见未来由QQ构建起来的强大棋牌休闲游戏帝国。
　　那么，在技术上，QQ游戏到底是如何实现百万人同时在线并保持游戏高效率的呢？
　　事实上，针对于任何单一的网络服务器程序，其可承受的同时连接数目是有理论峰值的，通过C＋＋中对TSocket的定义类型：word，我们可以判定这个连接理论峰值是65535，也就是说，你的单个服务器程序，最多可以承受6万多的用户同时连接。但是，在实际应用中，能达到一万人的同时连接并能保证正常的数据交换已经是很不容易了，通常这个值都在2000到5000之间，据说QQ的单台服务器同时连接数目也就是在这个值这间。
　　如果要实现2000到5000用户的单服务器同时在线，是不难的。在windows下，比较成熟的技术是采用IOCP－－完成端口。与完成端口相关的资料在网上和CSDN论坛里有很多，感兴趣的朋友可以自己搜索一下。只要运用得当，一个完成端口服务器是完全可以达到2K到5K的同时在线量的。但，5K这样的数值离百万这样的数值实在相差太大了，所以，百万人的同时在线是单台服务器肯定无法实现的。
　　要实现百万人同时在线，首先要实现一个比较完善的完成端口服务器模型，这个模型要求至少可以承载2K到5K的同时在线率（当然，如果你MONEY多，你也可以只开发出最多允许100人在线的服务器）。在构建好了基本的完成端口服务器之后，就是有关服务器组的架构设计了。之所以说这是一个服务器组，是因为它绝不仅仅只是一台服务器，也绝不仅仅是只有一种类型的服务器。
　　简单地说，实现百万人同时在线的服务器模型应该是：登陆服务器＋大厅服务器＋房间服务器。当然，也可以是其它的模型，但其基本的思想是一样的。下面，我将逐一介绍这三类服务器的各自作用。
　　登陆服务器：一般情况下，我们会向玩家开放若干个公开的登陆服务器，就如QQ登陆时让你选择的从哪个QQ游戏服务器登陆一样，QQ登陆时让玩家选择的六个服务器入口实际上就是登陆服务器。登陆服务器主要完成负载平衡的作用。详细点说就是，在登陆服务器的背后，有N个大厅服务器，登陆服务器只是用于为当前的客户端连接选择其下一步应该连接到哪个大厅服务器，当登陆服务器为当前的客户端连接选择了一个合适的大厅服务器后，客户端开始根据登陆服务器提供的信息连接到相应的大厅上去，同时客户端断开与登陆服务器的连接，为其他玩家客户端连接登陆服务器腾出套接字资源。在设计登陆服务器时，至少应该有以下功能：N个大厅服务器的每一个大厅服务器都要与所有的登陆服务器保持连接，并实时地把本大厅服务器当前的同时在线人数通知给各个登陆服务器，这其中包括：用户进入时的同时在线人数增加信息以及用户退出时的同时在线人数减少信息。这里的各个大厅服务器同时在线人数信息就是登陆服务器为客户端选择某个大厅让其登陆的依据。举例来说，玩家A通过登陆服务器1连接到登陆服务器，登陆服务器开始为当前玩家在众多的大厅服务器中根据哪一个大厅服务器人数比较少来选择一个大厅，同时把这个大厅的连接IP和端口发给客户端，客户端收到这个IP和端口信息后，根据这个信息连接到此大厅，同时，客户端断开与登陆服务器之间的连接，这便是用户登陆过程中，在登陆服务器这一块的处理流程。
　　大厅服务器：大厅服务器，是普通玩家看不到的服务器，它的连接IP和端口信息是登陆服务器通知给客户端的。也就是说，在QQ游戏的本地文件中，具体的大厅服务器连接IP和端口信息是没有保存的。大厅服务器的主要作用是向玩家发送游戏房间列表信息，这些信息包括：每个游戏房间的类型，名称，在线人数，连接地址以及其它如游戏帮助文件URL的信息。从界面上看的话，大厅服务器就是我们输入用户名和密码并校验通过后进入的游戏房间列表界面。大厅服务器，主要有以下功能：一是向当前玩家广播各个游戏房间在线人数信息；二是提供游戏的版本以及下载地址信息；三是提供各个游戏房间服务器的连接IP和端口信息；四是提供游戏帮助的URL信息；五是提供其它游戏辅助功能。但在这众多的功能中，有一点是最为核心的，即：为玩家提供进入具体的游戏房间的通道，让玩家顺利进入其欲进入的游戏房间。玩家根据各个游戏房间在线人数，判定自己进入哪一个房间，然后双击服务器列表中的某个游戏房间后玩家开始进入游戏房间服务器。
　　游戏房间服务器：游戏房间服务器，具体地说就是如“斗地主1”，“斗地主2”这样的游戏房间。游戏房间服务器才是具体的负责执行游戏相关逻辑的服务器。这样的游戏逻辑分为两大类：一类是通用的游戏房间逻辑，如：进入房间，离开房间，进入桌子，离开桌子以及在房间内说话等；第二类是游戏桌子逻辑，这个就是各种不同类型游戏的主要区别之处了，比如斗地主中的叫地主或不叫地主的逻辑等，当然，游戏桌子逻辑里也包括有通用的各个游戏里都存在的游戏逻辑，比如在桌子内说话等。总之，游戏房间服务器才是真正负责执行游戏具体逻辑的服务器。
　　这里提到的三类服务器，我均采用的是完成端口模型，每个服务器最多连接数目是5000人，但是，我在游戏房间服务器上作了逻辑层的限定，最多只允许300人同时在线。其他两个服务器仍然允许最多5000人的同时在线。如果按照这样的结构来设计，那么要实现百万人的同时在线就应该是这样：首先是大厅，1000000/5000＝200。也就是说，至少要200台大厅服务器，但通常情况下，考虑到实际使用时服务器的处理能力和负载情况，应该至少准备250台左右的大厅服务器程序。另外，具体的各种类型的游戏房间服务器需要多少，就要根据当前玩各种类型游戏的玩家数目分别计算了，比如斗地主最多是十万人同时在线，每台服务器最多允许300人同时在线，那么需要的斗地主服务器数目就应该不少于：100000/300=333，准备得充分一点，就要准备350台斗地主服务器。
　　除正常的玩家连接外，还要考虑到：
　　对于登陆服务器，会有250台大厅服务器连接到每个登陆服务器上，这是始终都要保持的连接；
　　而对于大厅服务器而言，如果仅仅有斗地主这一类的服务器，就要有350多个连接与各个大厅服务器始终保持着。所以从这一点看，我的结构在某些方面还存在着需要改进的地方，但核心思想是：尽快地提供用户登陆的速度，尽可能方便地让玩家进入游戏中。

timiil 发表于2004-12-15 20:22:00 IP: 211.162.241.*为什么要区分“大厅服务器”和“游戏房间服务器”呢？无端增加了网络连接损耗； “大厅”终日无所事事（负载轻），而“房间”则忙到晕 （因为要负责游戏逻辑、进行运算、分派消息。。。），
然则就算一个“大厅”能容5000人，而一台“房间”服务器只能负责500人，那么就出现了一个“大厅”需要拖动十个“房间”的情况了。既然如此，何不把二者业务统一放在一台服务器上算了，软件效率提高不小，系统架构也简单了许多。

BTW, 个人感觉联众比QQ要好得多。。。更不敢苟同仁兄所言。。。

sodme 发表于2004-12-17 12:54:00 IP: 218.88.36.*一个大厅拖十个房间，这个数字已经是很小的了。再者，我这里提到的架构是一种网状架构，并不是纯粹的层次型架构，并不是说通过只有通过大厅1才能到达房间1，通过大厅2也是同样可以到达房间1的，同一坐位上的两个玩家，他们很可能是通过不同的大厅连接进入的。大厅只是提供了一个通道的作用，我认为这样的负担设置是很合理的。最底层的房间服务器只维护房间逻辑和桌子逻辑。

你说联众比QQ好，那是你的看法。数字才是最有说服力的，如果联众不是卖给了韩国，说不定他还没有现在发展得好，为什么联众里面也越来越多地融入了诸如虚拟形象这样的东西，这还不是跟QQ一样尊从韩国风格？

QQ游戏之所以这么火爆，一是在于它刚推出来时，一改当时市面上棋牌游戏的一贯烂界面，把界面作得很精致，让QQ一族有耳目一新之感；而另外一点，QQ通过游戏这种方式，让它的聊天软件用户在一个更广泛的平台上去展示自己，并可以同时跟更多的人进行沟通和交流。形象地说，QQ聊天本身是一对一的，而QQ游戏则已经是一对多的了。这种交流方式的本质变化是吸引QQ用户喜爱QQ游戏的一个重要原因，反过来，QQ游戏又进一步地对QQ聊天软件进行了补充，二者是互补的。而联众有什么？它除了占一个先天之机，其它的有哪点能跟QQ相比？联众的致使缺点就在于，单纯地为了游戏而游戏，可扩展性和延伸性实在太小，其实，在早期，它完全可以依靠游戏社区去发展自己的P2P产品，这样可能也会达到跟QQ不相上下的成果，但，世界上没有如果。

其它的不用多说，看看QQ游戏的同时在线和联众的同时在线就知道全部了，而且，我还得告诉你一个数据：QQ注册量是3亿(其中肯定有很多重复注册，这是正常的)，而QQ聊天软件的同时在线最高是900，QQ游戏现在才刚刚达到100万人同时在线，它的前景还非常广阔。当然，你有保留自己观点的权利。

timiil 发表于2004-12-17 13:54:00 IP: 61.144.81.*分层越多，逻辑越复杂，网络带宽的损耗、数据包的转发也越多。 这里讨论的层，指的是物理服务器。 而站在COM+的立场看，固然需要把大厅逻辑和房间逻辑部署在分别两个Assembly中了，只不过老兄要这两个Assembly分别部署在两台硬件服务器上，才令我不解。

联众N年前就推出了一个IM的附带工具，然问津者乏，才无了音讯。这样的比较对联众不大公平。 QQ只不过是因为本身用户数量大，才有所谓“百万在线”的效果。 就像因为Windows的用户多，所以NotePad是最多人用的编辑器。。。这样与NotePad有多强大、有多猛又有什么关系呢？

我最喜欢下中国象棋，联众起码在棋谱功能、等级等多方面完善一些。另外，从程序严谨性而言，联众的客户端可以Anti SoftICE, 有一些放外挂的措施， 从程序员的角度看，这个客户端的开发者还是很有深度的。

sodme 发表于2004-12-17 14:45:00 IP: 218.88.36.*呵呵。

联众的那个IM我知道，但是，他没有能象QQ聊天整合QQ游戏一样，把联众IM很好地与联众游戏整合起来，作的深度还远远不足。

联众在诸如比赛活动举办这方面，我还是比较欣赏的。但时势造英雄，QQ还是很好地抓住了时机，反超联众。

至于说程序技术方面，我觉得这个就不比了吧，QQ的数据包加密也算是作得比较好的了，呵呵。

Fyter 发表于2004-12-19 00:51:00 IP: 218.18.124.*我QQ7985850
我和朋友是开发棋牌游戏的，对于这个行业来说，我们的服务器结构和Sodme说的架构是相同的，但是我们比QQ，联众更出色一些。

QQ比联众的服务器优秀，联众很多游戏（房间）服务器都只有几百人封顶。QQ游戏，中游的都可以3K或4K左右。

广东地区中游（中国游戏中心）有很多人玩，但是他并不受大众喜欢。也有30万左右同时在线，中国第三。

鼯鼠

sodme 发表于2004-12-19 15:06:00 IP: 221.237.140.* 呵呵，Fyter，你们的游戏现在公开测试了吗？方不方便在QQ上给个网址。
lovefox 发表于2005-01-05 14:05:00 IP: 218.5.7.* to sodme：
你的完成端口用什么编程工具来实现的啊。有用delphi的么？
此外，就你的架构而言，你的游戏逻辑是否采用接口模式，用dll来实现逻辑的封装，以及后继的更新啊
FB2004 发表于2005-01-10 03:18:00 IP: 218.59.26.* 文中好像有一处错误，不知对不对，因为我并不是做这个的，不敢确定：
socket的port数是只有64k，还要保留一些，但这与连接数无关，比如web server，所有的客户端都是连到port 80上的。即便只用一个port，这个方面的连接数都是无限的，当然别的方面有瓶颈限制。
@pple 发表于2005-02-02 00:41:00 IP: 222.92.14.* HI,看到你的BLOG很感兴趣,我想你也是做棋牌网络游戏的,咱们应该算是同道中人,希望可以联系多多交流,我的MSN就是那个MAIL了,或者直接给我MAIL告诉我你的线上联系方式.
MAIL:usl_liuquan@hotmail.com
aben456 发表于2005-02-02 11:01:00 IP: 202.104.96.* 正在做这类游戏，希望广大爱好者共同切磋，共同进步！
R_YIKO 发表于2005-02-21 22:03:00 IP: 61.146.0.* 学习中...
specially 发表于2005-02-22 11:01:00 IP: 203.187.170.* 如果用户登陆时，使用web login,也就是用户登陆的检验由网站来负责，登陆成功后，直接引导用户进入大厅服务器，负载均衡由硬件负责，这样的架构怎么样？有什么利弊吗？
sodme 发表于2005-03-01 15:58:00 IP: 211.167.58.* 如果采用我上面说的这种模式进行的话，事实上，已经不用太担心登陆服务器的效率问题了，也没必要再用weblogin了。当然，如果你使用web login登陆也可以，不过，web login也要能实现大厅服务器的负载均衡，我不知道这种状态下是如何作的。
excelmaster 发表于2005-03-02 18:48:00 IP: 218.24.186.* 同意..不过最好能把数据库服务器.计费服务器..聊天服务器分离出来..


sodme 发表于2005-03-28 15:18:00 IP: 211.167.58.* 补：关于web login方式时的负载均衡问题

近段时间看了一下市面上的一些网游，其中的在线更新模块，在实现时，采用的是这样的方法：向外提供一个域名，然后将此域名解析到不同的IP上，这样不同的客户端在下载时就会从不同的服务器上下载自己的更新文件，从而实现负载均衡。看看网易的几个游戏吧，采用的是这样的方法。

sodme 发表于2005-04-13 10:54:00 IP: 211.167.58.* 更正一下：socket 的创建数目，上限不是65535，而是没有具体的上限数字。按windows网络编程第2版所言，这个上限值受机器配置影响。在此书上第6章，其列出的最高测试是5W个连接，但这并非理论的最高值。
QQ游戏开发人员 发表于2005-06-12 13:18:00 IP: 61.186.252.* 呵呵，我曾经参与过QQ游戏的服务器端的设计，我来做几点说明吧
1。qq游戏server是建立在linux上（虽然后来也做了windows版本的server，但只是为了内部开发调试所用）
2。qq游戏server的架构基本并不是如sodme所分析的那样，而timiil 的理解和看法基本上是对的，与qq游戏server架构基本接近。
3。关于qq游戏server与联众游戏server谁强谁弱，我只简单比较一下。两者架构体系不一样，但qq游戏server在我看来应该要略胜一筹的，仅仅就一点来说，qq游戏server自正式运营来很少发生down机，这一点是联众server无法相比的。qq游戏client端的界面，以及某些创意也比联众游戏要好，但联众游戏的程序它的在游戏功能上要比qq游戏强一些。
大宝(sodme) 发表于2005-06-12 21:23:00 IP: TrackBack来自《负载均衡－－大型在线系统实现的关键（再谈QQ游戏百万人在线的技术实现）》：

Ping Back来自：blog.csdn.net
sodme 发表于2005-06-12 21:28:00 IP: 61.186.252.* 呵呵，感谢腾讯的朋友澄清此问题，也了结了一个悬念。^_^

此文是差不多一年前写的了，先是放在文档中心的，后来转到了blog上。当时，让我体会最深的是，要实现一个可扩充的支持百万人在线的服务器，核心的概念是要有一个负载均衡服务器，它是直接向玩家开放的，而一旦它的任务完成后就可与客户端断开连接了。之所以能支持这样的量，就因为建立连接和释放连接这样的一来一往不会消耗完服务器的连接套接字数量上限。
ilovevc 发表于2005-06-15 09:10:00 IP: 61.186.252.* >>：socket 的创建数目，上限不是65535

不解. 应该是有上限的, 就是一个short的最大值.

>>比如web server，所有的客户端都是连到port 80上的。即便只用一个port，这个方面的连接数都是无限的.

对, server确实只需要监听一个80端口, 但是当client连上来以后, server端要分配一个额外端口用于和client进行一对一通讯, 这时就有限制了. 如果同时client过多, 这个额外的端口就不够分配了.

总之, 只要是走TCP/IP, 由于TCP的端口号是short(2 bytes), 就有理论上的限制, 即64K.





sodme 发表于2005-06-15 09:17:00 IP: 61.186.252.* 查了一下MSDN，在其中对SOCKET类型的定义，是unsigned int，而unsigned int类型到底代表多少字节，在不同的系统结构中是不同的，要以具体机子的系统架构而言，不能说就一定是64K。
sodme 发表于2005-06-15 09:31:00 IP: 61.186.252.* >>比如web server，所有的客户端都是连到port 80上的。即便只用一个port，这个方面的连接数都是无限的.

web server之所以表现出来的是连接可能是无限的，但这并不说明socket本身创建数目是无上限的，web server基于的是http协议，而http协议是短连接协议，即：完成数据交换后客户端与服务器端即断开连接，它们的连接并不是总是保持的。在每次HTTP传输的最后，都会有RST连接重置的命令。

ilovevc 发表于2005-06-15 13:06:00 IP: 61.186.252.* 看SOCKET是无意义的, 它一般是一个Handler, 表示了OS的一个资源. 跟TCP/IP不直接相关.
应该看的是sockaddr_in结构, 其中的port就是是一个short类型.
或者看IP头, IP头包含以下3个部分,
1. 类型, 对于我们所说, 都是TCP (为8 ?)
2. IP地址, 对于我们所说, 假设该server只有一个IP地址
3. 端口号. short类型.

这样, 对于一台机器, 对于TCP来说, IP中的类型, IP地址都是相同的, 唯一能够区分不同socket的就只有端口号了, 而TCP是一对一的, 那么理论上就只能有64K 个clients. 否则底层收到一个IP包, 端口的理论范围都只有1-64K, 它如何区分这是给1号client 的, 还是给 64K+1号client?
sodme 发表于2005-06-15 14:27:00 IP: 61.186.252.* 分清两个概念哈：
一个是可创建的SOCKET句柄数，一个是port（端口）数，后者65536，我没有异义，但这个仅代表本机可以在多少个端口上对外部访问进行监听。而监听之后，客户端与服务器端的单个通信是通过SOCKET句柄相关联的。比如，你在A地用浏览器浏览google，在B地另外一个浏览器也在浏览google，它们访问的都是80端口，这个在IP头上是完全一样的，只不过，在WEB服务器上，会创建不同的SOCKET句柄与客户端进行一对一的通信。并不会出现这种情况：当在B地浏览GOOGLE时它的IP头里的端口信息就变了。

另外，IP头信息里，是不包括端口信息的，它只包括源IP、目的IP地址以及协议类型(如是TCP还是UDP等)等信息，而源端口和目的端口等端口信息是在TCP的包头里才包含的，这是两个不同的协议封装层次。

下面是TCP的协议格式：
Source Port (16) | Destination Port (16)
Sequence Number (32)
Acknowledgment Number (32)
Data Offset(4) | Reserved (6)|UGR|ACK|PSH|RST|SYN|FIN|Window(16)
Checksum (16) | Urgent Pointer (16)
Options (0 or more 32 bit words + padding)
DATA

端口号为16位长，最多65536。但这并不代表此端口上可连接的客户端数量就是65536，它最多只表示同个IP可创建的最多监听端口数，呵呵。

非常高兴跟你继续讨论。^_^
ilovevc 发表于2005-06-15 15:09:00 IP: 61.186.252.* 呀, 惭愧. 确实Port在TCP首部, IP中只包括地址和类型.
我又翻了翻W.Richard.Stevents的书, 发现确实是我错了. 由于使用4个元素( src ip, dest ip, src port, dest port)来确定一个端口, 因此并没有64K的限制. (我以前还一直这样认为)

sodme 发表于2005-06-15 15:20:00 IP: 61.186.252.* 呵呵，没事。偶原来也一直认为65536是它的上限，后来跟朋友讨论时才知道原来port和socket并不是一回事，哈哈。：）　欢迎常来讨论。
Joys 发表于2005-06-16 00:15:00 IP: 61.186.252.* 在windows上如果不是使用IOCP，而是使用select话该如何设计呢？
sodme 发表于2005-06-16 00:36:00 IP: 61.186.252.* to Joys:
IOCP和select只是在网络模型方面有所区别，在我的另外一个系列文章：
http://blog.csdn.net/sodme/archive/2005/06/12/392977.aspx
这里所提到的模型架构，很多也同样适用于select模型，比如：最好也要有数据队列的概念等等。但在win平台上，IOCP确实是最为高效的模型了，使用select可以是可以，但性能肯定没有IOCP好。

Joys 发表于2005-06-16 00:42:00 IP: 61.186.252.* 上了K级别的肯定是要用IOCP的了，如果只是几百个长连接，并且考虑到跨平台问题的话还是选择了select。目前发现一个问题就是用一个线程对400个连接的读状态进行循环监测的时候，当不停的有包发送过来，循环select导致CPU占有率非常高，不知道sodme兄是否可以给点意见和建议。谢谢
sodme 发表于2005-06-16 01:49:00 IP: 61.186.252.* 你的循环是怎么作的？可否给出片段代码？或者大致描述一下结构？有包过来后，你是如何处理的？直接进行逻辑处理还是先放入数据队列？
西瓜 发表于2005-06-16 02:01:00 IP: TrackBack来自《负载均衡－－大型在线系统实现的关键(上篇)（再谈QQ游戏百万人在线的技术实现）》：

Ping Back来自：blog.csdn.net
Joys 发表于2005-06-16 21:45:00 IP: 61.186.252.* 你好，我白天没法上网的，不好意思。我是起了一个专门的线程进行400个socket的可读状态的循环监测的，当其中有socket可读时就取出这个socket，交给另外的线程进行数据读取，读取的数据放入数据队列供处理线程进行处理。大体上就是这样的。
Joys 发表于2005-06-16 22:41:00 IP: 61.186.252.* 偶mail是SocketBoy@msn.com，谢谢
岚焕 发表于2005-06-16 23:38:00 IP: TrackBack来自《负载均衡－－大型在线系统实现的关键(上篇)》：

本文作者：sodme本文出处：http://blog.csdn.net/sodme声明：本文可以不经作者同意任意转载，但任何对本文的引用都须注明作者、出处及此声明信息。谢谢！！　　要了解此篇文章中引用的本人写的另一篇文章，请到以下地址：　　http://blog.csdn.net/sodme/archive/2004/12/12/213995.aspx　　以上的这篇文章是早在去年的时候写的了，当时正在作休闲平台，一直在想着如何实现一个可扩充的支持百万人在线的游戏平台，后来思路有了，就写了那篇总结。文章的意思，重点在于阐述一个百万级在线的系统是如何实施的，倒没真正认真地考察过QQ游戏到底是不是那样实现的。...
redchina 发表于2005-06-18 15:01:00 IP: 61.186.252.* socket 的创建数目就我的理解其实是受机器的内存配置的影响。因为每创建一个socket，就会消耗一定的核心内存。微软规定所有应用程序占用的核心内存有一个上限。你的思路跟我的思路差不多，不过我只用了两类服务器，登陆服务器，游戏服务器。房间从属于游戏服务器，每个房间我在服务器中把它加到一个不同的广播域中，这样客户端的数据广播数据就限定在每个房间中，大大的减轻了服务器的负担。
sodme 发表于2005-06-18 16:57:00 IP: 61.186.252.* to redchina:
你可以到以下的地址处参与讨论：
http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx

因为CSDN现在对于15日前所发的文章，这些文章的修改和评论已经不作即时显示处理了，而是时隔24小时后才显示评论内容，所以这篇文章后的讨论会受点影响。^_^
shadowfish 发表于2005-07-03 23:22:00 IP: TrackBack来自《负载均衡－－大型在线系统实现的关键(上篇)（再谈QQ游戏百万人在线的技术实现） 》：

Ping Back来自：blog.csdn.net
大宝 发表于2005-08-31 23:30:00 IP: TrackBack来自《CSDN旧文备份---负载均衡－－大型在线系统实现的关键(上篇)（再谈QQ游戏百万人在线的技术实现）》：

近日在与业内人士讨论时，提到QQ游戏的实现方式并不是我原来所想的那样，于是，今天又认真抓了一下QQ游戏的包，结果确如这位兄弟所言，QQ游戏的架构与我当初所设想的那个架构相差确实不小......
FreeXploiT 发表于2005-09-02 14:00:00 IP: TrackBack来自《负载均衡－－大型在线系统实现的关键(上篇)（再谈QQ游戏百万人在线的技术实现）》：

Ping Back来自：blog.csdn.net
linux2linux 发表于2005-10-18 17:16:00 IP: TrackBack来自《负载均衡－－大型在线系统实现的关键(上篇)（再谈QQ游戏百万人在线的技术实现） 》：

Ping Back来自：blog.csdn.net
theforest 发表于2006-01-31 17:09:00 IP: 211.100.21.* TrackBack来自《负载均衡－－大型在线系统实现的关键(上篇)（再谈QQ游戏百万人在线的技术实现）》：

以上的这篇文章是早在去年的时候写的了，当时正在作休闲平台，一直在想着如何实现一个可扩充的支持百万人在线的游戏平台，后来思路有了，就写了那篇总结。文章的意思，重点在于阐述一个百万级在线的系统是如何实施的，倒没真正认真地考察过QQ游戏到底是不是那样实现的。