运维告诉我CPU飙升300%,为什么我的程序上线就奔溃了

线上服务CPU飙升的一次经历

前言

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

问题描述

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

问题定位

  • 首先我们先梳理下Websocket的数据发送的简单原理示意图。往往定位问题得清楚我们的逻辑是什么
  • 当一个客户端启动时除了和Websocket建立连接之外,我们还需要向Websocket服务注册当前客户端需要哪些接口的实时数据
  • 我在代码内部是通过一个Map来存储这些接口签名信息的。然后客户注册时候将这些接口和客户端绑定在一起
  • 当我们监听程序坚挺到数据变动就会对绑定到相关接口的客户端发送最新数据
image

业务定位

  • 业务上很好定位,问题就是出现在我们的监听程序中。当监听到数据给websocket客户端发送订阅的最新变动接口时就会出现CPU飙升。持续时间还很长,稍等一会就会降下来
  • 这很明显是我们推送消息的时候出现了问题
image

隔离业务看本质

  • 作为一个合格的程序员呢,必须摆脱业务才能有所收获 。业务是我们代码的外壳所有的问题基本上都是我们本质的问题。我们线上使用用户1W内。在这种的并发场景下应该是不会出问题的。现在出了问题肯定我们的程序逻辑有缺陷
image
  • 上面是我们的发送消息的代码。代码也很简单。先获取所有符合发送条件的客户端 。然后通过客户端内部提供的sendMessage方法进行推送。
  • 但是这个时候的message 是我们的接口信息。在内部会基于客户端保存的方法签名进行反射调用从而获取最新数据。在推送给客户端的
  • 在上面的代码中核心的是WebsocketManager.messageParse 。这段是获取消息然后发送。里面获取消息是基于resultful格式解析的
image
  • 这个方法内部我们有内置了我们的四种解析方式。这里我们只需要关心RequestMappingMessageParseHandlerImpl 这个协议。
image
  • 关于我们内部的协议这里也不需要太在意。这是我们自己的一个设计。根据上面的图示我们也能看的出来里面RequestMappingMessageParseHandlerImpl 是核心
image

产生原因

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

解决方案

  • 这就是量变引起质变。在多客户的情况下我们的设计弊端就暴露出来。这里也是笔者自己给自己挖坑。既然找到问题我们就好解决了。下面我们对代码做了一下改动
image
  • 我将数据缓存起来。因为在同一批次推送时本来也应该保证数据一致性。而且我们系统对数据实时性也是可以接受一定时间延迟的。我在这里又加上缓存这样就解决了我们循环的问题

  • 经过测试本次改动在CPU上大概优化了100倍。

总结

  • 功能开发完成仅仅代表功能的实验没有问题
  • 单用户和多用户完全是两种不同的用户形态。我们功能设计初期就应该尽量考虑数据量的问题
  • 唯一做的好的地方是我通过责任链模式将数据解析隔离出来。否则这样的问题定位将会更加麻烦

作者: zxhtom
链接:https://juejin.cn/post/6960795554406367269
来源:juejin

有时候一个小小的问题就会引起很大的波动现象,那么处理起来也是非常的痛楚,只有找到合适的方法,这次笔者自己给自己挖坑,在这里做了一下记录。特别是在高并发到的时候,小问题会带来更大的麻烦。

技术github学习地址:https://github.com/codeGoogler/JavaCodeHub

程序员编程书籍:https://github.com/codeGoogler/ProgramBooks

关于如何学习Java,一方面需要不断的去学习,把基础知识学扎实,另一方面也要认识到java的学习不能仅仅靠理论,更多的是靠实操,所以要多练习多做项目,在实践中学习才是最好的学习方法。很多人刚开始不知道怎么去学习,这里我将一些重要的技术文章整理到了github上开源项目上,希望能给大家带来一些帮助,项目是:JavaCodeHub

另外,还整理了一些针对于程序员的编程书籍项目,都放到了github上面,项目为:ProgramBooks 需要的话可以自取。地址:https://github.com/codeGoogler/ProgramBooks

如果github访问太慢?我同时也把去放到了码云上面ProgramBooks

最后,照旧安利一波我们的公号:「终端研发部」,目前每天都会推荐一篇优质的技术相关的文章,主要分享java相关的技术与面试技巧,我们的目标是: 知道是什么,为什么,打好基础,做好每一点!这个主创技术公众号超级值得大家关注。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,126评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,254评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,445评论 0 341
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,185评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,178评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,970评论 1 284
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,276评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,927评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,400评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,883评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,997评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,646评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,213评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,204评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,423评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,423评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,722评论 2 345

推荐阅读更多精彩内容