高并发系统设计 40 问
唐扬
美图公司技术专家
49013 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
高并发系统设计 40 问
15
15
1.0x
00:00/00:00
登录|注册

春节特别策划 | 高并发下如何发现和排查问题?

压测也是一种常规的发现系统问题和隐患的手段
格外重视客户端监控
欢迎分享实战经验
熟悉常见的分析工具会让我们的问题排查过程事半功倍
利用监控和日志,总结出问题的共性特点,是我们排查问题的主要手段
监控和压测是发现系统性能问题的两个最重要的手段
常见工具也是问题排查的重要手段
需要做一些归纳总结,针对性地分析问题发生的一些共性特点
问题排查的主要手段:监控和日志
全链路压测发现Redis组件问题
客户端监控发现带宽超出导致接口响应时间缓慢
主要手段:监控和压测
墨菲定律:事情有变坏的可能性总会发生
高并发环境下问题可能迅速恶化
一课一思
课程小结
排查问题的方法
实际案例
如何及时发现问题
为什么要讲这个问题
高并发下如何发现和排查问题

该思维导图由 AI 生成,仅供参考

你好,我是唐扬,新年快乐!
过年嘛,都要吃好玩好,给自己一年的辛苦付出“加餐”,那咱们的课程也不例外,在新的一年里,我为你策划了两期加餐,今天先来聊聊在高并发下,我们如何发现和排查问题。
为什么要讲这个问题呢?是因为我在课程结束之后,发现有同学反馈说:
虽然课程里几乎涵盖了高并发系统设计的全部方面(比如数据库、缓存和队列的使用、分布式系统主要组件的原理,以及系统运维方面需要关注的重点),但自己按照课程中提供的方式正确使用了组件,在实际工作中仍然会发现系统中各种各样的问题,比如服务性能衰减、依赖资源的抖动甚至是服务整体故障。
尤其在高并发环境下,由于并发请求更多,对于资源和服务的压力更大,所以原本隐藏在冰山下的问题又都会在某一时间突然浮出水面。
这其实就像墨菲定律说的那样: 如果事情有变坏的可能,不管这种可能性有多小,它总会发生。这不是一个数据概率问题,也不是一个心理学效应,而是一种必然的法则。
在高并发场景下,一些细微的问题可能会迅速恶化,并且对系统中多个模块的 SLA 带来巨大的影响。比如,业务仅仅缓存的平均响应时间增加 1ms 或者缓存命中率下降 1 个百分点,都会带来灾难性的影响。这不仅增加了问题排查的难度,也对问题排查的及时性提出了更高的要求。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在高并发环境下,系统中的细微问题可能会迅速恶化,对系统的多个模块的SLA带来巨大影响。本文介绍了在高并发场景下如何发现和排查问题。作者提到了两个主要手段:监控和压测。他强调了客户端监控的重要性,因为它最能真实反映用户的使用体验。作者分享了在项目中发生的事情,以及在云上部署的服务中发现的问题。通过全链路的压力测试,作者发现了Redis组件的隐藏问题,并解决了这些问题。总的来说,本文强调了在高并发环境下,及时发现和排查问题的重要性,以及监控和压测在此过程中的关键作用。 在排查问题方面,文章提到了监控和日志是主要的排查手段,而针对性地分析问题发生的一些共性特点也是重要的。此外,熟悉常见的分析工具也会让问题排查过程事半功倍。作者还分享了一些常见工具的使用方法和场景,以及在实际工作中的经验。最后,文章强调了问题的排查过程虽然痛苦,但每一次的排查经历都是在为下一次排查积累经验,同时也能让人更加熟悉工具的使用。 总的来说,本文为读者提供了在高并发环境下发现和排查问题的方法和手段,强调了监控和压测的重要性,以及熟悉常见分析工具的必要性。通过作者的实战经验分享,读者可以获得宝贵的排查问题经验和技巧。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统设计 40 问》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(6)

  • 最新
  • 精选
  • 每天晒白牙
    感谢老师春节更新,我在工作中排查过几次cpu占用高,频繁fgc的问题 https://mp.weixin.qq.com/s/ji_8NhN4NnEHrfAlA9X_ag https://mp.weixin.qq.com/s/IPi3xiordGh-zcSSRie6nA https://mp.weixin.qq.com/s/fWsy26VeUvb8yPKON3OTmA

    作者回复: 赞 总结很赞~

    2020-01-24
    32
  • Lane
    遇到过几次诡异问题。 明天零晨两点,服务器报警,看监控每天都这个点,以为crontab占用资源,后来发现,这个机器ping别的机器丢包严重,换网线好了。 重启服务报端口被占用,发现ffpemg的组件ffprobe也listen端口(是被服务用exec启的ffmpeg)。 有台新机器,基本上每天有十秒钟没有请求(nginx没有access.log),换网线网卡重装系统升级了内核,就是找不到原因,dmesg也没报错。 真叫人头秃

    作者回复: 👍,经验丰富~

    2020-02-08
    3
  • helloworld
    确实是,遇到问题,解决问题是提升自己的最快的方式,并且如何在遇到问题时不恐慌耐得住性子来排查问题也是需要好好学习锻炼

    作者回复: 排查问题就是一场修行,技术和性格的双重修行。

    2020-08-05
    2
  • 各种各样的业务问题排查过不少,还分门别类的整理起来写了一个问题排查手册,性能调优、网络超时、连接池超时这些问题也排查过,不过特别诡异的好像没有。 业务问题看对系统及业务的了解程度,系统问题看自己的基础知识,个人感觉日志太关键了,尤其对于不好复现的问题,公司如果基础设施好,排查问题的工具都是界面化傻瓜式操作能提高不少排查问题的效率,否则就看自己对各种工具的熟练程度了。 前几天还排查了一下使用Gosn和HikariCP的问题,Gosn是识别数据全部转换为Double在转Long会存在丢失数据精度,HikariCP的参数设置不对会出现连接不可用的问题,马上又要开始排查一下系统老报连接超时的问题了。 排查问题其实挺有意思的,尤其是大家觉得不好弄就这样吧!然后绞尽脑汁能把问题解决,即使没人点赞也很开心。
    2020-05-10
    3
    14
  • 小胡
    感觉提供的案例问题很好解决,比如那个服务器系统时间的问题,正常人都会想到的
    2021-09-05
    1
  • ちよくん
    消费重复消费
    2020-01-27
收起评论
显示
设置
留言
6
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部