游戏服务端防御式开发

游戏服务端承担着游戏复杂业务逻辑实现,玩家数据持久化等重要作用。作为一个合格的服务端业务狗,我们有必要遵守一些好的防御手段,让自己的代码少踩些坑,或者当出现了bug,能够在第一时间进行抢救。

下边一些开发原则是我的经验总结,欢迎补充,不喜轻喷o(^_^)o\

  •   检查玩家请求数据的有效性

不管是做web后端,还是游戏后端开发,我们都要检查客户端请求数据的有效性。举个栗子,假设玩家在商店买了一个道具XX,数量为100。对于上传到服务端的参数,例如所购买的道具id和购买数量,我们需要重点检查购买数量参数。总不能玩家说要买100个,但是玩家的金币只能购买10个,服务端就傻傻地给了玩家100个道具吧!

有经验的程序员总是不厌其烦地告诉新手程序员,必须对传入函数的参数进行有效性检测。类似地,我们也必须对玩家的各种请求参数进行检测。很多外挂工具可以直接模拟游戏上一次发包内容,甚至通过对数据的分析进行参数篡改。所以,我们对于直接处理用户请求消息的逻辑方法,应该进行相关有效性检查。

  •   重视行为日志

策划童鞋的脑洞很活跃,有时一些业务流程性非常强,要达到目标往往需要多个步骤有序地完成。我们做开发的,在面对一些强流程性或者数据比较重要的逻辑,一定不要吝啬留下行为日志。打多点日志,出了问题,即使测试人员无法重现,我们也可以根据日志以及代码逻辑发现问题。

当然,打日志也是有技巧的。由于日志是给开发人员自己调试排错的,我们没必要像写作文一样下笔有神,我们只要打印一些关键的行为字眼以及相关参数值。对于同一个模块,我们最好采用相同的前缀作为关键字。这样,当需要查询的时候,只要输入模块前缀以及玩家id,就能清晰地查看完整的流程行为。

  •   合理使用锁

java的线程同步机制主要靠锁。不合理地使用锁,容易引起死锁。如果出现死锁,一般需要重启服务。如果你把服务搞垮了,就准备扣绩效吧。我们可以通过一些保守的策略,尽量减少发生死锁的可能。

一些比较好的方法有如下:
      -   尽可能使用有超时中断的锁,例如ReentrantLock.tryLock()方法。
      -   尽量避免锁里有锁,有时我们为了细化锁的粒度,采用了在一个锁变量里面再使用另外一个锁变量,这种情况最容易发生死锁了。我们可以直接在最外层代码用一个大锁代替里面多个小锁。有时,为了代码更可控,宁可牺牲一些性能。

  •   在别人的方法里加逻辑,请用try.catch()进行包装

游戏业务其实就是功能的堆砌和业务的修改。很多时候,我们经常需要在别人的模块里面加上自己的业务。这个时候,别忘了将自己的代码写在try.catch里面。这样可以保证,当我们的代码发生异常,不会打断已有的逻辑。

  •   不要在循环内部向客户端推送消息

由于客房端在每一帧拆包的数量是有限的,如果在循环体内向客房端下发消息,会导致客户端拆包速度处理不过来,造成卡顿效果。如果确定需要在循环体内处理业务逻辑,可以把每一次迭代的中间结果收集起来,最后统一发下去。

  •   给自己的功能加个开关

在实现一些自己没什么把握的功能,我们可以在这些模块加个对应的功能开关。这些开关其实就是一个简单的布尔变量,当变量为false的时候,我们就不让代码继续往下跑了,同时告诉玩家,该功能暂时关闭。至于怎么切换开关,可以使用管理工具或修改内存的脚本。

  •   有实现热更新代码的机制

不管是多牛逼的程序员,只要是代码,就有可能出现bug。我们更关心的是,当真的出现bug的时候,能够在不重启服务器的情况下,进行代码修复。代码热更新是一个大的话题,有很多机制可以实现,在这里就不展开了。

本文转载自:博客园 - 叶哓飞,版权归原作者所有

--电子创新网--
粤ICP备12070055号