浅谈网游服务器的承载

   本人对做了四年的游戏服务端，对市面上面的一部分游戏框架有一定了解。今天就以用得最久的那套框架：烈火战神为例。

   烈火战神那套游戏框架一开始上线的时候可以同时承载在线2000人，同屏承载300。时至今日，从那套框架衍生出来的二次开发产品能承载个800人就不错了，由于客户端很多没优化得好，同屏100人就很卡了。

  三个原因局限：

  1：对于那套框架最大的一个局限就是用的单进程单线程服务器，也就是说引擎启动随机分配到一个CPU上面。只有一个CPU在处理问题，其它的CPU只能干看着。好了，中央处理器能力就这么大，你的代码写得越低效，承载的人数就越低。对于太耗性能的东西我总结出来几个点。

  2：第一，AOI大头，估计占比40%以上，主要表现在人物的移动，玩家的出现与消失，属性的变更方面，说到底就是有变化就会对你身边的实体进行广播（可以想象一下，同屏PK的场景，那数据量够大吧）。其次的话就是除了人物以外的实体AI，就拿怪物的AI来说，在线程遍历的时候，无时无刻不在检测周边出现的实体。

  3：再有的话就是衍生出出来的代码臃肿问题了，公司是要赚钱的，哪那么多时间让你去去除臃肿，性能优化（其实，很多公司知道，一旦上线，哪有这么多人玩啊！一般小平台几十个人，根本不会卡。你跟老板要时间来优化，你会被打的）.

 解决方案:

 1:你如果还想用单线程的话也可以，其实引擎启动的时候可以给它绑定多几个CPU(SetThreadAffinityMask(hThread, dwMask)，这是windows API函数）。但是这种局限在Windows环境下面的，而且也不能绑定过多，一般超多三个就会出现CPU的竞争情况。还有一种的话就是多线程咯，可以按照场景来分，也可以按照系统来分（个人的喜好一般是喜欢把AOI和聊天系统分出来，其它都还好）

 2:再有就是代码问题了，其实这是小创公司一个共同的弊病了。很多不好理的逻辑，一般都是根据需求来开发的。策划都想玩创新，结果导致，代码里面这里一个IF那里一个While。很伤。然而，一百多个系统，乱糟糟，建议，如果想开发好的引擎，先拿半个月来一次瘦身最好

附加：服务器在查找方面需要注意好，简单直接才是最好的方式，看到很多游戏服务器动不动就用到了MAP结构，模板啥的，显得很高大上，其实并不然。比如做nActorID查找的时候，人数一多就是挺耗费性能的，不是哪种查询能够解决掉的问题。这种的话就必须要做直接索引了，我看过两种直接索引方式，第一种的话是直接把内存指针做成玩家的nActorId，强转就能得到玩家的Object。第二种方式的话就是拆分8字节，直接索引得到玩家的Object。