秒杀
2020-09-26 18:57:28 0 举报
AI智能生成
秒杀系统设计
作者其他创作
大纲/内容
问题
超卖
恶意请求
链接暴露
数据库压力
设计方案
前端
资源静态化
提前将静态资源放到cdn,用户请求从最近的cdn服务器获取,减少请求静态资源服务器的压力
秒杀链接加盐
把URL动态化,就连写代码的人都不知道,通过MD5之类的摘要算法加密随机的字符串去做URL,通过前端代码去获取URL 后端校验
限流
前端
秒杀之前将按钮置灰,点击秒杀按钮之后,将按钮置灰几秒
后端
加入限流组件,比如 阿里的Sentinel,Hystrix
物理限流,如果秒杀1000件商品,有10万个请求,那么放一万个请求进去,因为有很多是薅羊毛的,这些请求可以通过风控系统拦截一部分
NGINX
负载均衡,租用流量机
风控
后端
服务职责单一
开辟新的单独的秒杀微服务,建立新的秒杀库,使秒杀业务不影响现有的服务
Redis集群
主从同步、读写分离,开启哨兵,持久化
库存预热
通过运维人员提前将商品库存数据预热到Redis,减少秒杀活动开启时的瞬时压力,等秒杀活动结束后再异步的去修改库存数据
事务
如果Redis内只有一个库存,但是同时有三个人请求,那这个库存该给谁呢?如果库存扣减失败必须要启用事务,使一个事务内的所有操作失败
熔断、降级、限流、隔离
限流,顶不住就挡一部分请求回去
降级,下游的服务挂了返回统一的失败提示
熔断,不影响别的系统,不能导致服务雪崩
隔离,单个URL使用独立的线程池,当某个服务不可用不会无限制的新建线程,你不行了你别拖累其它兄弟们啊
消息队列
削峰填谷,将消息放到消息队列,然后开启一个单独的消费服务,一点点去扣减库存
数据库
单独建一个秒杀的数据库,当流量上来了挂的也只是秒杀的数据库,不会影响到其它的数据库,数据体量大就涉及到分库分表
分布式事务
TCC
不适合,TCC开发成本太大,所有的接口都要写三遍,因为涉及到TCC的三个阶段
最终一致性
不适合,最终一致性基本上是靠轮训去保证一个操作一定成功,那实时性就大打折扣了
2PC,3PC
推荐,虽然不一定能保证数据最终一致,但是效率上还是OK的
收藏
0 条评论
下一页