最近经常在朋友圈发关于黑色星期五的状态，这缘于合规性的要求导致每到周末或者节假日的20点系统会面临一波流量高峰（约为常规流量的5倍左右），4核CPU的虚拟机负载最高被打到20左右，伴随着一波告警和各方业务大佬的亲切咨询。
截止今天晚上（周六）20点的流量高峰，系统已经平稳的扛住了两次的流量高峰，整体系统的负载响应时间等一切指标都非常平稳，目前应该可以自信的拍着胸脯说报警已经解除。顺便总结整个问题解决的过程。
应对流量高峰的最佳实践指导思想是限流扩容，任何一个系统无外乎这两个套路。每晚20点我们有两个系统会遇到流量突增，一个是核心和登录相关的系统，一个是业务的查询系统。针对登录系统我们的理念就是扩容来硬抗，针对业务查询系统通过限流来解决。这个原则考量对业务的取舍，对于游戏来说优先保证用户登录能够正常游玩是第一原则，在登录的高峰期一些游戏相关的周边信息则不那么重要，参考电商的双11亦是如此。
当然如果仅仅通过机器扩容限流就解决了问题那么就没有必要花时间来分析整个过程了。其实中间还是经历了几次迭代。
阶段一：我们其实就是直接简单粗暴的扩容机器，按照成倍的机器去扩容，最初的8台扩到24台，但是一到流量高峰期机器负载依然被打的非常高，从理科生的逻辑上来讲完全不符合理性推理。
阶段二：开始分析各类监控指标，发现在流量高峰期有大量blocked 状态的阻塞线程，包括数据库获取连接的阻塞；大量 synchronized关键字导致的阻塞（代码里面全局搜索没有找到synchronized关键字），联合压测的同学开始第一轮模拟压测主要来定位大量 blocked 线程的原因。压测后对数据库的连接参数进行了调整，同时推动公司内部第三方公共包的同事优化了一波第三方依赖包。至此我们完成第二阶段的调整。
阶段三：开始梳理业务逻辑，分析在20点的流量高峰期哪些业务可以进行降级，因为在登录的过程中只要保证登录能够正常，其他的体验类的功能是可以有选择的进行降级的。然后以20点作为起点的N分钟内降级了体验类功能（N 分钟按需可配）。
经历了上述的3个阶段我们已经阶段性的能扛住高峰期的流量了，但是整体的响应时间还是不是特别理想（40ms增长到600-800ms）。所以继续了下一波的优化。
在前两次的实际流量高峰期我们发现了针对登录这个场景，如果自动登录的成功率高了那么手动登录的流量就不会突增。这其实就是一个典型的业务场景，只要能够保证第一波访问流量的成功率那么就不会有第二波流量高峰，之前是因为没有扛住第一波自动登录的流量高峰，导致很多用户选择了手动登录引起第二波流量高峰。
在这个业务理解的基础上，我们发现其实我们的监控流量其实是有1分钟左右的滞后性的，所以针对20点这个场景其实很多用户并没有选择在20点就开始登录，他们可能选择提前几分钟就开始尝试登录了。从下游系统的调用量上来看的确也是如此。
阶段四：开始尝试把开始降级的时间往前提早N 分钟（N 分钟可调），同时顺带决定把某个变更登录状态的 DB 写入同步降级掉。最终线上验证效果非常良好，响应时间在流量高峰期几乎保持40ms 没有变化（因为降级了服务略微还有些下降）。至此基本上事情算告一段落了。
回顾一波整个过程，结合实际情况而言，在业务的团队以业务的角度出发解决各类问题其实是一个低投入高产出的选择，不能一上来就选择走各种技术优化（可能效果反而不理想）。
最后终于以后不用再守20点的流量高峰期了。
网友评论