阅读 4228

一次JVM FullGC的背后,竟隐藏着惊心动魄的线上生产事故!【石杉的架构笔记】

欢迎关注个人公众号:石杉的架构笔记(ID:shishan100)

周一至周五早8点半!精品技术文章准时送上!


这篇文章给大家聊一次线上生产系统事故的解决经历,其背后代表的是线上生产系统的JVM FullGC可能引发的严重故障。


一、业务场景介绍

先简单说说线上生产系统的一个背景,因为仅仅是文章作为案例来讲,所以弱化大量的业务背景。

简单来说,这是一套分布式系统,系统A需要将一个非常核心以及关键的数据通过网络请求,传输给另外一个系统B。

所以这里其实就考虑到了一个问题,如果系统A刚刚将核心数据传递给了系统B,结果系统B莫名其妙宕机了,岂不是会导致数据丢失?

所以在这个分布式系统的架构设计中,采取了非常经典的一个Quorum算法

这个算法简单来说,就是系统B必须要部署奇数个节点,比如说至少部署3台机器,或者是5台机器,7台机器,类似这样子。

然后系统A每次传输一个数据给系统,都必须要对系统B部署的全部机器都发送请求,将一份数据传输给系统B部署的所有机器。

要判定系统A对系统B的一次数据写是成功的,要求系统A必须在指定时间范围内对超过Quorum数量的系统B所在机器传输成功。

举个例子,假设系统B部署了3台机器,那么他的Quorum数量就是:3 / 2 + 1 = 2,也就是说系统B的Quorum数量就是:所有机器数量 / 2 + 1。

所以系统A要判定一个核心数据是否写成功,如果系统B一共部署了3台机器的话,那么系统A必须在指定时间内收到2台系统B所在机器返回的写成功的响应。

此时系统A才能认为这条数据对系统B是写成功了。这个就是所谓的Quorum机制。

也就是说,分布式架构下,系统之间传输数据,一个系统要确保自己给另外一个系统传输的数据不会丢失,必须要在指定时间内,收到另外一个系统Quorum(大多数)数量的机器响应说写成功。

这套机制实际上在很多分布式系统、中间件系统中都有非常广泛的使用,我们线上的分布式系统也是采用了这个Quorum机制在两个系统之间传输数据。

给大家上一张图,一起来看一下这套架构长啥样。


如上图所示,图中很清晰的展示了系统A和系统B之间传输一份数据时的Quorum机制。

接下来,我们用代码给大家展示一下,上面的Quorum写机制在代码层面大概是什么样子的。

PS:因为实际这套机制涉及大量的底层网络传输、通信、容错、优化的东西,所以下面代码经过了大幅度简化,仅仅表达出了一个核心的意思。



上面就是经过大幅精简后的代码,不过核心的意思是表达清晰了。大家可以仔细看两遍,其实还是很容易弄懂的。

这段代码其实含义很简单,说白了就是异步开启线程发送数据给系统B所有的机器,同时进入一个while循环等待系统B的Quorum数量的机器返回响应结果。

如果超过指定超时时间还没收到预期数量的机器返回结果,那么就判定系统B部署的集群出现故障,接着让系统A直接退出,相当于系统A宕机。

整个代码,就是这么个意思!


二、问题凸现

光是看代码其实没啥难的,但是问题就在于线上运行的时候,可不是跟你写代码的时候想的一样简单。

有一次线上生产系统运行的过程中,整体系统负载都很平稳,本来是不应该有什么问题,但是结果突然收到报警,说系统A突然宕机了。

然后就开始进行排查,左排查右排查,发现系统B集群都好好的,不应该有问题。

然后再查查系统A,发现系统A别的地方也没什么问题。

最后结合系统A自身的日志,以及系统A的JVM FullGC进行垃圾回收的日志,我们才算是搞清楚了具体的故障原因。


三、定位问题

其实原因非常的简单,就是系统A在线上运行一段时间后,会偶发性的进行长时间Stop the World的JVM FullGC,也就是大面积垃圾回收。

但是,此时会造成系统A内部的工作线程大量的卡顿,不再工作。要等JVM FullGC结束之后,工作线程才会恢复运作。

我们来看下面那个代码片段:


但是这种系统A的莫名宕机是不正确的,因为如果没有JVM FullGC,本来上面那个if语句是不会成立的。

他会停顿1秒钟进入下一轮while循环,接着就可以收到系统B返回的Quorum数量的结果,这个while循环就可以中断,继续运行了。

结果因为出现了JVM FullGC卡顿了几十秒,导致莫名其妙就触发了if判断的执行,系统A莫名其妙就退出宕机了。

所以,线上的JVM FullGC导致的系统长时间卡顿,真是造成系统不稳定运行的隐形杀手之一啊!


四、解决问题

至于上述代码稳定性的优化,也很简单。我们只要在代码里加入一些东西,监控一下上述代码中是否发生了JVM FullGC。

如果发生了JVM FullGC,就自动延长expireTime就可以了。

比如下面代码的改进:


通过上述代码的改进,就可以有效的优化线上系统的稳定性,保证其在JVM FullGC发生的情况下,也不会随意出现异常宕机退出的情况了。

END




如有收获,请帮忙转发,您的鼓励是作者最大的动力,谢谢!


一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码,持续关注:


石杉的架构笔记(id:shishan100)

十余年BAT架构经验倾囊相授


推荐阅读:

1、拜托!面试请不要再问我Spring Cloud底层原理

2、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问?

3、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战

4、微服务架构如何保障双11狂欢下的99.99%高可用

5、兄弟,用大白话告诉你小白都能听懂的Hadoop架构原理

6、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问

7、【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍

8、拜托,面试请不要再问我TCC分布式事务的实现原理坑爹呀!

9、【坑爹呀!】最终一致性分布式事务如何保障实际生产中99.99%高可用?

10、拜托,面试请不要再问我Redis分布式锁的实现原理!

11、【眼前一亮!】看Hadoop底层算法如何优雅的将大规模集群性能提升10倍以上?

12、亿级流量系统架构之如何支撑百亿级数据的存储与计算

13、亿级流量系统架构之如何设计高容错分布式计算系统

14、亿级流量系统架构之如何设计承载百亿流量的高性能架构

15、亿级流量系统架构之如何设计每秒十万查询的高并发架构

16、亿级流量系统架构之如何设计全链路99.99%高可用架构

17、七张图彻底讲清楚ZooKeeper分布式锁的实现原理

18、大白话聊聊Java并发面试问题之volatile到底是什么?

19、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能?

20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解?

21、大白话聊聊Java并发面试问题之公平锁与非公平锁是啥?

22、大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化

23、互联网公司的面试官是如何360°无死角考察候选人的?(上篇)

24、互联网公司面试官是如何360°无死角考察候选人的?(下篇)

25、Java进阶面试系列之一:哥们,你们的系统架构中为什么要引入消息中间件?

26、【Java进阶面试系列之二】:哥们,那你说说系统架构引入消息中间件有什么缺点?

27、【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer的面试经历

28、【Java进阶面试系列之三】哥们,消息中间件在你们项目里是如何落地的?

29、【Java进阶面试系列之四】扎心!线上服务宕机时,如何保证数据100%不丢失?



关注下面的标签,发现更多相似文章
评论