标签：INFO 12 06 记录 08 05 WebViewActivity 排查 多端
我们组会负责后端的一些服务，因此出现问题时不仅仅是界面的样式兼容问题，还有很多其他的后台服务问题。
排查后面这类问题，需要具备些服务端的排查手段，否则就会难以定位问题所在。
一、聊天问题
公司有一个即时聊天的功能，在 6 月 2 日周五，上了一个自动推送个性文案的功能，大受好评，访问量迅速蹿升。
UV 一度增加了六七千，在高兴的同时，问题也接踵而至，例如匹配不到聊天对象、跳转页面时卡住白屏和聊天界面卡顿问题。
其实这些问题之前也存在，但因为用户量小，没有被大规模的曝光。
这次用户量上来后，在 3、4、5 号端午三天，客服不间断地收到投诉。由此可见，量大后，再小的问题也会被放大。
鉴于问题的表现都是在我们 Web 这一端，所以需要我们先进行排查。
排查的步骤分三步：首先需要确定问题是由哪一端触发的，其次确定问题影响范围和制定优先级，最后联合相关组一同给出解决方案。
在让其他端配合排查之前，需要先确保自己那块没有问题。
在将目前上报的所有问题分类后，发现大部分遇到的是第三个问题：聊天卡顿，这部分要安排更多的精力来解决。
1）匹配不到
当匹配不到时，就会像下图那样一直处于等待匹配中，用户不得不关闭界面。
匹配失败是因为账号被锁住了，由我们组负责优化。
在匹配时会创建一个并发锁，正常情况是3秒后过期或在某个位置解锁，但出现异常后，没有成功解锁导致用户一直处于锁住状态。
// redis原子性控制并发
async incrLock(key, option) {
const incrLock = await redis.aws.incr(key);
if (incrLock && Number(incrLock) > 1) {
return false;
}
const lockDuration = option && option.duration ? option.duration : 5;
const momentstamp = moment().add(lockDuration, 's').valueOf();
await redis.aws.pexpireat(key, momentstamp);
return true;
}
为了保证锁能过期，将过期的配置提升至if语句之前。
2）跳转卡住
这个问题非常奇怪，遇到此问题的都是安卓用户（华为、VIVO 和小米），进度条卡在下图的位置就进行不下去了。
查看客户端日志，发现其实已经请求了聊天页面（chat.html）。
06-05 12:08:12.730 1 INFO/AppForeground: WebViewActivity onCreate true 06-05 12:08:12.841 1 INFO/WebViewActivity: loadUrl https://security.xxx.me/safe_redirect?url=https%3A%2F%2Fs.xxx.me%2Fc%2F1Gf4Gf 06-05 12:08:12.867 1 INFO/AppForeground: WebViewActivity onStart 06-05 12:08:12.872 1 INFO/ChatServiceManager: startService true 06-05 12:08:12.873 1 INFO/AppForeground: WebViewActivity onResume 06-05 12:08:13.074 1 INFO/WebViewActivity: processUrl else true url:https://s.xxx.me/c/1Gf4Gf 06-05 12:08:13.394 1 INFO/AppForeground: MainActivity onStop 06-05 12:08:13.669 1 INFO/WebViewActivity: processUrl else true url:https://www.xxx.me/game/chat.html?entry=appchatpush 06-05 12:08:15.063 1 INFO/AppForeground: WebViewActivity onPause 06-05 12:08:16.064 1 INFO/AppForeground: WebViewActivity onStop
查看Nginx 服务器访问日志，发现的确在那个时刻收到了来自于客户端的请求。
url: "/game/chat.html?entry=appchatpush" not url: zh_cn and http_user_agent: MED-AL00
但是在查找脚本的请求日志时（game/js/chat.719c3c70.js 和 game/js/chunk-vendors.11311460.js），并没有发现。
由此可推断，要么就是客户端没有发送请求，要么就是服务器当时没有响应，需要客户端帮忙排查。
3）聊天卡顿
这个问题主要是客户端排查，我们组配合打印关键信息（console.warn()）。
后面我们对页面脚本也做了一次优化，实现组件区域化的渲染，避免整个大组件的渲染。
4）异常流量
在将相关组拉在一起开会时，运维反馈，在 6 月 4 日 23:42-23:43 之间有股异常流量，而 22:00-01:00 也是公司 APP 最为活跃的时间。
这股异常流量促使短链服务和长连接发生大量的 502/503/504 的报错。
查看 Nginx 日志（如下图所示），发现有个明显的凸起高峰，也正好是在那段时间发生的。
经查，在这段时间内，进入聊天页面的埋点只收到了 1 个。运维怀疑是 api 项目的一个回调接口影响了 api 的其他服务。
6 月 6 日晚上 20 点，将此接口服务迁出，单独作为一个服务（就是路由转发），当天晚上的错误从之前的 500 多降到了 60 多。
为了弄清楚长连接发生异常时，有哪些用户受到了影响，因此在 /socket 地址上还附带上了用户 ID。
5）下一步动作
在 6 号开完会议后，就马上修复了我们这边的几个问题，以及运维的问题。
查询聊天匹配完成的曲线图，发生呈明显的上升趋势，匹配率增幅 23% 以上，这是一个让人振奋的消息。
客户端因为无法复现，所以需要添加埋点，例如增加键盘交互等事件的监听，还需要优化键盘弹出方案，这些都得发布新版本。
所以要下一个版本中解决卡顿的问题。
二、内存问题
我们组的静态资源都单独放在一台服务器中，静态资源就是图片、HTML、JavaScript 和 CSS 等文件。
运维和我反馈说，这些服务器的内存会一直涨，除非重启容器后，内存才会降下来。
我的第一反应是内存是不是泄漏了，服务器中有个聊天的页面，会不会是建立了大量的 websocket 连接，没有被释放掉。
但是转而一想，应该不是，因为这些文件会被传输到用户浏览器中，发起的连接也是存在于客户端，不会影响服务端的内存。
进入到服务器中，输入 ps aux 命令，查看正在运行的进程，发现有好多 worker process。
问运维，说这些都是 Nginx 的进程，后面就让他去优化，他改了个配置，内存增长的幅度是变小，不过依然会慢慢增长。
标签：INFO,12,06,记录,08,05,WebViewActivity,排查,多端 来源： https://www.cnblogs.com/strick/p/16363013.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。