秒杀

电商系统架构

网络带宽
减轻网站服务器压力，将商品页面静态资源分开存放，缓存在各个CDN，为CDN服务商增加出口带宽。

页面
1.静态页面缓存到CDN
2.秒杀按钮显隐控制：置灰，倒计时
3.秒杀链接生成：秒杀链接倒计时生成，防止被盗取秒杀链接

常见中间件并发量预估
Nginx并发数预估10w
Tomcat应用并发数预估 800-1000
mysql数据库并发数预估 1000-3000
redis最大并发数预估 5w-10w
rocketmq最大并发数预估 10w

由上边数据其实可以很清楚的看出压力最大的是应用层以及持久层。
应用层可以通过增加机器配置，增加机器数量解决；
数据库却不能，因为数据库即使做分库分表，秒杀秒的都是同一个商品，最终还是会落到同一个数据库，数据库压力还是过大。
所以秒杀削峰核心就是解决数据库压力

秒杀对哪些服务造成的压力最大
1.商品服务--查看
2.订单服务--秒杀
3.库存服务--秒杀

商品服务
商品服务面临最多的就是非常多的查询，获取商品信息
缓存：多级缓存--本地缓存+进程缓存+redis缓存，热点缓存计算
后台：大促期间商品修改等功能全部降级处理
核心就是处理缓存一致性

秒杀运营准备

秒杀服务端大前提

高可用三板斧
限流，降级，熔断

准备
预估单量，预估qps，tps，确定机器

机器扩容

系统依赖：是否对上下游有依赖
中间件依赖：所涉及的中间件需求(容量、性能QPS等)
DB依赖：DB保障专项，历史数据清理，慢sql清零

接口评估
梳理核心对外接口，评估QPS，增加限流，降级，熔断策略
核心数据查询方案评估，页面查询search，热点缓存
高rt接口处理
接口是否需要配置监控报警，指那些严重影响生产的，以及报警后对应的处理方式
是否需要单独做压测，压测方式：系统压测，业务压测
是否需要预案，前置预案，应急预案

压测
压测目标，压测单量，期待暴露出新问题
破坏性演练

后续
复盘，问题分析，cpu，内存，GC，DB波动分析，巅峰QPS及平均RT

秒杀流程

其他玩法
1.可以通过Lua脚本库（OpenResty）从负载均衡层直接访问缓存
2.热点缓存，对于部分场景会有大批量单个缓存打到同一个缓存节点上
--分割key，打到不同缓存节点上，容易出现还有库存但是用户就是抢不到的情况
--分割redis库存到本地缓存，假设skuA有1000个redis库存，10台机器，每台机器存储skuA100库存，每次扣减本地库存同时扣减redis库存，本地库存拦一刀，减小redis压力---12306玩法
3.秒杀资格：在秒杀前加一步拦截，非所有用户都能直接获取秒杀资格
4.动态过渡：实时计算下单tps，普通下单接口峰值过高自动转秒杀接口