共计 1720 个字符，预计需要花费 5 分钟才能阅读完成。
案例实战：一个超大数据量处理系统是如何不堪重负OOM的？
1、超大数据量处理系统的案例
大家是否还记得我们不止一次提过的一个超大数据量的计算引擎系统？这个系统是我们自己研发的一个非常复杂的PB级数据计算系统，远比很多流行的开源技术要强悍，架构上也非常复杂，同时处理的数据量也特别大。
但是因为这个专栏并不是给大家讲这种具体的系统，因此我们还是用简化的案例场景来给大家解释当时遇到的线上OOM问题。
之前就用这个系统案例给大家分析过GC问题，但是因为他处理的数据量实在是很大，负载也过高，所以除了GC问题以外，还有OOM问题。
首先用最最简化的一张图给大家解释系统的工作流程。简单来说，就是不停的从数据存储中加载大量的数据到内存里来进行复杂的计算，如下图所示。
045-超大数据量处理系统是如何不堪重负OOM
这个系统会不停的加载数据到内存里来计算，每次少则加载几十万条数据，多则加载上百万条数据，所以系统的内存负载压力是非常大的。
另外这里给大家多讲一些之前案例中没提到过的这个系统的一些运行流程，因为他跟我们这次讲解的OOM场景是有关系的。
这个系统每次加载数据到内存里计算完毕之后，就需要将计算好的数据推送给另外一个系统，两个系统之间的数据推送和交互，最适合的就是基于消息中间件来做
因此当时就选择了将数据推送到Kafka，然后另外一个系统从Kafka里取数据，如下图。
045-超大数据量处理系统是如何不堪重负OOM
这就是系统完整的一个运行流程，加载数据、计算数据、推送数据。
2、针对Kafka故障设计的高可用场景
既然系统架构如此，那么大家思考一下，数据计算系统要推送计算结果到Kafka去，万一Kafka挂了怎么办？此时就必须设计一个针对Kafka的故障高可用机制
就当时而言，刚开始负责这块的工程师选择了一个思考欠佳的技术方案。一旦发现Kafka故障，就会将数据都留存在内存里，不停的重试，直到Kafka恢复才可以，大家看下图的示意。
045-超大数据量处理系统是如何不堪重负OOM
这个时候就有一个隐患了，万一真的遇上Kafka故障，那么一次计算对应的数据必须全部驻留内存，无法释放，一直重试等待Kafka恢复，这是绝对不合理的一个方案设计。
然后数据计算系统还在不停的加载数据到内存里来处理，每次计算完的数据还无法推送到Kafka，全部得留存在内存里等着，如此循环往复，必然导致内存里的数据越来越多。
3、无法释放的内存最终导致OOM
正是因为有这个机制的设计，所以有一次确实发生了Kafka的短暂临时故障，也因此导致了系统无法将计算后的数据推送给Kafka
然后所有数据全部驻留在内存里等待，并且还在不停的加载数据到内存里来计算。
内存里的数据必然越来越多，每次Eden区塞满之后，大量存活的对象必须转入老年代中，而且这些老年代里的对象还是无法释放掉的。
老年代最终一定会满，而且最终一定会有一次Eden区满之后，一大批对象要转移到老年代，结果老年代即使Full gc之后还是没有空间可以放的下，最终就会导致内存溢出。然后线上收到报警说内存溢出。
最后这个系统全线崩溃，无法正常运行。
如何对这个问题进行修复呢？
其实很简单，当时就临时直接取消了Kafka故障下的重试机制，一旦Kafka故障，直接丢弃掉本地计算结果，允许释放大量数据占用的内存。后续的话，将这个机制优化为一旦Kafka故障，则计算结果写本地磁盘，允许内存中的数据被回收。
这就是一个非常真实的线上系统设计不合理导致的内存溢出问题，想必大家看了这个案例后，一定对内存溢出问题感触更加深刻了。
后面我们还将有更多的各种各样奇形怪状的OOM案例带给大家，并且要给大家介绍很多解决OOM问题的技巧。
