服务器之多进程VS多线程

生平第一次写点技术文章，不知道咋开头，随便起个头吧。记得有一次似乎看到一句话：“真正的服务器高手是要充分利用机器的CPU，内存资源！”

出于对高手的憧憬，记下了这句话。我也不是高手，也从未有过很成功项目的经验，在这里对服务器有点浅溥认识，写下来供大家参考参考

首先将服务器的功能模块先简单归纳下：

1、登陆

2、游戏逻辑（战斗、任务、Object管理、场景管理、NPCAI寻路等其它策划需求，还要用到脚本） 

3、网络

4、日志

5、玩家数据存储、玩家数据缓存

现在任何一台物理机器也有十个八个CPU。所以服务器也应该分多线程或多进程来利用CPU。

上面对服务器功能的归类其实不太好，但我实在不知道怎么来更好的归类。从上面的列举我们可以看出，其实游戏服务器，主要的难点还是在游戏逻辑这块。它的逻辑复杂，并且需求也会经常变化。其中战斗、Object的查找，AI寻路（如果服务器是3D游戏则更为突出）都是性能瓶劲的重要地方。所以其实服务器竽点还是要处理这块的问题。无论是多进程学是多线程，登陆其实我们都会用单独的登陆服务器。网络和日志因为功能模块独可以切割到另外的线程，不受单服还是多服的影响。

下面正式让多线程和多进程做下PK：

I、多线程服务器，玩家数据缓存和向DB的存储我们可以开一个线程单独去做，这样不会有什么大的问题。日志和网络上面说过可以很容易切割出去，主要就是对游戏逻辑的切割。

A：按场景分线程，一个线程管理若干个场景。这样配置灵活，一个线程可以管理若干个小场影，除非有个场景人多到一个CPU跑不下来，一般的游戏都会满足需求。缺点则是不在同一线程的Object在做逻辑交互时，必须用异步，如果用到了脚本，那么这里的复杂度和性能要值得注意。如果项目中出现单个服务器解决不鸟的问题(例如战场服务器)，似乎就成了多线程多进程的庞大架构。

B：将某些功能切割到其它线程，例如Object的管理和查找，NPCAI的寻路，这种方式貌似在做逻辑需要分离到别的线程模块功能时有点麻烦，如果直接上锁等待肯定不是最好的方式,所以这些逻辑必须变成异步。

2、多进程服务器,其实这里的多进程和场景多线程改成了多进程。这里玩家数据缓存和向DB的存储我觉得用一个单独的DB服务器。多进程服务器可以在GameServer和GameClient之间加一个Gate，因为在跨服场景不需频繁断线连接。多进程服务器所有的通讯都依靠网络，有些逻辑必须有网络延迟的消耗。优点是配置灵活，在物理机器性能不够时可以通过扩充物理机器来解决。

 

上面写了这些，其实无论哪种方式只要能解决项目中的问题就行。没有最好的，只有更适合自己的。具体情况也会有自己的特殊处理部分，其实不管上面按场景分的多线路程还是多进程服务器，但如果服务器有3D的AI寻路，我个人认为也最好将其做成单独的服务器，这样来保证灵活。其实具体采用哪种，和项目的定位也是息息相关的

不过从我的观点出发，还是倾向于用多进程服务器。我觉得多进程有个优点就是在开发的过程中可以降低BUG查找难度。因为项目是一个团队的合作，团队中不断会有新人加入，并且所有人的水平也参次不齐。就像我们用LUA，PYTHON一样，其实很大程度为了降低开发难度,让新人快速融入进来。单个进程服务器的功能比较单一、逻辑上也会比较清晰，会有利开发过程中BUG的查找，对团队的合作而言比较有利。