服务器端使用了一套新的框架开发了对弈体系及相关服务,App端对弈首先迁移到了这套新的对弈体系下,从迁移后就有用户一直反馈超时负、断线负等各种问题,最初服务器端都以为是手机端网络不稳定导致的,也没细查。后来为了对弈互通,PC端也接入了这套对弈体系,出现很多用户上报超时负等各种问题。在PC客户端增加了提取日志功能,当用户反馈超时等问题时,提取下最近日志,通过日志分析,是网络延迟太大导致的问题,有的延迟回达到2分钟甚至更多,后来增加了心跳间隔上报机制,从上报的数据来开,有很多心跳延迟都很大的数据,可以确定问题是网络数据延迟导致的,针对这种网络延迟做了如下分析。

1、增加PC端原有体系心跳与新框架心跳间隔数据同时上报,通过分析同一时刻的心跳数据确定是否真的是网络问题。由于PC端原有体系没有心跳反馈机制,客户端根据其中获取服务器时间做了一个假的心跳,获取系统时间在服务器端是在数据库线程中处理的,实际上无法确定的反馈当时的网络情况,因为数据库线程有时压力比较大。同时服务端对上报的数据处理也有点问题,取了每个包的最大、最小、平均时间,一旦发生了数据延迟,会出现PC的心跳与新框架的心跳就对应不上了。但是,服务器端这里一直认为数据处理的没有问题,而且从数据分析来看这种延迟是网络问题。

2、服务器端考虑可能是负载均衡的问题,负载均衡是腾讯云提供的一种服务,就把负载均衡层去掉了,客户端直连网关服,通过前后数据对比发现网络数据延迟现象没有任何改善。其实腾讯云能把负载均衡当成一种产品提供,本身应该是不会出现这种问题的。

3、服务器端考虑可能是网络问题,就是网络当时确实不好。把其中一台网关服单独拿出来,接入了腾讯云的anycast(IP就近接入腾讯云,由腾讯云内网路由到服务器),经过数据对比发现情况稍微好了点,但是好的有限。

个人一些观点:

1、其实首先要考虑的是新框架是否稳定,有没有成熟的产品在使用这个框架,这个框架有没有经过大规模的测试?

2、能否更换新框架的网络层后,拿出几台网关服与原有网关服做数据对比?

3、有次会议上说网关服的机器配置是2核的,觉得可能是网络连接高并发处理问题,后来仔细问了下,新框架的网络层是epoll+单线程实现模式,网络数据收发及逻辑层处理都在一个线程中,那么会不会是高并发处理能力有问题,高峰期单台网关服平均连接数会达到1000,能否那一台出来指定连接数为不超过100,然后做数据对比?

可惜这些服务器端没有人去尝试,现在都一致认为就是网络延迟问题,先记录下来,看后续如何处理吧。

 

一些用户反馈事例记录如下:

2020年10月29日

用户对弈2局都超时负,提取用户客户端日志,发现从11:37-13:11,新框架接入服网络连接断开重连了172次,PC原有网络一直很稳定;

2020年10月30日

用户反馈对方落子后自己立刻超时了,提取用户客户端日志,发现网络数据延迟的很厉害,对方落子和对局结束几乎同时到达,在新框架网络延迟时间端内PC原有网络一直很稳定;