2023的线上事故复盘总结（OOM，数据库崩溃）持续更新中～

项目场景：

智慧门禁系统，公司研制的一个saas系统，基于Springcloud框架，主要是面向高校对老师学生的通行方式做统一的管理，可通过卡、码、脸等多种方式进出，可实现不同人员进出不同的场所，例如宿管人员不可进入图书馆。

在此也告诫我们，coding其实很简单，但是要考虑接口对数据库中间介的影响和接口可支持的并发量，你无法预测项目未来的用户量。

---

问题1: 项目OOM

有一场景是通过门禁系统对面板机进行下发人脸，项目OOM。

---

原因分析：

低级问题，进行数据下发，设备要求执行的协议是进行下发照片base64数据，想当然的对照片批量进行转换Base64（OOM）List体过大。

---

解决方案：

改为for循环，一张张照片转换下发，下发完成及时清理。

问题2: 项目OOM

有一场景是通过门禁系统对面板机进行下发人脸，后续调用业务系统OOM。

---

原因分析：

iot系统进行统一合并至物联网关后，业务线进行统一下发物联网关，不允许直接对接操作设备，由于同步人脸数量过多，整个学校的人员，大概两万多张。哈哈哈哈哈～并发过高，大量的Base64流打过去，物联网关系统down了。

---

解决方案：

1. 网关增加限流处理。

2. 由于图片是从阿里云取的，改为传递url，但是要注意图片有效期

问题3: mq疯狂堆积

有一场景是通过门禁系统对面板机进行下发人脸，发送mq进行异步处理，然后自消费下发到设备，线上mq疯狂堆积和重试，对公司所有业务线都造成了严重影响。

---