这几天在把几个副本活动从之前的本服转化到跨服，需要对一些代码的改动。由于这几个之前不是我写的，然后大概看了下其中一个代码，大概有一千五百行，为了不影响原有功能和减少重复代码的工作，先对一些模块进行重构，删除不必要的阻塞调用和重复判断，因为阻塞会挂起导致后面的判断复杂化，把原有的三个call改成一个call+send就行，不改变原来逻辑的意思。以及服务间的消息传递，最后测试多次没有异常便开始进行新功能的开发。和我之前的设计不一样，之前几个大型pvp/pve把本服改成跨服不需要改动太多，然而这几个当在跨服上时，有些模块是不开启的，那么有些数据是无法直接获取，这块如果简单粗暴就同步，但这会带来性能和不必要的存储，只能考虑其他方案，再如果设计过于复杂的方案可能不划算，延长工期。
差不多花了三天，中间也处理一些线上问题。加上跨服，代码行数跟之前差不多。只改动几个文件，其他的不动，目前的方案还是比较适合业务需求。另外，涉及到跨服排行数据，由于并不是很满意之前原有的同步数据，有更好的方案且简单，所以就自己写了下，也就十几行代码，这样减少因为要考虑同步数据可能导致不一致的情况不而引入一定的复杂度。
这中间其实还遇到一些边界情况的考虑，由于之前这么实现可能为了获取最新数据，但是在跨服上有些问题久比较棘手，为了性能还是复杂化？包括合服或者网络波动一些异常导致上层逻辑做的反馈。当然，这些都解决了，综合权衡可以选择比较合理的方法，总之。
上次总结到有个资源释放的问题，本以为是double release，加了判断和打印并没有出现这些info日志。并且跟踪线上报错时，发现还是出现那样的问题，但就一个。仔细查看上下文的日志，后来发现根本问题所在，分析复现的方法，然后本地复现出来了，过程挺复杂的，还是跟消息的时序有关系。当自己想着有没有什么好方法修复，可能最后方案并不特别满意，leader想出一种，简单些多，最后解决之。其实，这个问题就是数据状态不一致，本来我占有这个资源，那么资源的状态肯定是有效的，而现在资源释放，此时状态还是有效导致别人占有该资源时，本期望状态无效并自己初始化，所以这里有问题，还挺严重的。
这个问题是在重进游戏时并断开处理时出现的，因为是两条消息操作，所以后一条消息比前一条消息先到达，所以造成先处理release，然后后一条消息处理时，发现fd关联的信息没了所以出问题了，具体情况不细说，因为跟后台框架相关。
今天主要是想聊聊为什么在游戏中会卡顿。这个问题之前出现过，但偶现的。后来在某个版本上线出现玩家手机端大面积卡顿。具体就是进某些副本，然后转圈，而PC模拟器进同样的副本没有什么问题，所以这里比较奇怪，代码也是一样的。后来用手机Wi-Fi连那个服，然后进对应的副本，大概二十来人，平均延时两三百毫秒，因为是国外服务器，这个数据应该比较合理？猜测是不是网络问题。因为pc走的是网线，手机可能是3g/4g/wifi这样的情况，不稳定。
查看日志，发现动不动就断线重连，日志中好些connection timed out和reset by peer这样的底层socket错误，使得底层网络框架关闭此连接。是什么情况导致这样的呢？因为在腾讯上线一年，tw上线大半年没有这样的问题反馈。然后收集客户端报错日志，并没有明显的发现。也或者可能流量太大？但不应该啊，进一个至多五人的组队副本，也会发现这样的情况。其中也会偶现怪愣住的情况，大概两三秒样子，猜测可能服务器没发包下来，也可能客户端忙没有及时处理包，导致接收缓冲区窗口关闭。
因为玩家那边反馈来的具体情况描述不是特别清晰，比如什么网络模式，哪个时间段，同一个副本中是否有其他玩家也反馈，当时手机是否开了过多的应用等。因为可能在游戏的过程中，会有其他后台应用会发送一定量的数据包，那么当用户的网卡那边积累的数据包数量到达一定后，就可能出现数据发送不稳定，错包率上升等现象，进而导致游戏过程中数据的交互受影响，所以这些可能的原因都有。
有些复杂情况是很难分析和复现的，如果复现还可以有解决方案，其他情况只能靠猜测，然后本地尝试复现和解决，可能并不是对应的问题。
网友评论