xoxo
2014-08-06 21:19:14 +08:00
楼上的同学们没看懂楼主的问题；
楼主说的是什么问题呢？
重复提交，表面上是重复提交，威力不大，但实际。。。我们来分析分析：
假设一个用户，余额100，平台恰好有个提现的地方，理所当然用户最多只能提取100元。
我们来分析下程序在生成提现数据的过程：
开启事务；
用户发起一次提现请求，到达应用后，程序判断用户余额是否够用，如果不够就跳出事务了；
然后扣除100元，
然后再提现数据表中插入一条数据，
到这里还没结束，因为事务还没提交，当上面进行顺利时，到达这里就应该commit提交了，如果上面操作任何一步异常，就rollback回滚了。
看起来挺完美的过程，其实！弱暴了！
为啥？
假如用户发起两个请求，而且同一时间（1/1000秒级）请求到服务器，
再走一次上面的逻辑：
请求一达到服务器 请求二达到服务器
开启事务 开启事务
余额检查->通过 余额检查->通过
扣除余额->done 扣除余额->done
插入提现记录->done 插入提现记录->done
提交->commit(); 提交->commit();
两边几乎同时进行一样的操作，为什么没被拦截掉只处理一个请求呢？因为余额检查时，别的请求的事务未提交，在此请求内select的数据还未生效，所以两个请求处理都通过了检查。
那怎么防御呢？
token?
扯J8蛋！token用来防御这原子级别的攻击？别说session了，即使你重写php底层，让session动态调用php的内存也无济于事。原因自己脑补；
队列是终极解决方案。
然后有一个临时方案，提现的表中肯定会有time/datetime之类的字段，在建表时将这个表中的time/datetime + userId 设置为联合主键，然后事务在插入提现数据时，因为时间同一秒且同一用户所以数据冲突，只会成功一条，然后事务报错启动回滚，近乎完美。唯一的瑕疵就是假如前后误差1ms, 然后恰好前一个时间是xxxx1，后一个时间是xxxx2，这样就扯痛蛋了。。。千分之一的概率。