游戏服务端防御式开发

标签: 游戏服务端防御开发
779人阅读 评论(0) 收藏 举报
分类:

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

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

  • 检查玩家请求数据的有效性
不管是做web后端,还是游戏后端开发,我们都要检查客户端请求数据的有效性。举个栗子,假设玩家在商店买了一个道具XX,数量为100。对于上传到服务端的参数,例如所购买的道具id和购买数量,我们需要重点检查购买数量参数。总不能玩家说要买100个,但是玩家的金币只能购买10个,服务端就傻傻地给了玩家100个道具吧!
有经验的程序员总是不厌其烦地告诉新手程序员,必须对传入函数的参数进行有效性检测。类似地,我们也必须对玩家的各种请求参数进行检测。很多外挂工具可以直接模拟游戏上一次发包内容,甚至通过对数据的分析进行参数篡改。所以,我们对于直接处理用户请求消息的逻辑方法,应该进行相关有效性检查。
  • 重视行为日志
策划童鞋的脑洞很活跃,有时一些业务流程性非常强,要达到目标往往需要多个步骤有序地完成。我们做开发的,在面对一些强流程性或者数据比较重要的逻辑,一定不要吝啬留下行为日志。打多点日志,出了问题,即使测试人员无法重现,我们也可以根据日志以及代码逻辑发现问题。
当然,打日志也是有技巧的。由于日志是给开发人员自己调试排错的,我们没必要像写作文一样下笔有神,我们只要打印一些关键的行为字眼以及相关参数值。对于同一个模块,我们最好采用相同的前缀作为关键字。这样,当需要查询的时候,只要输入模块前缀以及玩家id,就能清晰地查看完整的流程行为。
  • 合理使用锁
java的线程同步机制主要靠锁。不合理地使用锁,容易引起死锁。如果出现死锁,一般需要重启服务。如果你把服务搞垮了,就准备扣绩效吧。我们可以通过一些保守的策略,尽量减少发生死锁的可能。
一些比较好的方法有如下:
尽可能使用有超时中断的锁,例如ReentrantLock.tryLock()方法。
尽量避免锁里有锁,有时我们为了细化锁的粒度,采用了在一个锁变量里面再使用另外一个锁变量,这种情况最容易发生死锁了。我们可以直接在最外层代码用一个大锁代替里面多个小锁。有时,为了代码更可控,宁可牺牲一些性能。
  • 在别人的方法里加逻辑,请用try.catch()进行包装
游戏业务其实就是功能的堆砌和业务的修改。很多时候,我们经常需要在别人的模块里面加上自己的业务。这个时候,别忘了将自己的代码写在try.catch里面。这样可以保证,当我们的代码发生异常,不会打断已有的逻辑。
  • 不要在循环内部向客户端推送消息
由于客房端在每一帧拆包的数量是有限的,如果在循环体内向客房端下发消息,会导致客户端拆包速度处理不过来,造成卡顿效果。如果确定需要在循环体内处理业务逻辑,可以把每一次迭代的中间结果收集起来,最后统一发下去。
  • 给自己的功能加个开关
在实现一些自己没什么把握的功能,我们可以在这些模块加个对应的功能开关。这些开关其实就是一个简单的布尔变量,当变量为false的时候,我们就不让代码继续往下跑了,同时告诉玩家,该功能暂时关闭。至于怎么切换开关,可以使用管理工具或修改内存的脚本。
  • 有实现热更新代码的机制
不管是多牛逼的程序员,只要是代码,就有可能出现bug。我们更关心的是,当真的出现bug的时候,能够在不重启服务器的情况下,进行代码修复。代码热更新是一个大的话题,有很多机制可以实现,在这里就不展开了。有兴趣的同学可以参考我一篇文章->手游服务端代码热部署

1
0

猜你在找
【直播】机器学习&数据挖掘7周实训--韦玮
【套餐】系统集成项目管理工程师顺利通关--徐朋
【直播】3小时掌握Docker最佳实战-徐西宁
【套餐】机器学习系列套餐(算法+实战)--唐宇迪
【直播】计算机视觉原理及实战--屈教授
【套餐】微信订阅号+服务号Java版 v2.0--翟东平
【直播】机器学习之矩阵--黄博士
【套餐】微信订阅号+服务号Java版 v2.0--翟东平
【直播】机器学习之凸优化--马博士
【套餐】Javascript 设计模式实战--曾亮
查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:101500次
    • 积分:1421
    • 等级:
    • 排名:千里之外
    • 原创:41篇
    • 转载:0篇
    • 译文:0篇
    • 评论:27条
    博客专栏
    最新评论