秒杀架构-详细

秒杀架构

  • 秒杀架构
    • 秒杀活动的特点
    • 要解决的问题
    • 涉及技术点
    • 问题解决方案
      • 瞬时大流量的冲击
      • 超卖、少卖问题
      • 高可用
      • 恶意请求
    • 用户秒杀流程图

秒杀架构

核心:把量变少,限流

适当增加机器,重新设计秒杀架构,让普通业务和秒杀业务分离开,秒杀不影响普通业务,分治法,分而治之(分散流量

把量拆开
1.在不同地区部署同样的架构+限流,分散流量
2.所有静态页全部扔到CDN中,原生支持多地域分散流量

秒杀活动的特点

1,瞬时大流量 所以需要对流量进行控制
2,读多写少 都不可以直接操作数据库,写可以酌情考虑
3,用户量大,商品数量有限,最终创建的订单少

要解决的问题

1,瞬时大流量的冲击
2,超卖、少卖问题
3,高可用
4,恶意请求

涉及技术点

1,负载均衡 lvs+nginx
2,限流 sentinel
3,秒杀动态url
4,消息队列削峰
5,定始任务保证数据最终一致
6,数据库乐观锁防止超卖
7,使用RocketMq的事物消息,保证消息投递的可靠性

问题解决方案

瞬时大流量的冲击

一,秒杀场景都是供不应求,往往请求很多,最终生成订单的请求不锁,也就是有效请求不多,所以前后端可以采用限流方案
前端限流
1,可以随意丢弃请求,直接返回秒杀失败
2,活动前置灰抢购按钮,防止产生无效流量
3,防暴击
后端限流
1,令牌桶算法
2,ip访问限制
3,用户黑名单
4,参与资格校验等
5,熔断降级
后端的限流方案可以选择现成的框架进行集成,比如Spring Cloud Gateway、Sentinel等
二,后端除了从流量上应对大量流量场景外,还可以引入缓存,提高吞吐量,但是同时也需要只要引入缓存的一些问题,比如缓存穿透、缓存击穿等,在秒杀活动开始前进行预热
三,引入消息队列,进行流量削峰
四,前面页面等资源静态化并引入CDN

超卖、少卖问题

超卖问题:
使用乐观锁进行库存变更,保证数据的安全性
少卖问题:
使用定时任务,定期同步缓存和数据库中的数据
使用定时任务,定期取消超时未支付的订单并恢复库存

高可用

一,秒杀服务独立部署,资源充足的情况下可以考虑针对秒杀活动单独部署一套环境,这套环境中可以剥离一些可能无用的逻辑,比如不用考虑使用优惠券、红包、下单后赠送积分的一些场景,剥离无用代码逻辑提高性能。
二,后台服务集群化,并添加lvs和nginx等负载均衡技术

恶意请求

一,动态URL,如果有一点编程基础或者懂行的人,会通过F12查询到请求地址从而进行提前请求,所以使用加密算法,加密随机的字符串去做url,然后通过前端代码获取url,后台校验。秒杀到时间时,才放出链接。

二,ip限制同时可以防止黄牛、友商的恶意刷单或捣乱

三,增加算术校验码分辨真实用户人机器脚本

用户秒杀流程图

秒杀架构-详细_第1张图片
秒杀架构-详细_第2张图片

秒杀架构-详细_第3张图片
地址
取自马士兵

你可能感兴趣的:(笔记,架构,java,分布式)