秒杀架构-详细

秒杀架构

核心：把量变少，限流

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

把量拆开
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限制同时可以防止黄牛、友商的恶意刷单或捣乱

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

用户秒杀流程图

地址
取自马士兵