游戏服务器与多线程方案思考.docVIP

游戏服务器和多线程方案思考 这些东西是平时遇到的,觉得有一定的价值,所以记录下来,以后遇到类似的问题可以查阅,同时分享出来也能方便需要的人,转载请注明来自RingOfTheC[ring.of.the.c@] 写在前面的 存在即合理,不管什么事,都是有原因有理由有前提的,所以在谈论之前我们先要明确一些东西 1.服务器端使用多线程的必要条件是多核,且物理核的计算能力总和服务器程序的计算量.如果不满足上述条件,应该先考虑硬件配置问题. 2.为什么要用多线程?是为了充分利用多核增加计算量,增大计算量的目的是什么?支持更为复杂的玩法.这里有很重要的信息,那就是支持更为复杂的玩法是目的,而增加计算量是达到目的的手段；前者是策划域问题,而后者是程序域问题.一个需求和实现的结合点. 3.当计算量达到时,其他短板开始起作用,也就是说不要去追求所谓最好利用计算量之方法,转而追求计算量不要成为最短板即可. 这片文章是在有支持更为复杂的玩法这样的需求,且当前存在计算量目前是最短板,且由于没有充分利用多线程发挥机器多核计算量即计算量有较多剩余的情况下的一些探讨和心得. 申明：本文并不想得出任何我这个就对！的方案,只是将我在实践中遇到的问题,和解决问题或是看到的一些思路写出来,期望能引发大家的探讨：)相比之下文中提高的方案只不过是一个example罢了 一个地图一个线程的方案 关于在游戏服务器中使用多线程,有一个常常被提到的方案是：一个地图一个线程,这个方案的一个推广就是平行子系统中每个子系统对应一个线程.个人认为这个方案还是值得商榷的.下面来说明一下我的看法. 根据一些讲解系统的名著中的定义：在问题域的世界中,交互联系格外紧密的一群实体之间形成了一个系统.一个子系统之所以被划分成为一个子系统,是因为在子系统中的成员的交互和联系频率要远远大于和系统外实体的交互和联系,这是一个很重要的结论.我们可以从这里得到一个推论：划分良好的子系统内部交互非常紧密,和外部实体交互相对较弱.很巧的是我们在设计中往往会把这里的子系统划分为程序中的一个功能模块,模块也有这样的性质,模块中的交互要远远大于模块间的交互. 有了上述理论的支持,再来看看为什么说一个地图一个线程这样的方案不可取?一个地图是一个子系统,地图间的交互是非常小的,的确是这样,可能就是在不同地图中移动时等不频繁事件.这里可以分析一下地图绑定线程这个想法的依据： 1.增大计算量.在系统中引入多线程,利用多核,加大服务器端的计算能力(提供更多的游戏逻辑处理),这样就可以在一个服务器上容纳更多的玩家. 2.防止犯错.避开多线程的锁的问题,把交互性强的部分分在同一个线程中,这样的话在大部分情况下避免锁,只有在很少的跨地图交互时才使用同步方法来保证[避免锁可以防止锁的竞争,更重要的是在实际编程中解放程序员,因为时刻考虑多线程问题太痛苦了,犯错不可避免].放在这里就可以发现按地图划分是一个很好的划分线程的方法. 该方法的问题在于首先它不一定很发挥出多核的效果,因为游戏中人不太会是均匀的分布在多个地图上.这样就会产生有的线程都忙不过来了[地图人很多],有的线程很闲[地图人很少],问题的本质是这种使用线程的方法限制了每个地图的可使用计算量[无形中的一个假设是：单个核的计算量是足够的,一旦现实情况不符,服务器端就会掉帧],也就是说对每个地图来说,还是单线程的,并没有达到想要的增大计算量的目地.其次,系统的稳定性差,因为只要有一个线程core掉,后果可想而知.再次,暂时不谈前两个问题,那么在计算量得到充分满足的条件下,根据短板效应,你的系统的能力又会开始受到内存,网络等其他因素的影响,这时你可能会想要在其他机器上横向扩展系统,你必须单独设计这一部分,多线程体系本来就有我能发挥机器的计算能力,计算量从此不是问题这样的倾向,但是它的一个不可回避的问题就是,多线程的执行流共享程序进程空间,它必须在同一台主机上.分布式的横向扩展对多线程来说是另一个课题,它从来没想过这个,你得自己去实现. 其实根据设计的特点,这里还不如只用多进程来代替多线程,因为： 1.多进程同样发挥多核的计算能力,至少在地图绑定线程这个问题上不弱于多线程,但也不会强,因为也受到单线程地图的影响. 2.多进程稳定性好,一个地图进程core了,其他地图不受影响. 3.使用socket进行地图[进程]间通信手段,天然支持分布式部署,在系统需要横向扩展时,不用做任何的额外工作. 总的来说,这种平行子系统中一个子系统对应一个线程的方法看似使用的多线程,但是本质上还是单线程的设计思路,所以不是一种很好的方案,但是这个方法有它的可行性和合理性,因为它的确是分摊了计算量,而且不用过度考虑锁的问题,所以它还是有很重要的参考价值. 去现实世界中寻找答案 另一个想法是,游戏世界中的每一个a