本文作者：sodme
本文出处：http://blog.csdn.net/sodme
声明：本文可以不经作者同意任意转载，但任何对本文的引用都须注明作者、出处及此声明信息。谢谢！！
在网络应用中，“负载均衡”已经不能算是什么新鲜话题了，从硬件到软件，也都有了很多的方法来实现负载均衡。我们这里讨论的负载均衡，并不是指依靠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里所定义的这些玩家组织形式的规则可能都会因为“全服皆通”而改变。
架构的选择是多样性的，确实没有一种可以称得上是最好的所谓的架构，适合于当前项目的，不一定就适合于另一个项目。针对于特定的应用，会灵活选用不同的架构。但有一点，是可以说的：不管你如何架构，你所要作的就是－－要以尽可能简单的方案实现尽可能的稳定、高效！
<全文完>
本文引用通告地址： http://blog.csdn.net/sodme/services/trackbacks/394576.aspx
[点击此处收藏本文]
又一位不敢以真面目示人的兄弟，如果你有能耐，你可以指出在这篇文章中我哪一点说错了，那样的话，我将非常感激，但象你如此无聊的扯其它东西，乱咬乱吠就不太好了。
单台２万是什么了不起的数据，edonkey服务器单台可以达６０万连接
１..３个connect server+n个game server＋１个数据库agent server
就能够构成一个服务器组了
短连接．．，的观点是错误的，无论如何服务器端都要维持对应的连接，快速断开，只是把负载踢给其他程序，该干的活是逃不掉的
全局信息的索引．．这不是问题，一个database agent server 就可以解决
能给个联系方式吗。我的MSN：xingliu2001@hotmail.com
另：支持sodme.反对II，我们写文章、读文章希望大家能共同提高。
打赢老外。
能给个联系方式吗。我的MSN：xingliu2001@hotmail.com
另：支持sodme.反对II，我们写文章、读文章希望大家能共同提高。
打赢老外。
偶一直是从事win平台下的服务器开发，说实话，我还真没见到过在目前我看到的网游项目中有单台能支持2万以上的，如果你遇到过，请你告诉我游戏的名字。我知道，在linux底下支持2万在线并不是什么大不了的，但那是linux。至于说edonkey单台60万或者更高，我想，这不能简单归结于“连接量”问题，edonkey的服务器逻辑以及数据通信量与游戏服务器相比，游戏服务器要复杂得多，你以edonkey有连接量来类比游戏服务器的承载量显然是不合适的。
相反的，我坚持认为短连接是解决有限的系统规模与庞大用户量矛盾的重要手段，至于服务器组到底可支撑多少人，当然还是要看底层的逻辑服务器的同时承载量。在底层的服务器组内，客户端肯定是要保持连接的，这一点毫无疑问。你自己也说了要快速断开。我不知道你这里的不是短连接是什么？请注意，我说的短连接，并不是指的在game server这一层，而是在connecter server这一层。
GOOGLE的流量更大，一般采用infiband技术，采用特殊硬件，各个机器之间直接访问对方内存，几个G的流速都可以。
短连接解决负载均衡的问题，没看明白。连接都建立了，还能怎么均衡？把自己的活推给别人？推给谁？在降低每个连接的消耗上下工夫个人觉得更好，比如如何减少交流的数据，如何减少运算，等等，这是最关键的。
======================
以棋牌类游戏的数据量以及逻辑运算量,单台服务器支持2W的用户,即使采用UNIX系统也是不太可能的吧.我说的是一般的单双CPU PC服务器,当然可能存在这么牛的PC服务器,当然不考虑中、小型机机之类。个人觉得，这个服务器程序肯定是基于分布式服务器构架。也就是有一台机子负责数据的接收和发送，就是客户端接触到的机子。其他的
逻辑运算则分布到各个服务器中处理。
楼主的文章写得不错。受益匪浅啊~~
sorry，这里提到的“负载均衡”应该是打引号的，呵呵，并不指如LVS那样实现的底层负载均衡，而是指应用层的，它并不负责在底层建立连接的这一步之前作均衡，而是只作业务层的均衡，呵呵。
用linux作棋牌类的，单台支持2万，问题不大。呵呵。分布式架构是肯定有的，但每台单独的服务器程序，也完全有能力支持2万在线。偶现在业余时间正在linux下作这方面的开发。
如果链接上去后什么也不干，什么包也不发，
即使一台普通PC,也能开到64511 (65535 -1024)个链接。
这个连接数跟游戏设计是相关的。
不同的游戏，相差很大，带宽需求不同，每秒钟发包数、接包数不同。
保守的算，所有链接合起来一秒钟发一万条消息的话（也就是每条链接一分钟发一次包），
服务器网卡每秒钟要处理多少次中断？时钟中断也不过18ms一次！
这时会出现严重的丢包，然后客户端超时重传，问题会更加严重。
不同的游戏比这个一点意义没有。
对MMORPG网络游戏希望能看到你的所知道的看法。特别是整体架构上的看法，老在门口转不过瘾，哈哈
如果能写点关于mmorpg网络游戏服务器端设计应该注意的要点之类的文章应该会增添点色彩。
你的单台PC连接数计算有问题，请说明65535从何而来。另外，在回贴之前，请参考这篇文章后我与另外一位网友的讨论：
http://blog.csdn.net/sodme/archive/2004/12/12/213995.aspx
sure, 单纯计算连接数当然无意义，我也从未说过这样有意义。呵呵。
to 阿虹：
MMORPG的逻辑线程，对于同类型的逻辑，最好只有一个线程，不要把相同的逻辑交给不同的线程去作，不然线程同步将变得很困难。除了线程同步外，MMORPG另一个同步问题是服务器与服务器，以及服务器与客户端的数据同步问题，比如跨服战斗或跨服交易问题。
to joey:
老实说，服务器设计就是经验积累而来的，没有一定的积累，确实难以写出东西来。偶也正处于这样的积累阶段，虽有些心得但可能还有很多不成熟的地方，很多地方还需要加强和提高，越作越觉得有很多东西要学。MMORPG的服务器端架构，我现在能自信比较熟悉的就是通信这一块，如果大家有通信架构这方面的疑惑我很乐意参与共同讨论，至于MMORPG逻辑架构这一块，不是我的强项，这方面目前我也是在积累中，之前我也曾作过一个休闲游戏项目，休闲游戏的逻辑架构方面要相对熟悉一些。至于您所说的截包方面的文章，只能算是偶的业余爱好，呵呵，每当市面上出现一个好点的游戏，我的习惯都是想先去分析分析它的通信流程和数据包设计。至于说IOCP相关的文章，我相信，你一篇也找不到我转载的别人的文章，皆是自己开发过程中的体会和感受以及总结，不存在转载一说。即使是其它类型的转载文章，我都会在文章首部加以说明。