Hybird3D

乔捷的技术博客

博客园 首页 新随笔 联系 订阅 管理
  15 随笔 :: 0 文章 :: 105 评论

我们的网页游戏服务器上线2个月了,一直运行平稳,没出什么重大BUG。前两天刚更新了一个版本,结果今天早上GM报过来一个BUG,让我折腾了整整一天。

事情是这样的,早上GM报告说某台服务器上有玩家抱怨在线时间奖励无法领取,客户端上显示在线时间已经到了,点击领取服务器却报错说在线时间不足。一开始怀疑是否客户端计时和服务器是否不同步,但很快排除了这个可能性。反复实验后发现是服务器上的玩家在线时间一直没有更新。查阅了一下服务器代码,玩家的在线时间变量是每隔60秒加1,这里判断时间间隔是用的系统的tick count,tick count是一个32位的int,单位是毫秒,每隔40天会溢出,因此就怀疑是不是tick count溢出,造成了时间判断错误(但是实际上tick count循环相减也是能够得到正确值的)。

虽然一时难以确定是tick count溢出造成的问题,不过还是顺手把tick count改为了更加可靠的DateTime计时方式。但就在修改的过程中,GM又收到了更多的玩家抱怨,其他和时间相关的刷新功能都报出了问题,最要命的是我们的游戏有每日零点自动恢复资源的设计,服务器是美国太平洋时间也就是我们早上10点会自动刷新资源,结果在线的玩家都没有在这个时间点上刷新资源,于是玩家开始造反了,各种投诉和抱怨不断。

继续查阅代码来分析问题,零点刷新的代码是用的DateTime来计时的,这样就排除了Tick count的问题,根据所掌握的情况,跟时间相关的功能都多多少少出了问题,但也不应该是代码的问题,因为其他服务器都正常运行的。难道是系统本身的时间出了问题吗?貌似只能这样解释了...不过,当你开始怀疑编译器、系统或者硬件出问题的时候,往往是自己犯低级错误的时候。所以我决定在关闭、迁移服务器之前再好好检查一下服务器的log记录,以定位问题所在。

在生产环境中的服务器是没办法用调试器去检查问题的,要分析问题只能看log记录。但是正式运营的服务器是不开DEBUG级的log的,(开了的话每秒会输出几千条信息,那就把服务器彻底搞崩溃了),所以能够看到的log信息很少,也没有发现明显的异常出错log,要定位这个问题就比较困难了。不过我在服务器上集成了一个实时profile的功能,能够统计并打印每个重要函数(感兴趣的函数)的执行次数和执行时间,profile了几次,终于发现了一条重要线索:服务器的主定时器OnUpdate函数不执行了。因为大部分时间相关的刷新都是在OnUpdate里执行的,这个函数不执行可想而知服务器问题有多严重,难怪玩家抱怨不断了。

服务器的定时器代码是我自己实现的,之前跑了那么久一直都没出过问题,怎么这次突然会出问题呢?分析了一下代码终于找到了原因,Timer的调度函数在每次执行完Timer的事件代码之后会重新把Timer添加到Timer队列里以便下次执行(如果这个Timer是多次或者无限次运行的话),由于Timer函数可能因为BUG会抛异常,所以调度函数是会处理异常事件并记录出错log的。但是在接住异常后我的代码就不会再将这个Timer添加到Timer队列里了,从逻辑上说这个策略是为了保护服务的安全性考虑,一旦Timer函数出现了异常,那么下次就不应该再去调度这个Timer,否则可能会不断的出异常把服务器拖慢甚至拖死。但是我的服务器OnUpdate也是依赖的Timer来实现的,如果OnUpdate里抛出了异常,OnUpdate就再也不会被执行了,这样就出大问题了。以前没发生过这种问题是因为我的OnUpdate代码从来没有出过错,而其他的Timer事件虽然有出过异常,但都是临时的一次性Timer,下次不会再被调度,因此掩盖了这个问题。出了这次的事故之后,我决定把这个坑填上,即使Timer事件发生异常也保证Timer可以继续被调度,因为频繁的报错总好过不知不觉的把Timer关掉,这样有利与用户查错。

那么OnUpdate怎么会抛异常的呢?继续翻阅了之前的服务器log记录,发现前面确实有好几条异常报错的log,其中有一条就是在OnUpdate里抛出来的,就是这条致命的异常log引发的血案。一般服务器在处理Bug所引发的异常时通常是采取容错策略,也就是在靠近外层的函数上接住异常,做好记录以备排查,然后把相关的用户session关闭,继续正常运行。这样的策略可以让服务器存在一些BUG的情况下依然可以健壮的运行,但也容易让人产生一些错觉。因为之前服务器已经稳定运行了很久了,对自己的代码过分的自信,所以现在很少会去检查错误log,很多Bug其实也就失去了被及时发现和修正的机会了。而前两天服务器代码刚刚更新过,有新来的同事添加过新的功能代码,引入新的BUG也是很正常的事情。亡羊补牢,根据服务器上的错误记录,把代码好好检查了一下,修正了3处会导致异常的代码Bug。然后更新版本重启服务器,才把这次的运营事故圆满的解决了。

总结一下这次的运营事故,在实践中容错策略和速错策略的权衡需要更加的小心。这次的问题是由于在服务器上更偏重容错策略,使得问题难以在第一时间被发现,虽然容错没有让这些Bug搞垮服务器,但是问题会以另一种形式呈现,最终让服务难以为继。万不可认为有了容错就可以高枕无忧啊。

posted on 2013-06-06 02:03  qiaojie  阅读(3022)  评论(5编辑  收藏