个人随笔
目录
反省1:千万不要为了去追求系统性能的极致而忽略了业务安全的保障
2021-06-28 20:45:46

作为程序员,让系统运行的更快更好从来都是毕生的追求,但是一切一切都需要建立在保障业务安全的前提之上,不然迟早会出大问题,特别是电商系统,如果不按规范来,不做到任何小的改动都上上报领导,层层提交,一不小心几个月白干,下面描述一下今天遇到的风险。

风险案例

我开发的一个抽奖功能,要求一个用户只能中一个奖,因为抽奖并发比较大,为了尽量减少数据库的操作,想着反正一个用户只会有一次抽奖资格,我就把“每个用户的中奖上限”规则给去掉了,反正用户只会有一次抽奖资格,不可能抽第二次,还可以少一次数据库操作,毕竟高并发嘛!

没想到!

导出中奖报表的时候,发现,有一个用户中了四个三等奖(我们设置100%中奖规则,靠库存控制),我的天,这为啥?还好是1.8L的花生油,要是一等奖我这两个月的工资就玩完了!要是我开启了“每个用户的中奖上限”这条业务规则该多好!

然后立马查原因,发现送了四条抽奖资格!这尼玛,始料不及,不科学,从来没想到过!(笑话,想得到老子当然不会删除那条“每个用户的中奖上限”规则了)。

最后发现原因,是因为那个用户报名那一天,部署RocketMQ的那台机因为别的程序业务量暴增导致资源不足,然后我们微服务登记报名消息的时候,导致登记失败触发了“消息补偿”,好巧不巧消息补偿也尝试登记还是失败,但是也不知道为什么这种资源不足的情况下消息中间件虽然报错,但是还是登成功了,导致一条业务报名的行为登记了多次,好巧不巧,消费程序的逻辑没有做幂等,偶买噶!又是始料不及!

兜兜转转,曲曲折折,最终问题出现了,并且危险性还挺大的!

所以,就算看了一万遍代码,对自己的代码无比的自信,最好最好留一手,跟何况,代码还不一定是自己写的呢!

加上“每个用户的中奖上限”这条规则,或者去掉这条规则的时候层层上报,最后可能有人会提出,要是一个用户因为别的原因获得了多个抽奖资格怎么办这个问题?可能你就不会删掉这个规则了。

反省总结

1、首先要保障业务安全,特备是涉及”价值”类的业务,系统性能是第二,业务安全是第一。

世界上只要是代码就免不了可能会又bug,软件上的,硬件上的,更甚至人为的,比如有别的员工直接修改数据库插入抽奖资格怎么办,比如你的项目别的员工开发的功能有bug,直接通过接口赠送抽奖资格怎么办!所以,一定要业务规则至上,如果不是必要的性能提升,比如不删除规则就卡死的这种,那就给自己留一手,宁愿假设自己没有考虑周到,然后兜个低,就当有问题,做个预留方案!

2、任何修改都要上报给领导,领导同意后,分析后才可以操作

千万不要以为自己觉得没问题就草率执行,特备是一些数据库操作.一定要走流程,请示临到,做好备份才能执行!

 60

啊!这个可能是世界上最丑的留言输入框功能~


当然,也是最丑的留言列表

有疑问发邮件到 : suibibk@qq.com 侵权立删
Copyright : 个人随笔   备案号 : 粤ICP备18099399号