前言

文本已收录至我的GitHub仓库， 种一棵树最好的时间是十年前，其次是现在

大家好，我是小六六，目前在一线互联网公司负责年营收过百亿的支付中台项目，感谢大家的支持，今天我们来看看 线上服务CPU飙升的问题

絮叨

• 功能开发完成仅仅是项目周期中的第一步，一个完美的项目是在运行期体现的
• 今天我们就来看看笔者之前遇到的一个问题CPU飙升的问题。代码层面从功能上看没有任何问题但是投入使用后却让我头大

问题描述

系统上点击数据录入功能在全局监控中会收到相关消息的通知。此时服务器CPU飙升300%

问题定位

• 首先我们先梳理下Websocket的数据发送的简单原理示意图。往往定位问题得清楚我们的逻辑是什么
• 当一个客户端启动时除了和Websocket建立连接之外，我们还需要向Websocket服务注册当前客户端需要哪些接口的实时数据
• 我在代码内部是通过一个Map来存储这些接口签名信息的。然后客户注册时候将这些接口和客户端绑定在一起
• 当我们监听程序坚挺到数据变动就会对绑定到相关接口的客户端发送最新数据
• 上面是我们的发送消息的代码。代码也很简单。先获取所有符合发送条件的客户端 。然后通过客户端内部提供的sendMessage方法进行推送。
• 但是这个时候的message 是我们的接口信息。在内部会基于客户端保存的方法签名进行反射调用从而获取最新数据。在推送给客户端的
• 在上面的代码中核心的是WebsocketManager.messageParse 。这段是获取消息然后发送。里面获取消息是基于resultful格式解析的

  产生原因

  • 上面我们简单的梳理了下代码的逻辑。
  • 仔细分析下我们是遍历所有客户端然后在反射调用接口数据进行返回的。实际上在消息推送时我们没必要在每个客户端内部调用数据。我们完全可以先调用数据然后在遍历客户端进行发送。
  • 这也是导致CPU过高的问题。我们1W个用户同事在线的可能有5000+ 。那么我们需要5000次以上的反射着肯定是吃不消的。这也是为什么本文开头说功能正常不代表业务正常。

  解决方案

  • 这就是量变引起质变。在多客户的情况下我们的设计弊端就暴露出来。这里也是笔者自己给自己挖坑。既然找到问题我们就好解决了。下面我们对代码做了一下改动