前言，这段时间主要是解决线上问题和bugs，虽然游戏上线半年，还是有一些bug反馈到这边，另一方面还接一些新的需求。在排查线上问题时，根据反馈来的一些不全信息，然后去看相关不熟悉代码，没有关键信息，比如xx补偿没有收到，如果在记录日志时有xx关键字就会很方便了，但没有的话只能根据其他信息反向推。
见过最多的问题是xx补偿/福利没有，然后一查日志是有的，这就是玩家设坑想多拿游戏中的道具。但其中也遇到一些偶现的bugs，在本地测试无法复现，然后其他玩家反馈时，问下当时怎么操作的也说不上来。比如技能数据为什么重置，我能看到其他帮派的聊天信息(有内鬼，取消交易)等。
因为信息不完全，然后问下客户端同学说技能数据没有同步下来，所以使用了默认数据。我把线上玩家数据拉到本地登录是没有问题的，然后也不太好复现这个严重的bug。后面一个问题拉日志时，并没有找到明显的错误，因为只出现过两次，且都在跨服上，就这两个信息，后来拉取到的日志却发现其他问题。
简单说就是因为负载高，玩家本来在跨服上，然后杀掉进程后又重进游戏，此时是重连。这个请求发出去后该协程被挂起，然后又来一个退出游戏的请求(杀掉进程)，导致对同一个对象的处理，先释放掉本地的对象，前一个请求被回应时断言失效，这样就导致跨服上的资源没有收回，然后如果有其他玩家重用本地对象时，跨服上的数据同步过来造成其他严重问题。这个问题之前记录过，就是本应该串行化的操作同一个对象，但因为是协程就不能保证先判断成功的条件过段时间还是成功。
因为昨天晚上有反馈说跨服上卡顿，延迟很大无法操作。然后今天查看日志和监控发现，cpu和内存不高，但网络出口流量非常大，导致网络线程处理不过来。之前优化过相关的业务逻辑和底层框架，之前是cpu百分之百完全处理不过来，然后测试后没什么问题，和今天的问题不一样。
我查看日志，这半小时内，有九百人左右在打某类副本，二十五对二十五，还有三四百人打其他类副本，也是多人副本。因为再优化代码就不太好办，影响正确性，只能再加一台机器作为跨服，引一部分人去新跨服。
之前我做过统计，因为历史原因，某些包量特别特别大，虽然之前弄掉一小部分，但还有很多。查看客户端和服务器相关实现代码，实在是太复杂，太多的逻辑，本来很简单的逻辑，写了很多逻辑，所以现在想来cpu高，客户端手机可能的发烫也很可能与这些实现有关系。
而且很多逻辑是相关联系的，耦合性太大，不太好拆分。比如有开始就有结束操作，那不能删除开始或结束操作，不然客户端表现怪怪的，为了优化而影响正确性。但这里本就可以用一个简单的实现来省略很多不必要的逻辑和数据包。因为牵扯到太多的逻辑，一改要改很多，又引入潜在bugs和报错，莫名其妙的问题，就暂时让它们这样吧。
所以我觉得，如果要实现一个功能，先简单写，把逻辑写清晰，这样后面再加代码或者修改等也很方便。一个协议约定时，看下有些数据是否真必要，比如cdstarttime和cdendtime弄成一个cddurationtime不就好了？太过于复杂的逻辑会很容易出问题或者给其他同学维护解决问题时带来困惑。
我觉得，不光是熟悉自己的业务，还是要多花点时间去看看一些知名的开源，学些不错的设计，这样也能在以后可能用的上，比自己想的方案更好。
网友评论