有关秒杀的一点思考

拜读大作后有感,链接贴文末

场景考虑:

  10万秒100

问题:

  高并发可能导致缓存雪崩、击穿、穿透

       超卖:对于最后1件,多redis 同时访问,可能扣减为负

       恶意请求

    链接暴露

  数据库扛不住

全链路的考虑:

  前端:

  1. 页面资源静态化,减轻服务器压力
  2. url动态化,秒杀链接加盐 ,如md5
  3. 按钮置灰,防止秒杀还没开始服务压力就上来
  4. 前端限流:每触发按钮一次,隔段时间允许再次触发

  网关:

  1. 高并发支持:nginx 几万并发支持/tomcat 几百并发支持

  风控:对机器账号的过滤

  后端:服务之间降低影响

  1. 单一职责微服务+分布式部署 
  2. Redis集群:主从同步,读写分离,哨兵持久化,开启事务防止并发竞争超卖
  3. 库存预热: 商品库存先加载到Redis,秒杀后异步改库存
  4. 限流,服务降级,熔断,隔离
  5. 消息队列
  6. 单独秒杀数据库,简单的表设计,合适索引
  7. 分布式事务:数据同步方式 2pc或3pc,效率高

 

https://www.cnblogs.com/aobing/p/13515871.html

原文地址:https://www.cnblogs.com/lingli-meng/p/13522469.html