- 业务
- 库存:下单后即锁库存。
- 下单:支付环节,扣款可能成功,但是支付返回失败,后台会请求查询支付数据(比如向支付宝请求支付状态),用户也可以回到订单列表刷新请求。
- 并发
- 重启与过载保护
- 拒绝请求
- 前端设置过滤
- 将过载保护设置在CGI入口层,快速将客户的请求返回
- 反作弊
- 单个账号,多个请求
- 简单的方案:判断用户的参与记录,没有参与过才写入到参与记录;(低效,并 且容易被绕过而失效,时差内所有请求都会通过这个判断)
- 更好的方案:在程序入口处,一个账号只允许接受一个请求,其他请求过滤
- 多个账号,多个请求(僵尸号)
- 可以通过检测指定机器IP请求频率就可以解决,如果发现某个IP请求频率很高,可以给它弹出一个验证码或者直接禁止它的请求(直接禁止容易误伤)
- 多个账号,不同IP多个请求
- 高并发下的数据安全
- MySQL:自带的锁机制
- 悲观锁:只要有修改数据,就加锁,排斥外部请求的修改。遇到加锁就等待,解决线程安全;弊端,请求过多,链接被耗尽,系统陷入异常
- FIFO队列:不拒绝,而是直接将请求放入队列中的;只是缓解上面的情况,并不能完全解决
- 乐观锁:大都是采用带版本号(Version)更新。实现就是,这个数据所有请求都有资格去修改,但会获得一个该数据的版本号,只有版本号符合的才能更新成功,其他的返回抢购失败。这样的话,我们就不需要考虑队列的问题,不过,它会增大CPU的计算开销。但是,综合来说,这是一个比较好的解决方案。
- 有很多软件和服务都“乐观锁”功能的支持,例如Redis中的watch就是其中之一。通过这个实现,我们保证了数据的安全。
电商系统风险点