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