这个周末加了两天班，因为在删档付费测试时，有几个比较影响用户体验的bug修复了下。在测试的时候没有测试出来反而在现上才暴露出问题，真的不应该。
仔细分析了下，是跟一个字段有关系，而我负责的模块是经济系统，计算收益需要使用到离线时间，如果不能正确设置，那么会造成无限刷bug，但是为什么没有正确设置离线时间而由另一个玩法的bug导致卡loading不得不走导致走重新登陆流程，所以我这边暂时不依赖于那个字段，自己用个字段设置最新的更新时间。（复现方法是需要故意让它卡loading然后强制重新登陆）
还有一个世界boss的bug，模块不是我负责的，同事不在，帮忙修复了下，主要还是在一种临界情况下才出现的因时序问题引起的，导致旧数据影响到后面的数据，虽然这块跟玩家数据没有关系，只是显示而已，但玩家可能感觉怪怪的，还没开始就有数据，而且不正确。
另外一个bug还是由其他模块的bug引起的，导致我这边没有判断好，而底层lua遇见报错后就不再继续执行后面的流程，下一次在触发时，数据还在里面，没有清除。这里为了防止无限刷错误栈日志，在结束的时候重置了callback函数集合，另一方面对副本进行隔离，这样如果报错，只会对当前这次活动有影响，这样从三个维度去解决。
还有code review其他同事的修复bug的记录，主要还是有些模块耦合性太高，导致一个模块出bug，其他模块可能会受影响，如果进行解耦，会好一些，但这样可能引入其他复杂性… 一些临界情况没有测试到，或者操作序列导致的，修bug的路还很长…
当时还排查一个负载过高的问题，不是服务器负载过高，而是有的agent和场景消息队列消息过多导致overload的情况，在一场战斗处理中，有四十多个玩家和三十多只怪，引起客户端的卡顿情况（猜测是不是消息过多，一方面处理不过来，进而没有及时从接受缓冲区读数据，导致数据积压过多，关闭窗口，服务器那边数据发送不出去，导致队列出现负载。我这边对客户端网络层代码打印了些日志。每次去收包的时候，打印下队列中有多少条消息。（之前文章记录优化百人PK的时候，没有出现过overload情况，可能是除了当前账号是真实玩家，其余是机器人并没有客户端，况且当处理队列中的消息时，当积压过多，可能后面的消息超时或者无用，那么会白白浪费资源。）确实出现写套接字的时候是暂时写不了，但这个不是最终原因，详细分析会在后面记录下。
另外在看phxqueue的分布式锁，看了下redlock的实现和几篇批评它不安全的文章，改天总结下。
网友评论