记录我编写后端程序的一次致命错误

47 阅读2分钟

我为什么会试着做后端

我曾经听过一些java工程师说,会了java后javaScript我闭着眼睛就能写,然后拿着框架部署一个vue就是哗哗哗开干

我听到这话心里很不是滋味,但是抛开一些代码上的不优雅,一些后台管理系统,后端工程师借助若依框架确实可以很好的完成。

门槛降低总是好事,大家都有了更多选择,可以干更多的事情,借着nodejs的兴起也带来了一些使用javaScript编写的后端框架,koa,express,nestjs...

我便是将上面的三个框架都学习使用了一遍,我使用koa+typescript+mysql构建后端项目,多数情况下,我只做一些简单的增删改查、创建一个事务并提交、进行一些复杂的where查询、做一个多表联查、多表更新、创建一个字段索引、做几个外键约束、做一个文件上传、做一个jsonWebtoken鉴权、或者生成excel文件发送给前端。这就差不多是我后端工作的全部了。

我的致命错误

后来我遇到一次业务上的挑战,做一个定时扣费功能,我对这个功能没有多想,想到用定时器连锁递归的方式来做,没多想就开始做了。

每当有订单开始生效,我编写的代码就会生成一个定时器,定时到下次扣费时间再执行,然后定时器递归,直到订单到期。如果服务器重启则遍历未完成的订单并重新开启定时器

在上面的逻辑里面有一个非常致命的错误——没有考虑高并发,上千上百个订单我的这个思路与逻辑确实可以很准时的执行,但是如果有上万上十万呢?内存就泄露了。服务器就崩了。

我含泪删下了千行代码,试着使用一个循环定时器定时查询订单列表来实现,这样虽然没那么准时,但是面对高并发确实可以从容不迫。最终是初步完成了这个功能。

面对这样的业务不得不说找一个有经验的人问真的很重要。奈何我这个前端仔交的朋友都是前端。QAQ