面试官:遇到过什么系统故障?怎么解决?看完后能轻松应对

本文作者结合15年的互联网研发经验,分享了遇到的八大系统故障案例,包括JVM FULL GC、内存泄漏、幂等问题、缓存雪崩、数据库死锁等,提供了解决方案。此外,还赠送2020年互联网大厂面试题及高端简历模板。
摘要由CSDN通过智能技术生成

很多人在面试时,会被问到这样的问题:遇到过什么系统故障?怎么解决的?下面是笔者根据自己15年互联网研发经历总结的多个线上故障真实案例。相信可以帮你从容应对面试官的提问!

本文图不多,但内容很干!理解为主,面试为辅,学以致用!添加小助手VX:xuanwo008即可获取2020年互联网大厂真实面试题

故障一:JVM频繁FULL GC快速排查

在分享此案例前,先聊聊哪些场景会导致频繁Full GC:

  1. 内存泄漏(代码有问题,对象引用没及时释放,导致对象不能及时回收)
  2. 死循环
  3. 大对象

尤其是大对象,80%以上的情况就是他。

那么大对象从哪里来的呢?

  1. 数据库(包括Mysql和Mongodb等NOSql数据库),结果集太大
  2. 第三方接口传输的大对象
  3. 消息队列,消息太大

根据多年一线互联网经验,绝大部分情况是数据库大结果集导致。

好,现在我们开始介绍这次线上故障:

在没有任何发布的情况下,POP服务(接入第三方商家的服务)突然开始疯狂Full GC,观察堆内存监控没内存泄漏,回滚到前一版本,问题仍然存在,尴尬了!!!

按照常规做法,一般先用jmap导出堆内存快照(jmap -dump:format=b,file=文件名 [pid]),然后用mat等工具分析出什么对象占用了大量空间,再查看相关引用找到问题代码。这种方式定位问题周期会比较长,如果是关键服务,长时间不能定位解决问题,影响太大。

下面来看看我们的做法。先按照常规做法分析堆内存快照,与此同时另外的同学去查看数据库服务器网络IO监控,如果数据库服务器网络IO有明显上升,并且时间点吻合,基本可以确定是数据库大结果集导致了Full GC,赶紧找DBA快速定位大SQL(对DBA来说很简单,分分钟搞定,如果DBA不知道怎么定位,那他要被开除了,哈哈),定位到SQL后再定位代码就非常简单了。按照这种办法,我们很快定位了问题。原来是一个接口必传的参数没传进来,也没加校验,导致SQL语句where后面少了两个条件,一次查几万条记录出来,真坑啊!这种方法是不是要快很多,哈哈,5分钟搞定。

当时的DAO层是基于Mybatis实现的,出问题的SQL语句如下:

上面SQL语句意思是根据orderID查一个订单,或者根据userID查一个用户所有的订单,两个参数至少要传一个。但是两个参数都没传,只传了startTime和endTime。所以一次Select就查出了几万条记录。

所以我们在使用Mybatis的时候一定要慎用if test,一不小心就会带来灾难。后来我们将上面的SQL拆成了两个:

根据订

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值