456主机测评
网络游戏服务器的主要作用是模拟整个游戏世界，客户端用过网络连接把一些信息数据发给服务器，在操作合法的情况下，更新服务器上该客户端对应的player实体、所在场景等，并把这些操作及其影响广播出去。让别的客户端能显示这些操作。
在这个模拟过程中，需要解决的一个重要问题是：多长时间处理（更新）一次该服务器上的待处理事件，体现在实际开发中，这就是一个服务器端的心跳设计问题（tick）。
在网络游戏服务器端的心跳设计里主要面临以下几个问题：
为了解决以上问题，本文将对心跳进行分类，从不同角度进行讨论。
一、按照策略分类
就心跳间隔策略而言，现在的网游服务器端主要分为两种。分别是固定tick时间和固定sleep时间，可以通过下图进行具体的说明：
图 1-1
如上图1-1中，画出两种间隔策略的示意图，渐变颜色的横条代表时间，Tick1、Tick2代表程序两次不同的更新操作，Run1、Run2代表在心跳函数里处理更新操作所需的时间，Sleep1、Sleep2代表让出CPU时间片的时间。
（1）固定Tick时间：顾名思义就是指程序每次心跳的时间都是等长的、固定的。如图中的“图A”，Tick1和Tick2的时间是相等的，如果实际执行的比上次执行时间长（Run2 > Run1），则Sleep2 < Sleep1，同时满足等式：Tick1 = Tick2 = Run1 + Sleep1 = Run2 + Sleep2
（2）固定Sleep时间：每次心跳，更新操作执行完成后，sleep固定的时间。如图中的“图B”，Sleep1 = Sleep2，Run1和Run2不一定相等，同时满足等式：Tick1 = Run1 + Sleep1，Tick2 = Run2 + Sleep2
下面结合具体的代码对比说明这两种策略
1.1 固定Tick时间
使用固定tick时间的心跳策略的一大好处就是，在负荷不高的情况下，由于相邻两次tick的时间一定，所以开始执行Run1到开始执行Run2的时间间隔一定。tick时间固定带来的另一个好处就是容易实现逻辑服务器运行时快放慢放功能（见？？），当然固定tick时间同样带来一些问题，如下图：
图 1-2
如图1-2，在负荷不高的情况下，心跳函数可以按照上图中“图A”的时间线正常的运行，如果在服务器运行的过程中遇到一些突发事件（开新服、做活动、大世界内大范围的帮战），会导致服务器CPU负荷变高，从而使得一次tick无法处理完当前所有事件，出现“图B”中的情况Run1 > Tick1，这时Sleep1不管取什么值都不能满足等式Tick1 = Run1 + Sleep1，
这样一来就带来第一个问题：高负荷情况下如何保证CPU能充分利用的情况下，tick1和tick2两次心跳互相不干扰？伴随而来的另一个问题是tick时间设为多长才能满足低负荷时固定间隔的要求，同时不能经常出现“图B”的情况？
下面结合实例讲解固定tick时间的心跳如何编写，以及如何处理以上两个问题。
Mangos-Zero
mangos-zero项目中的逻辑服务进程mangosd的心跳函数采用如图1-2中的“图C”的方法，当更新的处理时间Run1大于固定大小的tick时间时，下一个tick到来时不sleep直接执行Run2，实现代码如下：
以上代码是游戏世界的主循环，看while循环里的代码，主要干下面几件事：
（1）从WorldTimer::getMSTime()得到一个uint32的值realCurrTime，realCurrTime是循环的（到增加到0xFFFFFFFF后，在增加就变成0），表示当前时间，单位是毫秒，是一个相对前一次tick的时间。
（2）使用WorldTimer::tick();计算上次tick到这次tick的时间差diff，该值理论上等于realCurrTime – realPrevTime
（3）sWorld.Update( diff );就是tick里的处理函数，游戏逻辑在这里得到更新处理。
（4）这里就是图1-2中的“图C”所描述的，如果运行时间大于固定的tick时间，则不sleep继续占用CPU来处理更新，直到能在一个tick处理所有操作为止，这个时候才会sleep让出CPU时间片。
（5）WORLD_SLEEP_CONST就是固定的tick的时间长度，在这里是50ms
总结：现在可以回答本节前面的两个问题：在高负荷情况下mangos采用图1-2中“图C”的方式提高服务器的响应速度，每个tick时间长度为50ms，也就是每秒钟更新20次，能满足更新的需求。
timer_thread
出于模块化的考虑，固定tick时间策略还有一种实现方式：使用单独的线程做timer，周期性产生心跳信号或者心跳task。工作原理如下图：
图 1-3
图1-3也是比较常见的设计方案，服务器进程采用多线程方式，主循环线程、timer线程及其他非工作线程向任务队列（task queue）中添加task，而工作线程不断的从任务队列中取出任务执行相应的处理。这里提到的timer thread就是用来产生心跳任务的，timer thread会每隔50ms产生一个heartbeat task放入任务队列中。一般来说队列中的heartbeat task的数量会远远大于其他task，所以这种策略也可以称为固定tick时间的心跳策略。在服务器高负荷运行的情况下，近似于mangos所采用的图1-2中“图C”的方式进行处理。多个worker thread的情况下，还需要对heartbeat task加锁。
1.2 固定Sleep时间
固定Sleep也是一种比较常见的心跳函数间隔处理策略，如下图，每次心跳处理函数执行完毕后sleep固定长度时间。
图 1-4
如图1-4，Sleep1 = Sleep2，Run1和Run2不一定相等，同时满足等式：Tick1 = Run1 + Sleep1，Tick2 = Run2 + Sleep2。下面结合实例进行说明：
根据网上流出的天龙源代码，GameServer工程的主循环至线程的心跳函数的调用过程如下：
如上，主循环启动一个“用来处理服务器之间数据通讯的线程”m_pServerThread，以及一个线程池m_pThreadPool。首先看m_pServerThread的run ()函数，调用g_pServerManager->tick ()函数，代码如下：
如上，在Tick ()函数里首先调用ServerManager::Select ()，在Select函数中（2）调用MySleep(50)让出CPU时间片50ms，然后给select_ex设置100us的超时，可以认为每次执行完处理后，会固定sleep 50ms。
再来看看Threadpool里线程的tick函数
根据以上代码中的（1）、（2）、（3）可以看到场景的tick函数中采用同样的方法，每次调用时先调用MySleep(50)让出CPU时间片50ms，然后再执行相应的处理代码。
总结：
（a）固定Sleep时间在高负荷情况下，由于每次都会强制让出CPU时间片，会不会导致响应不及时？
（b）在每次运行执行处理函数的时间比较稳当的情况下，这种策略还是能提供比较稳定的tick间隔。
（c）这样的设计目前为止本人还没有看出有什么好处？请各位博友指教。
二、按照物理位置分类
按照物理位置分类，分为两种，一种是运行在同一物理主机上，另一种是运行在不同的物理主机上。该分类是受到云风一篇blog的启发（见《心跳服务器》）。
（1）心跳服务和逻辑程序运行在同一物理主机上：据我所知，大部分的网游服务器程序都采用这种方式，而且心跳服务往往和逻辑程序写在同一个进程里。心跳服务和逻辑程序不在一个进程里，但运行在同一物理主机上的情况本人没有见过，也不敢妄加臆断。
（2）心跳服务运行在一台独立的物理主机上：（a）按照云风的说法，这样做最大的好处就是方便实现服务器的快放慢放功能，从而很容易重现bug。博文中指出使用使用10Hz的心跳间隔，以局域网内0.1~0.2ms的ping值，不知道能不能容忍？而且使用TCP连接，多两次网络IO，不知道效率如何？（b）另一种独立的心跳服务器是本人读研时参与过的大屏幕显示同步时遇到的，当时一块大屏幕有24台主机，每台主机负责绘制图像中的一块区域。使用一台单独的心跳服务器，用同步卡向着24台主机的串口周期性的发信号，这24台主机收到从串口来的心跳信号后，同时开始绘制这一帧。不过据说精确度有待提高………
三、总结
综上所述，最常见的心跳服务是这样设计的：使用固定tick时间策略，与逻辑处理程序写在同一个进程里，tick时间50ms，100ms。
声明：本文所使用的代码均从互联网上获得，本人没有传播及利用其获取商业利益
- 海报
