电商系统风险点

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