当前位置：首页 > 问答 > 正文

Redis面试里秒杀技巧怎么用，面试中Redis那些必须懂的点

畅苗
问答
2026-01-11 11:13:18
1

关于Redis在面试中，尤其是秒杀场景下的应用，以及必须掌握的核心知识点，可以围绕以下几个方面来组织和回答，内容综合了多个技术社区和博客的常见讨论点，比如CSDN、掘金、InfoQ等平台上技术博主们的经验总结。

第一部分：秒杀场景下Redis的使用技巧

面试官问秒杀，其实是想考察你是否能处理极端高并发下的数据一致性和系统性能问题，Redis在这里扮演了至关重要的角色,但绝不是单打独斗。

库存扣减的核心：用Redis原子操作预减库存 这是最关键的技巧，你不能直接去数据库里查库存、判断、再更新，因为数据库扛不住瞬间的并发读写的，正确的做法是，在活动开始前，先把商品的库存数量加载到Redis中，用一个简单的string类型或者hash类型存储，来源自常见的最佳实践，老顾”等技术博主强调，当用户发起秒杀请求时，直接使用Redis的DECR或DECRBY命令进行库存扣减，这两个命令是原子性的，意味着多个客户端同时执行时，也不会出现超卖（即库存减到负数）的情况，如果DECR后的结果大于等于0，说明扣减成功，用户有资格进行后续下单；如果小于0，说明库存已售罄,直接返回失败给用户。
应对恶意请求和系统压力：限流与计数器 秒杀时会有大量请求涌入，其中很多可能是无效请求或恶意刷新的请求，你不能让所有这些请求都走到库存扣减那一步，这时候可以用Redis的INCR命令做一个简单的限流，给每个用户ID或者每个IP地址设置一个键，每次请求就INCR一下，并给这个键设置一个短暂的过期时间（比如5秒），如果某个用户在5秒内的请求次数超过一个阈值（比如5次），就直接拒绝后续请求，这能有效减轻后端服务的压力,这个思路在众多互联网公司的实战分享中都有提及。
避免重复下单：唯一性校验 同一个用户不应该抢到同一件商品两次，在扣减库存成功后，在生成订单之前，可以先在Redis中用一个set类型存储“用户ID:商品ID”这样的键，每次下单前用SADD命令尝试添加，如果返回1表示是第一次下单，可以继续；如果返回0，则表示已经下过单了，需要阻止,这比去数据库查订单表要快得多。
消息队列异步化处理 这是秒杀架构中非常重要的一环，Redis扣减库存成功，只是意味着“资格”拿到了，但真正的下单、支付流程很复杂，耗时较长，如果同步进行，系统很容易被拖垮，应该将扣减成功的消息立即放入一个Redis的list结构充当的消息队列中，然后立即返回用户“抢购中，请稍后查看结果”的提示，后端有专门的 worker 服务从队列中取出消息，慢慢地、异步地去完成数据库库存的最终扣减、生成订单等繁琐操作，这样就把瞬间的峰值压力变成了一个平滑的持续压力，保证了系统不会被冲垮，这种方法在淘宝、京东等大型电商的早期秒杀系统中被广泛使用。

第二部分：面试中必须懂的Redis核心点

除了秒杀，面试官还会考察你对Redis本身的理解深度,这些是基础。

数据类型及其应用场景 你不能只说得出五种基本类型（string, hash, list, set, zset）,还得说出它们分别用在什么地方。
- string：缓存用户信息、计数器、库存。
- hash：存储对象，比如用户的完整信息（姓名、年龄、城市）,比string更节省空间。
- list：消息队列（如上所述）、朋友圈时间线。
- set：好友共同关注（求交集）、随机抽奖（SRANDMEMBER）。
- zset：排行榜,带权重的队列。
持久化机制：RDB和AOF 这是必问的，你得知道Redis数据如何保证不丢，RDB是快照，在特定时间点生成数据备份，恢复快但可能丢失最后一次快照后的数据，AOF是记录每一个写命令，数据更安全但文件更大、恢复慢，生产环境通常两者结合使用，你要理解什么是AOF重写,以及它们各自的优缺点。
高可用：主从复制和哨兵模式 单点Redis挂了怎么办？所以需要主从复制（Master-Slave），数据从主节点同步到从节点，那主节点挂了怎么办？这就需要哨兵模式（Sentinel）了，哨兵会自动监控主节点，并在其宕机时自动选举一个从节点升级为新的主节点，实现故障自动转移,你要能说清楚大致的流程。
缓存问题：穿透、击穿、雪崩 这是缓存应用的经典难题,几乎必考。
- 穿透：查询一个根本不存在的数据，缓存和数据库都没有，解决方案是用布隆过滤器（Bloom Filter）快速判断数据是否存在,或者将空结果也缓存一小段时间。
- 击穿：某个热点key过期了，瞬间大量请求直接打到数据库，解决方案是设置热点key永不过期，或者使用互斥锁（比如Redis的SETNX命令），只让一个请求去加载数据,其他请求等待。
- 雪崩：大量key在同一时间过期，导致所有请求都打到数据库，解决方案是给key的过期时间加上随机值,避免同时失效。
为什么快？ 这个问题考察底层原理，核心答案通常是：基于内存操作；使用单线程避免了多线程的上下文切换和竞争开销（对于Redis 6.0以前版本）；使用了高效的I/O多路复用模型（如epoll）,能处理大量连接。