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

风险案例

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

没想到！

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

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

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

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

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

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

反省总结

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

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

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

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