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

原因分析：

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

---

解决方案：

1. 网关增加限流处理。

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

问题3: mq疯狂堆积

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

---

原因分析：

我特喵～我也是接盘的。

1. 发送mq没有考虑过这种场景是否适合使用mq，下发2w个人脸，直接mq怼怼怼了两万条进去，其中信息中还包含着base64流，一张照片1M算的话，2w张照片*设备数量，诸位自行体会mq的磁盘占有量。

2.没有考虑超时未回复ack的情况，在频繁重试。

3.异常处理不到位，对业务异常和代码异常都进行重试处理，如果是业务异常，照片不符合规范重试也没用。

---

解决方案：

1. 临时紧急发版，消费代码全部删除，全部进行消费。

2. 取消mq的使用，考虑下发人脸的场景既不涉及支付又无关痛痒，改为异步线程处理，LIst中含两万个名单，本身对内存占有率影响不大。

问题4: 数据库拖死

设备会实时的进行通行记录的上传，某某某同学通过哪个设备进入了哪里，由于校方有台设备长期处于离线过程中，某一天它突然上线了，开启离线上传，可谓是一瞬间怼过来了8w条数据，由于整个公司的业务线都是一个数据库上，导致其它业务线都受影响。

---

原因分析：

我特喵～我也是接盘的～也是之前哥们给我留的小惊喜

1. 主要还是接口的并发量过高。

2. 接收通行记录后，推送了一个大屏，没有人连接大屏的socket，也进行推送了，推送的代码中查询了通行记录这张表，这张表的数据量已经超级多了，也相当于查询了8w次，大批量慢sql。

---

解决方案：

1. 接口增加限流处理。

2. 项目问题太多了，影响到其它业务线了，把我们撵出来了…单独购买了一个数据库。

3. 不是当日的数据，不进行推送，无人连接socket，不进行推送。

4. 通行记录表索引优化。

复盘总结：

问题还有很多，正在整理过程中。

1.  在coding过程中，一定要做好代码评审环节。

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年嵌入式&物联网开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上嵌入式&物联网开发知识点，真正体系化！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新！！

点，真正体系化！**

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新！！