系统OOM或者崩溃时的解决方法
项目背景
发生故障的系统是基于spring cloud和Vue搭建的一套前后端分离的系统，主要是用来对接小程序来使用的，后端分为两个基础服务、四个中心服务以及三个对端服务，所有的流量都是从网关打到对端服务，再通过对端服务去调用中心服务和基础服务。会员注册数是四千万左右。
遇到的挑战与解决方法
先说说第一个吧，第一个挑战发生在企业会员日当天的下午三点钟，这天运营人员在小程序中开启了一个秒杀活动，就是有一万张买一送一卷，当三点到达时大量用户同一时间涌入小程序中，这一时间的请求数大概是平时的五倍左右，但就在这时小程序出现了长时间的卡顿和白屏现象，一个请求的响应时间比平时慢了三倍左右，这段时间持续了五分钟，也就是当这一万张卷抢完后流量迅速下滑才恢复。
【系统OOM或者崩溃时的解决方法】在后续调查时发现上一次迭代的时候在小程序首页加入了一个新的查询接口，这个接口是在用户进入小程序时会自动触发，这也就导致在流量过高时，店铺系统就会存在大量请求访问数据库使得系统响应时间变长。系统性能下降又导致用户重复点击操作，这又加深了系统负担，进而更加恶化。
解决方案也很简单，就是在首页加一个交互，当用点击后才去触发当初的那个接口，并且在接口中增加缓存，避免数据库压力过大，这其实在开发中很常见，自己写的接口进行测试发现就几十毫秒的响应时间，但是当用户请求数瞬间暴增时数据库承受了他不该承受的重量而被压垮。
再来说说第二个，这次是在某天中，系统突然频繁奔溃，在重启后不到半小时就崩溃，在阿里云平台的ARMS监控中可以可以看到系统在某个时间节点内频繁的进行FULLGC,查看系统错误日志发现存在大量OOM异常，首先想到的就是会不会又是在搞什么运营活动，请求量暴增导致，但是在查看系统请求数后发现曲线平缓，并没有峰值。
当暂时没有头绪时就从第一个崩溃的服务开始查，发现其中有个发卷的接口响应时间直接超时了，查看原因发现有个运营自己创建了一个扫码领劵的活动，每扫一次码就领取一百万张卷，他扫了四次，也就是给他发放了四百万张卷，最后一次扫码时接口就超时了，之后这个人去小程序中查看自己的卷包时导致的OOM，因为用户的卷最多也就几百张，所以在查询优惠券时没有进行分页，导致一次将几百万的对象存到内存中导致内存溢出。这也就导致当他进行查看一次优惠券，我们系统就会崩溃一次。
解决方法就是先在优惠券发放上加上限，以及分页查询优惠券，并且优化数据库连接超时时间，以前将超时时间设置的太长，导致某个慢SQL长期占领数据库资源，导致系统卡顿。
总结
当遇到系统崩溃时，不要慌张，先从错误日志以及对应的性能监控平台进行查看，收集有用的信息，友盟的性能监控平台目前还没有使用过，等有机会使用过再来谈谈其与别的监控平台的使用感受。
代码是不会有“灵异事件”的，如果有只能说明是你还没有学到位，对于某些地方还存在缺陷，所以不用害怕，规范编码以及勤加思考和学习才能写出高质量的系统。
推荐阅读
- 如何在Mac中的文件选择框中打开系统隐藏文件夹
- 单点登陆
- 操作系统|[译]从内部了解现代浏览器(1)
- 游乐园系统，助力游乐园管理
- 中国MES系统软件随工业化成长
- 推荐系统论文进阶|CTR预估 论文精读(十一)--Deep Interest Evolution Network(DIEN)
- Cesium|Cesium 粒子系统学习
- 拒绝可以很艺术，或者很行为艺术。
- Android系统启动之init.rc文件解析过程
- 程序员|【高级Java架构师系统学习】毕业一年萌新的Java大厂面经，最新整理