秒杀业务特点：限时限量，业务系统要处理瞬时高并发请求，Redis是必需品。
秒杀可分成秒杀前、秒杀中和秒杀后三阶段，每个阶段的请求处理需求不同，Redis具体在秒杀场景的哪个环节起到作用呢？
1 秒杀负载特征
秒杀商品的库存量＜＜购买该商品的用户数，且会限定用户只能在一定时间段内购买。
这给秒杀系统带来两个明显负载特征：
1.1 瞬时并发访问量很高
一般DB每秒只能支撑k级并发，而Redis并发能达到w级。所以，当大量并发请求涌入秒杀系统时，要使用Redis先拦截大部分请求，避免大量请求直接发给DB
1.2 读多写少
读还是简单的查询操作。秒杀下，用户需先查验商品是否还有库存（即根据商品ID查询该库存量），只有库存有余量时，秒杀系统才能进行库存扣减、下单。可本地缓存保存库存是否为 0 的标识，避免再请求 redis。
库存查验操作是典型KV查询，Redis正满足。但秒杀只有小部分用户能成功下单，所以：
商品库存查询操作（读操作）＞＞库存扣减、下单操作（写操作）
一般把秒杀活动分成三个阶段：
2 秒杀阶段
2.1 秒杀前
用户不断刷新商品详情页，导致详情页瞬时请求量猛增。
一般尽量静态化商品详情页的页面元素，然后使用CDN或浏览器缓存这些静态化元素。
秒杀前的大量请求可直接由CDN或浏览器缓存服务，不会到达服务端。
2.2 秒杀中
大量用户点击商品详情页上的秒杀按钮，会产生大量的并发请求查询库存。一旦某个请求查询到有库存，紧接着系统就会进行库存扣减。然后，系统会生成实际订单，并进行后续处理，例如订单支付和物流服务。如果请求查不到库存，就会返回。用户通常会继续点击秒杀按钮，继续查询库存。
该阶段主要操作：
- 库存查验
- 库存扣减
- 订单处理
每个秒杀请求都会查询库存，而请求只有查到有库存余量，后续的库存扣减和订单处理才会被执行。所以，该阶段最大并发压力在库存查验。就需使用Redis保存库存量，请求直接从Redis读库存并查验。
库存扣减和订单处理是否都可交给后端DB执行?
订单处理可在DB执行，但库存扣减操作，不能交给DB。
为何非在DB处理订单呢？
订单处理涉及支付、商品出库、物流等多个关联操作，这些操作本身涉及DB中的多张表，要保证事务性，需在DB完成。
订单处理时，请求压力已不大，DB完全可支撑。
为啥库存扣减操作不能在DB执行
一旦请求查到有库存，即发送该请求的用户获得商品购买资格，用户就会下单了。同时，商品库存余量也需-1。
若把库存扣减的操作放到DB，会带来风险：
- 额外开销
Redis保存库存量，而库存量最新值又是DB在维护，所以DB更新后，还要和Redis进行同步，这增加额外操作逻辑 - 下单量＞实际库存量，超卖！
由于DB处理性能较慢，无法及时更新库存余量，可能导致大量库存查验请求读到旧库存值，并下单。就会出现下单数量＞实际库存量，导致超卖
所以，要在Redis进行库存扣减：
- 当库存查验完成后，一旦库存有余量，立即在Redis扣库存
- 为避免请求查询到旧库存值，库存查验、库存扣减两个操作需保证原子性
秒杀中需要Redis参与的两个环节：
2.3 秒杀结束后
该阶段，可能还有部分用户刷新商品详情页，尝试等待有其他用户退单。而已成功下单的用户会刷新订单详情，跟踪订单进度。
不过，此阶段的用户请求量已下降很多，服务器端一般都能支撑。
3 Redis可支撑秒杀的特性
3.1 支持高并发
Redis先天支持。且若有多个秒杀商品，也可使用切片集群，用不同实例保存不同商品的库存，避免使用单实例导致所有秒杀请求都集中在一个实例。
使用切片集群时，先CRC计算不同秒杀商品K对应Slot，然后在分配Slot和实例对应关系时，才能把不同秒杀商品对应的Slot分配到不同实例保存。
3.2 保证库存查验和库存扣减的原子性
使用Redis的原子操作或分布式锁。
4 基于原子操作支撑秒杀
秒杀中的一个商品的库存对应两个信息：
- 总库存量
- 已秒杀量
这种数据模型正好一个key（商品ID）对应两个属性（总库存量和已秒杀量），可用Hash保存：
key: itemID
value: {total: N, ordered: M}
- itemID 商品编号
- total，总库存量
- ordered，已秒杀量
因为库存查验、库存扣减这两个操作要保证一起执行，一个直接的方法就是使用Redis的原子操作。
库存查验、库存扣减是两个操作，需Lua脚本保证原子执行：
#获取商品库存信息
local counts = redis.call("HMGET", KEYS[1], "total", "ordered");
#将总库存转换为数值
local total = tonumber(counts[1])
#将已被秒杀的库存转换为数值
local ordered = tonumber(counts[2])
#如果当前请求的库存量加上已被秒杀的库存量仍然小于总库存量，就可以更新库存
if ordered + k <= total then
#更新已秒杀的库存量
redis.call("HINCRBY",KEYS[1],"ordered",k) return k;
end
return 0
然后就能在Redis客户端，使用EVAL命令执行脚本。客户端根据脚本返回值，确定秒杀是否成功：
- 返回值k，成功
- 0，失败
5 基于分布式锁支撑秒杀
让客户端向Redis申请分布式锁，拿到锁的客户端才能执行库存查验、库存扣减。
这样大量秒杀请求就会在争夺分布式锁时被过滤掉。
库存查验、扣减也不用原子操作了，因为多个并发客户端只有一个客户端能够拿到锁，已保证客户端并发访问的互斥性。
// 使用商品ID作为key
key = itemID
// 使用客户端唯一标识作为value
val = clientUniqueID
//申请分布式锁，Timeout是超时时间
lock =acquireLock(key, val, Timeout)
//当拿到锁后，才能进行库存查验和扣减
if(lock == True) {
//库存查验和扣减
availStock = DECR(key, k)
//库存已经扣减完了，释放锁，返回秒杀失败
if (availStock < 0) {
releaseLock(key, val)
return error
}
//库存扣减成功，释放锁
else{
releaseLock(key, val)
//订单处理
}
}
//没有拿到锁，直接返回
else
return
使用分布式锁时，客户端要先向Redis请求锁，只有请求到锁，才能进行库存查验等操作，这样客户端在争抢分布式锁时，大部分秒杀请求本身就会因为抢不到锁而被拦截。
推荐使用切片集群中的不同实例来分别保存分布式锁和商品库存信息。秒杀请求会先访问保存分布式锁的实例。若客户端没拿到锁，这些客户端就不会查询商品库存，减轻保存库存信息的实例的压力。
6 总结
秒杀系统是个系统性工程，Redis实现对库存查验、扣减环节的支撑。
此外，还有环节需要处理：
前端静态页面的设计
秒杀页面上能静态化处理的页面元素，要尽量静态化，充分利用CDN或浏览器缓存服务秒杀开始前的请求
请求拦截和流控
在秒杀系统的接入层，对恶意请求进行拦截，避免对系统的恶意攻击，例如使用黑名单禁止恶意IP进行访问。如果Redis实例的访问压力过大，为了避免实例崩溃，我们也需要在接入层进行限流，控制进入秒杀系统的请求数量。
库存信息过期时间处理
Redis中保存的库存信息其实是数据库的缓存，为了避免缓存击穿问题，不要给库存信息设置过期时间。
数据库订单异常处理。如果数据库没能成功处理订单，可以增加订单重试功能，保证订单最终能被成功处理。
资源隔离
秒杀活动带来的请求流量巨大，我们需要把秒杀商品的库存信息用单独的实例保存，而不要和日常业务系统的数据保存在同一个实例上，这样可以避免干扰业务系统的正常运行。