1. 项目复盘先看清黑马点评到底在练什么黑马点评这个项目在上海、杭州、深圳的Java培训班和自学圈子里几乎成了Redis落地实战的标配训练场。项目本身不复杂模拟的是大众点评/美团的本地生活业务用户登录、查看店铺、秒杀优惠券、好友关注动态、签到统计、附近商户搜索。但如果只把黑马点评当成一个“会跑就行”的CRUD练习那确实浪费了。它真正的价值在于把一个完整的业务系统拆成了若干个Redis经典痛点场景——缓存击穿怎么防、缓存穿透怎么挡、高并发秒杀怎么保库存不超卖、Feed流分页怎么做、亿级UV怎么用几KB内存统计出来。一个个都是面试官追着问而且是实际开发里真会踩的问题。这篇文章不是“照着笔记再抄一遍”而是我把自己复盘这个项目时的完整思路写下来业务设计为什么这么拆Redis每种数据结构为什么在这个场景用、换个场景又为什么不行落到代码层面那些参数和命令长什么样以及我跑通和跑挂过程中的一些教训。适合刚学完Redis、不知道怎么和Spring Boot结合的初级开发也适合准备面试、想把那些“背过的知识点”串成业务故事的人。更实在一点说如果你面试时能把黑马点评这套逻辑讲成一个有取舍、有代价、有排查过程的项目复盘效果比背十道八股文强得多。2. 整体设计与技术选型为什么偏偏是Redis打主力2.1 点评业务的三个核心矛盾黑马点评的Demo业务看着简单但它刻意覆盖了三种完全不同的流量特征第一店铺查询是典型的“高并发读”场景。一个热门商圈的店铺详情页QPS能冲到几千上万MySQL单表即使有索引在热点数据上也会被打穿。而且这类数据有冷热之分热门店铺被反复查冷门店铺一天没几个人看。这是缓存要解决的核心矛盾。第二优惠券秒杀是“瞬时高并发写”。一张限量券在0点放出来用户都在那一秒涌入背后是库存扣减和订单创建。数据库行锁在大量并发下吞吐骤降Redis是纯内存单线程执行指令天然适合扛瞬时写入但数据落库又必须可靠所以流程要拆成“Redis挡流量MySQL做最终落地”。第三好友动态和签到统计是“数据结构型需求”。Feed流要按时间倒序分页签到要按天做位图标记附近商户要按经纬度检索。MySQL当然也能做但要么分页性能差要么SQL写得绕要么压根没有合适的数据类型支持。Redis的ZSet、BitMap、GEO就是为这类场景设计的用对了代码量和性能同时改善。一个合格的实战项目它的系统设计应该反映这三个矛盾而不是把所有请求都直接怼到数据库里。2.2 核心表结构和数据模型在动手写代码之前先看数据模型。黑马点评里几个关键表特别值得留意商家表tb_shop核心字段是店铺ID、名称、地址、类型、经纬度。经纬度是后期做GEO附近搜索的原料。如果你后期用GEO指令做附近门店搜索就会发现MySQL里的经纬度字段存成DECIMAL(10,6)比较合适而且必须有索引否则SQL的WHERE latitude BETWEEN ...全表扫描会非常痛苦。优惠券表分两张tb_voucher存优惠券的基础信息比如面额、使用门槛、类型tb_seckill_voucher存秒杀专属信息库存、开始时间、结束时间。这两张表的设计是一对一关系在代码里通过优惠券ID关联。从我们的视角看这种拆分是有意为之普通优惠券和秒杀券的库存和活动策略完全不一样拆开后两种类型的扩展互不影响。后期做秒杀时库存扣减的SQL就落在tb_seckill_voucher这张表上行锁竞争也集中在这一行数据这就是超卖问题的根源。用户笔记表tb_blog和关注关系表tb_follow是Feed流的数据基础。tb_follow存储的是“谁关注了谁”查询时一个人关注的所有人然后拉取这些人的笔记列表——这就是“拉模式”黑马点评最终实现的是“推模式”做法是发笔记时主动写到每个粉丝的收件箱里具体用哪个Redis结构存收件箱后面细说。2.3 技术栈清单和选型理由整个项目是Spring Boot MyBatis Plus MySQL Redis的组合没有引入RabbitMQ或者Kafka这些重量级中间件。很多初学者会觉得奇怪异步下单用消息队列不是更正规吗为什么不引入MQ我的看法是这个项目的教学目标不是“会搭消息中间件”而是先把“为什么需要异步”以及“不引入新中间件时Redis能不能干这个活”想明白。Stream库可以满足大多数小规模异步场景作为教学它足够作为生产环境则要看团队运维能力。项目里用Redis的Stream做秒杀异步下单就是为了压低技术栈的复杂度同时又能把消息队列的消费者组、Pending List这些概念讲透。生产环境你完全可以换成RocketMQ或者RabbitMQ业务接口不变变的只是消息的写入和消费方式。3. 核心琐碎细节逐个拆代码和命令都摆出来3.1 登录态管理从Session到Redis Token黑马点评的登录逻辑不复杂但细节密度很高。它把“登录验证码校验”和“登录态保存”两件事分开了。验证码验证码存在Redis里key设计成login:code:手机号设置5分钟过期。校验时从Redis取出来和用户输入的对比对比完之后立刻删除——这是一个很小的细节但值得养成习惯一次性校验码用后即焚防止重放攻击。登录成功后不需要把用户信息全部塞Token里而是生成一个随机的UUID作为Token然后把用户对象序列化成JSON存进Rediskey是login:token:xxx有效期设30分钟。为什么不用JWT直接签名携带用户信息因为用Redis存登录态能做到主动失效管理员封号、用户修改密码、多端登录顶号都只需要删Redis Key而JWT签发之后在过期之前是没法主动作废的除非额外维护黑名单那又绕回来了。这里还有一个很多人在项目里忽略的细节 ——登录校验要做两层拦截器。第一层拦截器拦截所有请求只负责从Header里取Token如果存在就查Redis、把用户保存到ThreadLocal顺带刷新Token的过期时间不存在就放行不拦截。第二层拦截器只拦截需要登录的接口判断ThreadLocal里有没有用户没有就返回401。这么设计的目的是像查询店铺列表这种公开接口游客也可以访问但访问时如果带着Token也顺手把登录态续期了。只有真正需要身份的接口比如下单、发笔记才在第二层拦截器里强制校验。我见过很多开发把所有接口都拦成必须登录游客连首页都看不了体验很糟糕。3.2 缓存三大经典场景穿透、击穿、雪崩店铺按ID查询的这个接口是缓存三大问题的教学现场。很多同学把“缓存穿透、击穿、雪崩”背得滚瓜烂熟但在项目里不知道怎么用黑马点评恰好把三种问题都设计进去了。缓存穿透是指查一个Redis和MySQL都不存在的数据比如一个不存在的店铺ID请求每次都打到数据库。项目里的解法是查DB发现为空时在Redis里写一个空值TTL设短一些比如25分钟。这是一种空间换时间的解法简单有效但空值占内存、TTL窗口期内数据短暂不一致这两个副作用你能接受就行。另一种思路是布隆过滤器适合数据量大且不经常更新的场景但黑马点评这种单机教学项目缓存空值完全够用。缓存击穿指的是一个热点Key在过期的一瞬间大量请求同时涌到数据库。黑马点评提供了两套方案互斥锁和逻辑过期。互斥锁方案用的是Redis的SETNX在缓存失效时只允许一个线程去查DB并重建缓存其他线程要么等待、要么直接返回旧值。它的优点是数据一致性高但缺点是缓存重建期间其他线程要等待多多少少会增加响应时间。逻辑过期方案是把缓存永不过期在缓存对象里额外保存一个逻辑过期时间查询时发现逻辑过期后拿到互斥锁的线程在后台异步重建缓存拿不到锁的线程直接返回旧数据。它的优点是响应速度极快缺点是在重建成功的窗口期内读到的数据是旧数据。实际项目中大部分热点数据可以容忍秒级不一致所以逻辑过期方案应用得非常广。我用一张表把两套方案摆在一起对比对比项互斥锁逻辑过期数据一致性高重建期间无人读旧值低重建期内读旧值响应速度可能阻塞基本不受影响数据库压力单线程重建压力小单线程重建压力小实现复杂度低中需维护逻辑过期时间适用场景对一致性要求高的场景热点数据、可容忍短暂不一致缓存雪崩是因为大量Key集中在同一时间过期导致数据库被打挂。黑马点评的解法很务实给缓存TTL加一个随机值比如基础TTL 30分钟再加一个05分钟的随机偏移。这样就算一批数据在同一时间写入缓存过期时间也会被分散开。项目里这条逻辑不是重点但面试时你要能说清楚雪崩不光是同一时间过期也可能是Redis宕机这两种场景的应对策略完全不同前者靠随机TTL解决后者靠多级缓存和熔断降级解决。3.3 缓存与数据库的最终一致性缓存和数据库的双写一致性是项目里最容易被追问的问题。黑马点评的落地方案是更新数据库时先更新DB再删除缓存同时给所有缓存数据设置合理的过期时间兜底。为什么不直接更新缓存而是删除缓存因为更新缓存存在并发问题两个线程同时更新DB后更新的线程先把旧值写进了缓存另一个线程再写最后缓存里的值可能不是最新的。删除缓存就避免了“写缓存的值永远是对的”这个假设下次查询时缓存Miss再从DB读最新值重建。为什么不先删缓存再更新DB因为删除缓存和更新DB之间有一个时间窗口另一个请求可能把旧值又写回缓存DB随后更新缓存彻底变成脏数据。先更DB再删缓存理论上也有类似窗口但因为有TTL兜底最终会收敛。这里需要补充一个实际开发中常遇到的问题如果删除缓存失败了怎么办项目里可以引入重试机制或者采用延迟双删更新DB后延迟几百毫秒再删一次缓存。但在黑马点评这个单机项目里我的建议是不要过度设计因为设置了一个合理的过期时间后缓存最终会被过期机制自动清掉业务上可接受。面试时把这个逻辑讲清楚比一上来就宕机重试、消息队列补偿让人信服得多。4. 秒杀全流程超卖的7种死法4.1 库存扣减的乐观锁为什么必须带库存条件秒杀接口是整个项目的重头戏也是最容易玩崩的部分。第一版实现往往长这样Transactional public Result seckillVoucher(Long voucherId) { SeckillVoucher voucher seckillVoucherService.getById(voucherId); if (voucher.getStock() 1) { return Result.fail(库存不足); } boolean success seckillVoucherService.update() .setSql(stock stock - 1) .eq(voucher_id, voucherId) .update(); // 创建订单... }这个逻辑在低并发下没有问题但一旦并发上来就出现超卖。原因在于多个线程同时执行了“先查库存再扣减”两个步骤查库存的时间窗口内库存都是充足的然后大家一起扣库存变成负数。要解决超卖光在业务代码里判断库存是不够的必须把“检查库存是否大于0”和“扣减库存”合并在一条SQL里完成boolean success seckillVoucherService.update() .setSql(stock stock - 1) .eq(voucher_id, voucherId) .gt(stock, 0) // 关键库存必须大于0才执行扣减 .update();这条SQL利用数据库行锁和条件更新保证了扣减的原子性。MySQL在更新这行数据时会加行锁也就是说同一时刻只有一个事务能执行这条UPDATE其他事务只能等待。结合stock 0这个条件即使有1000个请求同时进来最终也只有库存数目的请求能更新成功其他请求的UPDATE影响行数是0不会把库存扣到负数。这就是乐观锁CAS思想在库存扣减场景的具体运用。为什么不用悲观锁SELECT FOR UPDATE因为悲观锁在并发量大的时候会产生大量锁等待数据库连接被占满吞吐量直线下降。乐观锁只在更新时短暂持锁性能好得多但代价是部分请求会失败需要在前端做友好的提示——“手慢了再抢一次”。4.2 一人一单的限制锁的粒度要细化库存不超卖只是第一关。业务上还有一个约束一个用户只能买一张秒杀券。如果用户每次都拿相同的用户ID来下单上面的扣库存逻辑完全拦不住因为两个并发请求都能成功扣库存然后创建两条订单。一人一单的实现最容易踩的坑是“锁加错了地方”。很多同学会写synchronized (this) { // 查询订单 if (existsOrder(userId, voucherId)) { return Result.fail(一人限购一单); } // 创建订单... }这个方法有两个问题第一synchronized (this)在单机多线程下确实能保证同一时间只有一个线程进入但在分布式部署时每个服务实例有自己的锁根本锁不住其他机器的请求第二即使只在单机运行锁的粒度太粗不同用户、不同优惠券的请求也会互相阻塞性能很差。正确的做法是使用分布式锁并且锁的粒度要细到 “用户 优惠券”这个维度String lockKey lock:order: userId : voucherId; boolean isLock stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (!isLock) { return Result.fail(请求频繁请稍后重试); } try { // 查询订单是否存在 // 不存在则创建订单 } finally { stringRedisTemplate.delete(lockKey); }这里必须注意几个坑setIfAbsent命令必须带过期时间否则如果业务执行过程中程序异常退出锁永远不会释放后面的请求全部被卡死。另外删除锁的时候要小心误删线程A的锁业务执行超时锁自动过期线程B拿到新锁这时候线程A终于执行完finally块里的delete把线程B的锁删掉了。解决方式是删除前比较锁的值每个线程写入一个唯一标识只有值匹配才删除。这个删除操作要和比较操作放在一个Lua脚本里保证原子性。4.3 异步下单Redis Stream是怎么顶替MQ的库存扣减解决了超卖一人一单解决了重复下单但新的问题又来了所有请求都在数据库行锁上排队秒杀接口的吞吐量并不高。黑马点评的进阶方案是库存预扣和一人一单的校验全部放到Redis里做通过的请求抛给异步队列慢慢落库。具体流程拆开是这样的请求进来先用Lua脚本一次性完成三个操作判断库存、判断用户是否已购买、扣减Redis里的库存。为什么用Lua脚本因为这三个步骤必须原子执行而Redis单线程执行Lua脚本期间不会穿插其他命令天然满足原子性。如果分开发三条命令中间任何一条失败都会留下脏状态。校验通过后往Redis Stream里写入一条下单消息。消息内容包括用户ID、优惠券ID和下单时间。一个独立的线程池或者定时任务异步消费Stream里的消息去MySQL里真实创建订单再次校验一人一单再次扣减数据库库存。为什么要用Redis Stream而不是简单地用一个List当队列因为Stream提供了消费者组的概念支持多个消费者实例分摊消息、消息确认机制ACK、以及“消息被处理过但未确认”的Pending列表。生产环境用MQ的一大原因就是消息不能丢Stream 的这些机制保证了消息在消费失败后还能被重新拉取。项目里虽然只是Demo但用Stream这套设计后期迁移到RabbitMQ时业务代码几乎不用改。下面给一个最核心的Lua脚本参考这是我从项目里整理出来的精简版但整体思路不变-- KEYS[1]: 秒杀券库存Key -- KEYS[2]: 用户已购KeyRedis Set类型存userId -- ARGV[1]: 优惠券ID -- ARGV[2]: 用户ID if tonumber(redis.call(get, KEYS[1])) 0 then return 1 end if redis.call(sismember, KEYS[2], ARGV[2]) 1 then return 2 end redis.call(decr, KEYS[1]) redis.call(sadd, KEYS[2], ARGV[2]) return 0消费端处理完一条消息后必须执行ACK否则重试机制会反复推送同一条消息导致重复下单。同时数据库里也要有兜底订单表用user_id voucher_id建唯一索引这样就算消息被重复消费数据库也会拒绝第二条订单的插入。Redis挡洪峰数据库兜底双保险才算完整。4.4 全局唯一ID生成为什么需要它秒杀订单表是分表分库时最先被拆的表因此订单ID不能依赖数据库自增ID需要全局唯一。黑马点评里用Redis的INCR命令生成序列号再结合时间戳拼成ID。做法大致是62位Long型前32位是时间戳后32位是Redis自增序列。在秒杀场景下一天的自增序列量完全能控制在32位范围内不需要担心溢出。有人会问不用Redis自增用雪花算法不行吗雪花算法生成的ID带机器标识但依赖机器时钟时钟回拨会出现重复IDRedisINCR天然单调递增在同一段时间内生成的ID还能反推出下单先后顺序对后续数据分析更友好。黑马点评选择Redis生成ID和项目本身的Redis技术栈一致逻辑简单部署不依赖额外组件。生产环境如果你的订单ID需要跨全局唯一且量大可以结合两者用时间戳 机器ID Redis分段自增这也是一条可以展开说的优化思路。5. 高级数据结构实战Feed流、签到、UV、附近的店5.1 好友关注Feed流为什么选推模式好友关注动态很多人第一反应是“查数据库”查出我关注的所有用户ID再查找这些用户发布的Blog按时间倒序返回。这就是拉模式。但这种做法有两个问题第一用户关注的人很多时IN查询的列表非常长MySQL的性能急剧下降第二每个用户的主页刷新都要做一次实时聚合查询数据库压力巨大。黑马点评用的是推模式当我发一条笔记时系统会遍历我的所有粉丝把这条笔记的ID写入每一个粉丝的收件箱。收件箱在Redis里就是一个ZSetmember存笔记IDscore存发笔记的时间戳。推模式的好处是查询路径极短用户刷新Feed流时直接查自己的收件箱ZSet按分数倒序取就能展示。坏处是写放大一个拥有10万粉丝的用户发一条笔记就要写10万个Redis Key如果粉丝量巨大写放大会成为瓶颈。所以实际大型系统里都是混合模式普通用户发帖用推模式大V发帖用拉模式普通用户关注大V时要么拉取发帖列表中聚合要么静态化一份大V的Feed给粉丝读。面试被问到“如果用户有几百万粉丝怎么办”时能答出来这套推拉结合方案说明你真的理解了这个设计的本质而不是只会写代码。5.2 Feed流滚动分页为什么不用offsetFeed流的分页非常讲究。普通业务分页用LIMIT offset, size没有太大问题但Feed流是实时动态变化的用户刚刷新时看到第1页看的过程中有人发了新笔记那用户往下翻第2页时offset偏移量已经不对了会出现两条数据重复或者漏数据的情况。黑马点评采用的方案是滚动分页核心是三条信息上一次翻页的最后一条记录的score值minScore以及这一页记录里有多少条score值和minScore相同offset。查询下一次分页时使用ZREVRANGEBYSCORE feed:userId inf (minScore LIMIT offset count注意(minScore代表不包含该分数LIMIT从offset开始取count条。这样即使Feed流里有新数据插入分页游标也不会受新数据影响不会重复也不会遗漏。这里有个细节同一秒内发布了多条笔记score会相同。假如上一次翻页最后一页的score是1700000000123而且这个分数出现了3条offset3那么下一页就要从这三条的下一条开始取也就是ZREVRANGEBYSCORE key inf (1700000000123 LIMIT 3 5。如果不记录这个offset在有并发发布的情况下可能丢掉几条或者重复几条。这个细节面试聊起来非常加分。5.3 签到统计BitMap的位运算妙用签到功能用MySQL也能做每个用户每天插入一条记录查询时数天数。但一个月30天一年365天数据库里每个用户的签到记录会膨胀得很快。BitMap的优雅之处在于一个用户一个月的签到情况只需要4个字节32位一年也不到46个字节。黑马点评的签到设计是key为sign:userId:年月每天签到时执行SETBIT sign:1001:202512 dayOffset 1。dayOffset的计算方式是这个月第几天减1比如12月5日签到的offset就是40代表1号。连续签到天数的统计是面试高频题难点在于“从今天往回数连续1的个数”。拿到当天offset值之后用位运算把一个字节右移并逐位与1进行与运算数到第一个不是1的位就停止。更高效的做法是取出用户这个月所有的签到位后用~取反然后用Integer.numberOfTrailingZeros数末尾0的个数这就是断签的位置。这个函数一行代码就能算出来但背后理解到位的人不多。5.4 UV统计和附近商户UV统计的特点是量极大、精度要求不高Redis的HyperLogLog正好是为此设计的。一个HyperLogLog键最多占用约12KB内存标准误差是0.81%可以统计到2^64级别。项目里的思路是每个页面或活动创建一个HyperLogLog键用户访问页面时执行PFADD page:uv:202512 用户ID统计时执行PFCOUNT page:uv:202512。哪怕访问量到百万千万级12KB的内存固定不变性价比极高。不适合用它统计业务上必须精确的数据比如订单数、余额这个要特别注意。附近商户靠的是Redis的GEO模块。写入店铺经纬度时执行GEOADD shop:geo 经度 纬度 店铺ID搜索附近5公里的店铺时执行GEOSEARCH shop:geo FROMLONLAT 经度 纬度 BYRADIUS 5 km ASC COUNT 20。底层原理是GeoHash编码把经纬度二维坐标通过二进制区间编码转成一维字符串越相邻的地点字符串前缀越相似。Redis再用ZSet结构存储GeoHash值范围搜索就变成ZSet的区间查询非常高效。用GEO之前要把业务想清楚它不是精确的地理系统边界上的判断会有几米的误差做“附近门店搜索”够用做精确的电子围栏就不太合适。6. 踩坑记录、排查方法和面试常问的雷区6.1 我实际跑这个项目时踩过的四个坑第一个坑是锁的误删。我最初实现分布式锁时用setIfAbsent加锁业务结束后直接delete释放。压测时发现锁偶尔会提前消失排查了半天才意识到是线程A执行超时后锁自动过期线程B拿到新锁随后线程A的delete把B的锁删了于是B和C同时进入临界区。后来加上了“删除前比较value是否是自己写入的值”的Lua脚本问题消失。第二个坑是缓存空值导致的内存膨胀。给店铺查询做了缓存穿透防护后恶意请求不断拼不存在的商铺IDRedis里堆积了大量空值键内存上涨很明显。后续做法是给空值键设置极短的TTL2分钟同时限定同一个空值key只写一次其他请求直接返回“店铺不存在”而不写入。第三个坑是Redis Stream消费后没有ACK。我把消费消息的逻辑写在独立线程后手工停了服务再重启后发现有大量重复订单。原因就是消费线程已经从Stream读取了消息但没有执行XACKPending列表里的消息又被重新投递。加上XACK和数据库订单表唯一索引的兜底后重复下单问题才彻底解决。第四个坑是一人一单的锁粒度太大。初版把锁key设计成lock:order: 优惠券ID测试时发现不同用户都在抢占同一把锁吞吐量十分拉胯。改成lock:order: userId “:” voucherId 之后不同用户之间完全没有锁竞争秒杀接口的TP99大幅下降。6.2 常见问题快速排查表以下是我整理的一份排查速查表项目跑得不正常时按表排查比自己瞎试高效得多。现象可能原因排查思路解决方案商品库存变成负数扣库存SQL缺少stock 0条件查看秒杀接口执行的UPDATE语句UPDATE语句加条件配合乐观锁同一个用户买了两张券一人一单校验和创建订单不是原子操作看日志中两个请求的执行顺序用分布式锁或Lua脚本保证原子性接口偶发卡顿DB活着但响应慢Redis锁过期时间太短业务没执行完锁就释放查看锁的过期时间和业务耗时引入看门狗自动续期或改用RedissonRedis内存缓慢增长缓存空值过多或Feed流收件箱无限增长INFO memory查看内存占用SCAN统计空值键数量空值TTL缩短收件箱ZSet做容量裁剪缓存重建风暴一个热点Key过期后大量线程同时查DB观察Redis命中率和DB的QPS曲线互斥锁或逻辑过期方案消息重复消费产生重复订单Stream消费线程未ACK或消费逻辑未幂等查看XACK是否执行订单表索引是否唯一消费后立即ACK订单表加唯一索引6.3 容易被追问的四个问题把答案想透第一个缓存一致性最终怎么保证逻辑要闭环。我一直坚持的回答是更新DB后删除缓存设置TTL兜底必要时延迟双删。面试官追问“删除失败怎么办”时不要说“消息队列补偿”这种腾空的话而是说“先保障DB正确缓存最终靠TTL收敛同时做好监控报警真正需要强一致性的数据直接走DB不走缓存”。第二个分布式锁如果Redis宕机怎么办。黑马点评的单机Redis确实有单点问题这个很现实。回答思路可以是单机Redis锁用在低风险场景为了高可用可以引入RedLock算法多个Redis节点投票但RedLock本身也有争议而且极端情况下依然可能出现两个节点同时成功。生产上对锁需求严格的话建议使用强一致性的中间件比如ZooKeeper或etcd牺牲部分性能换取确定性。第三个Stream消息积压怎么办。消费者组支持动态扩容消费者实例每个实例负责部分分区可以平行扩展消费能力。还要设置“最大消息堆积数”的监控超过阈值直接触发告警人工排查是消费线程卡死还是数据库慢了。秒杀场景里流转速度是第一位的宁可丢那条消息再补一次也不要让积压拖垮后面的所有请求。第四个为什么不直接引入MQ做异步下单。我的回答是项目目的是展示Redis能解决什么Stream已经提供了消费者组、ACK、Pending List等近似MQ的语义。引入MQ会增加部署和运维成本且面试官更想听到的是“我理解异步的本质是什么”而不是“我会用哪个组件”。7. 项目复盘的最后一个建议复盘黑马点评的过程让我最感慨的不是某个命令用法而是“很多看似高级的方案本质上都是在跟几个成本做斗争”数据库连接成本、网络往返成本、数据一致性窗口成本。你理解了这些成本再看缓存穿透的缓存空值、秒杀的Lua原子脚本、Feed流的推模式就全都通了。它们不是技巧而是特定约束下的必然选择。最后分享一个实操建议不要只把黑马点评的代码跑通就完事试着拦下几个接口用Redis的MONITOR命令看看到底执行了哪些Redis指令试着把秒杀流程画成一张时间线图标出每条命令的触发时刻和失败分支。这个动作花不了几个小时但做完之后你对Redis的理解会比刷十篇文章深刻得多。如果你正在做这个项目或者准备用这个项目面试希望你也能从这里拿走一点真正属于自己的东西。 
长河君 · 2026/9/30 3:05:27 · 阅读 1.2k 黑马点评项目复盘：Redis八大实战场景从缓存穿透到秒杀防超卖
1. 项目复盘先看清黑马点评到底在练什么黑马点评这个项目在上海、杭州、深圳的Java培训班和自学圈子里几乎成了Redis落地实战的标配训练场。项目本身不复杂模拟的是大众点评/美团的本地生活业务用户登录、查看店铺、秒杀优惠券、好友关注动态、签到统计、附近商户搜索。但如果只把黑马点评当成一个“会跑就行”的CRUD练习那确实浪费了。它真正的价值在于把一个完整的业务系统拆成了若干个Redis经典痛点场景——缓存击穿怎么防、缓存穿透怎么挡、高并发秒杀怎么保库存不超卖、Feed流分页怎么做、亿级UV怎么用几KB内存统计出来。一个个都是面试官追着问而且是实际开发里真会踩的问题。这篇文章不是“照着笔记再抄一遍”而是我把自己复盘这个项目时的完整思路写下来业务设计为什么这么拆Redis每种数据结构为什么在这个场景用、换个场景又为什么不行落到代码层面那些参数和命令长什么样以及我跑通和跑挂过程中的一些教训。适合刚学完Redis、不知道怎么和Spring Boot结合的初级开发也适合准备面试、想把那些“背过的知识点”串成业务故事的人。更实在一点说如果你面试时能把黑马点评这套逻辑讲成一个有取舍、有代价、有排查过程的项目复盘效果比背十道八股文强得多。2. 整体设计与技术选型为什么偏偏是Redis打主力2.1 点评业务的三个核心矛盾黑马点评的Demo业务看着简单但它刻意覆盖了三种完全不同的流量特征第一店铺查询是典型的“高并发读”场景。一个热门商圈的店铺详情页QPS能冲到几千上万MySQL单表即使有索引在热点数据上也会被打穿。而且这类数据有冷热之分热门店铺被反复查冷门店铺一天没几个人看。这是缓存要解决的核心矛盾。第二优惠券秒杀是“瞬时高并发写”。一张限量券在0点放出来用户都在那一秒涌入背后是库存扣减和订单创建。数据库行锁在大量并发下吞吐骤降Redis是纯内存单线程执行指令天然适合扛瞬时写入但数据落库又必须可靠所以流程要拆成“Redis挡流量MySQL做最终落地”。第三好友动态和签到统计是“数据结构型需求”。Feed流要按时间倒序分页签到要按天做位图标记附近商户要按经纬度检索。MySQL当然也能做但要么分页性能差要么SQL写得绕要么压根没有合适的数据类型支持。Redis的ZSet、BitMap、GEO就是为这类场景设计的用对了代码量和性能同时改善。一个合格的实战项目它的系统设计应该反映这三个矛盾而不是把所有请求都直接怼到数据库里。2.2 核心表结构和数据模型在动手写代码之前先看数据模型。黑马点评里几个关键表特别值得留意商家表tb_shop核心字段是店铺ID、名称、地址、类型、经纬度。经纬度是后期做GEO附近搜索的原料。如果你后期用GEO指令做附近门店搜索就会发现MySQL里的经纬度字段存成DECIMAL(10,6)比较合适而且必须有索引否则SQL的WHERE latitude BETWEEN ...全表扫描会非常痛苦。优惠券表分两张tb_voucher存优惠券的基础信息比如面额、使用门槛、类型tb_seckill_voucher存秒杀专属信息库存、开始时间、结束时间。这两张表的设计是一对一关系在代码里通过优惠券ID关联。从我们的视角看这种拆分是有意为之普通优惠券和秒杀券的库存和活动策略完全不一样拆开后两种类型的扩展互不影响。后期做秒杀时库存扣减的SQL就落在tb_seckill_voucher这张表上行锁竞争也集中在这一行数据这就是超卖问题的根源。用户笔记表tb_blog和关注关系表tb_follow是Feed流的数据基础。tb_follow存储的是“谁关注了谁”查询时一个人关注的所有人然后拉取这些人的笔记列表——这就是“拉模式”黑马点评最终实现的是“推模式”做法是发笔记时主动写到每个粉丝的收件箱里具体用哪个Redis结构存收件箱后面细说。2.3 技术栈清单和选型理由整个项目是Spring Boot MyBatis Plus MySQL Redis的组合没有引入RabbitMQ或者Kafka这些重量级中间件。很多初学者会觉得奇怪异步下单用消息队列不是更正规吗为什么不引入MQ我的看法是这个项目的教学目标不是“会搭消息中间件”而是先把“为什么需要异步”以及“不引入新中间件时Redis能不能干这个活”想明白。Stream库可以满足大多数小规模异步场景作为教学它足够作为生产环境则要看团队运维能力。项目里用Redis的Stream做秒杀异步下单就是为了压低技术栈的复杂度同时又能把消息队列的消费者组、Pending List这些概念讲透。生产环境你完全可以换成RocketMQ或者RabbitMQ业务接口不变变的只是消息的写入和消费方式。3. 核心琐碎细节逐个拆代码和命令都摆出来3.1 登录态管理从Session到Redis Token黑马点评的登录逻辑不复杂但细节密度很高。它把“登录验证码校验”和“登录态保存”两件事分开了。验证码验证码存在Redis里key设计成login:code:手机号设置5分钟过期。校验时从Redis取出来和用户输入的对比对比完之后立刻删除——这是一个很小的细节但值得养成习惯一次性校验码用后即焚防止重放攻击。登录成功后不需要把用户信息全部塞Token里而是生成一个随机的UUID作为Token然后把用户对象序列化成JSON存进Rediskey是login:token:xxx有效期设30分钟。为什么不用JWT直接签名携带用户信息因为用Redis存登录态能做到主动失效管理员封号、用户修改密码、多端登录顶号都只需要删Redis Key而JWT签发之后在过期之前是没法主动作废的除非额外维护黑名单那又绕回来了。这里还有一个很多人在项目里忽略的细节 ——登录校验要做两层拦截器。第一层拦截器拦截所有请求只负责从Header里取Token如果存在就查Redis、把用户保存到ThreadLocal顺带刷新Token的过期时间不存在就放行不拦截。第二层拦截器只拦截需要登录的接口判断ThreadLocal里有没有用户没有就返回401。这么设计的目的是像查询店铺列表这种公开接口游客也可以访问但访问时如果带着Token也顺手把登录态续期了。只有真正需要身份的接口比如下单、发笔记才在第二层拦截器里强制校验。我见过很多开发把所有接口都拦成必须登录游客连首页都看不了体验很糟糕。3.2 缓存三大经典场景穿透、击穿、雪崩店铺按ID查询的这个接口是缓存三大问题的教学现场。很多同学把“缓存穿透、击穿、雪崩”背得滚瓜烂熟但在项目里不知道怎么用黑马点评恰好把三种问题都设计进去了。缓存穿透是指查一个Redis和MySQL都不存在的数据比如一个不存在的店铺ID请求每次都打到数据库。项目里的解法是查DB发现为空时在Redis里写一个空值TTL设短一些比如25分钟。这是一种空间换时间的解法简单有效但空值占内存、TTL窗口期内数据短暂不一致这两个副作用你能接受就行。另一种思路是布隆过滤器适合数据量大且不经常更新的场景但黑马点评这种单机教学项目缓存空值完全够用。缓存击穿指的是一个热点Key在过期的一瞬间大量请求同时涌到数据库。黑马点评提供了两套方案互斥锁和逻辑过期。互斥锁方案用的是Redis的SETNX在缓存失效时只允许一个线程去查DB并重建缓存其他线程要么等待、要么直接返回旧值。它的优点是数据一致性高但缺点是缓存重建期间其他线程要等待多多少少会增加响应时间。逻辑过期方案是把缓存永不过期在缓存对象里额外保存一个逻辑过期时间查询时发现逻辑过期后拿到互斥锁的线程在后台异步重建缓存拿不到锁的线程直接返回旧数据。它的优点是响应速度极快缺点是在重建成功的窗口期内读到的数据是旧数据。实际项目中大部分热点数据可以容忍秒级不一致所以逻辑过期方案应用得非常广。我用一张表把两套方案摆在一起对比对比项互斥锁逻辑过期数据一致性高重建期间无人读旧值低重建期内读旧值响应速度可能阻塞基本不受影响数据库压力单线程重建压力小单线程重建压力小实现复杂度低中需维护逻辑过期时间适用场景对一致性要求高的场景热点数据、可容忍短暂不一致缓存雪崩是因为大量Key集中在同一时间过期导致数据库被打挂。黑马点评的解法很务实给缓存TTL加一个随机值比如基础TTL 30分钟再加一个05分钟的随机偏移。这样就算一批数据在同一时间写入缓存过期时间也会被分散开。项目里这条逻辑不是重点但面试时你要能说清楚雪崩不光是同一时间过期也可能是Redis宕机这两种场景的应对策略完全不同前者靠随机TTL解决后者靠多级缓存和熔断降级解决。3.3 缓存与数据库的最终一致性缓存和数据库的双写一致性是项目里最容易被追问的问题。黑马点评的落地方案是更新数据库时先更新DB再删除缓存同时给所有缓存数据设置合理的过期时间兜底。为什么不直接更新缓存而是删除缓存因为更新缓存存在并发问题两个线程同时更新DB后更新的线程先把旧值写进了缓存另一个线程再写最后缓存里的值可能不是最新的。删除缓存就避免了“写缓存的值永远是对的”这个假设下次查询时缓存Miss再从DB读最新值重建。为什么不先删缓存再更新DB因为删除缓存和更新DB之间有一个时间窗口另一个请求可能把旧值又写回缓存DB随后更新缓存彻底变成脏数据。先更DB再删缓存理论上也有类似窗口但因为有TTL兜底最终会收敛。这里需要补充一个实际开发中常遇到的问题如果删除缓存失败了怎么办项目里可以引入重试机制或者采用延迟双删更新DB后延迟几百毫秒再删一次缓存。但在黑马点评这个单机项目里我的建议是不要过度设计因为设置了一个合理的过期时间后缓存最终会被过期机制自动清掉业务上可接受。面试时把这个逻辑讲清楚比一上来就宕机重试、消息队列补偿让人信服得多。4. 秒杀全流程超卖的7种死法4.1 库存扣减的乐观锁为什么必须带库存条件秒杀接口是整个项目的重头戏也是最容易玩崩的部分。第一版实现往往长这样Transactional public Result seckillVoucher(Long voucherId) { SeckillVoucher voucher seckillVoucherService.getById(voucherId); if (voucher.getStock() 1) { return Result.fail(库存不足); } boolean success seckillVoucherService.update() .setSql(stock stock - 1) .eq(voucher_id, voucherId) .update(); // 创建订单... }这个逻辑在低并发下没有问题但一旦并发上来就出现超卖。原因在于多个线程同时执行了“先查库存再扣减”两个步骤查库存的时间窗口内库存都是充足的然后大家一起扣库存变成负数。要解决超卖光在业务代码里判断库存是不够的必须把“检查库存是否大于0”和“扣减库存”合并在一条SQL里完成boolean success seckillVoucherService.update() .setSql(stock stock - 1) .eq(voucher_id, voucherId) .gt(stock, 0) // 关键库存必须大于0才执行扣减 .update();这条SQL利用数据库行锁和条件更新保证了扣减的原子性。MySQL在更新这行数据时会加行锁也就是说同一时刻只有一个事务能执行这条UPDATE其他事务只能等待。结合stock 0这个条件即使有1000个请求同时进来最终也只有库存数目的请求能更新成功其他请求的UPDATE影响行数是0不会把库存扣到负数。这就是乐观锁CAS思想在库存扣减场景的具体运用。为什么不用悲观锁SELECT FOR UPDATE因为悲观锁在并发量大的时候会产生大量锁等待数据库连接被占满吞吐量直线下降。乐观锁只在更新时短暂持锁性能好得多但代价是部分请求会失败需要在前端做友好的提示——“手慢了再抢一次”。4.2 一人一单的限制锁的粒度要细化库存不超卖只是第一关。业务上还有一个约束一个用户只能买一张秒杀券。如果用户每次都拿相同的用户ID来下单上面的扣库存逻辑完全拦不住因为两个并发请求都能成功扣库存然后创建两条订单。一人一单的实现最容易踩的坑是“锁加错了地方”。很多同学会写synchronized (this) { // 查询订单 if (existsOrder(userId, voucherId)) { return Result.fail(一人限购一单); } // 创建订单... }这个方法有两个问题第一synchronized (this)在单机多线程下确实能保证同一时间只有一个线程进入但在分布式部署时每个服务实例有自己的锁根本锁不住其他机器的请求第二即使只在单机运行锁的粒度太粗不同用户、不同优惠券的请求也会互相阻塞性能很差。正确的做法是使用分布式锁并且锁的粒度要细到 “用户 优惠券”这个维度String lockKey lock:order: userId : voucherId; boolean isLock stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (!isLock) { return Result.fail(请求频繁请稍后重试); } try { // 查询订单是否存在 // 不存在则创建订单 } finally { stringRedisTemplate.delete(lockKey); }这里必须注意几个坑setIfAbsent命令必须带过期时间否则如果业务执行过程中程序异常退出锁永远不会释放后面的请求全部被卡死。另外删除锁的时候要小心误删线程A的锁业务执行超时锁自动过期线程B拿到新锁这时候线程A终于执行完finally块里的delete把线程B的锁删掉了。解决方式是删除前比较锁的值每个线程写入一个唯一标识只有值匹配才删除。这个删除操作要和比较操作放在一个Lua脚本里保证原子性。4.3 异步下单Redis Stream是怎么顶替MQ的库存扣减解决了超卖一人一单解决了重复下单但新的问题又来了所有请求都在数据库行锁上排队秒杀接口的吞吐量并不高。黑马点评的进阶方案是库存预扣和一人一单的校验全部放到Redis里做通过的请求抛给异步队列慢慢落库。具体流程拆开是这样的请求进来先用Lua脚本一次性完成三个操作判断库存、判断用户是否已购买、扣减Redis里的库存。为什么用Lua脚本因为这三个步骤必须原子执行而Redis单线程执行Lua脚本期间不会穿插其他命令天然满足原子性。如果分开发三条命令中间任何一条失败都会留下脏状态。校验通过后往Redis Stream里写入一条下单消息。消息内容包括用户ID、优惠券ID和下单时间。一个独立的线程池或者定时任务异步消费Stream里的消息去MySQL里真实创建订单再次校验一人一单再次扣减数据库库存。为什么要用Redis Stream而不是简单地用一个List当队列因为Stream提供了消费者组的概念支持多个消费者实例分摊消息、消息确认机制ACK、以及“消息被处理过但未确认”的Pending列表。生产环境用MQ的一大原因就是消息不能丢Stream 的这些机制保证了消息在消费失败后还能被重新拉取。项目里虽然只是Demo但用Stream这套设计后期迁移到RabbitMQ时业务代码几乎不用改。下面给一个最核心的Lua脚本参考这是我从项目里整理出来的精简版但整体思路不变-- KEYS[1]: 秒杀券库存Key -- KEYS[2]: 用户已购KeyRedis Set类型存userId -- ARGV[1]: 优惠券ID -- ARGV[2]: 用户ID if tonumber(redis.call(get, KEYS[1])) 0 then return 1 end if redis.call(sismember, KEYS[2], ARGV[2]) 1 then return 2 end redis.call(decr, KEYS[1]) redis.call(sadd, KEYS[2], ARGV[2]) return 0消费端处理完一条消息后必须执行ACK否则重试机制会反复推送同一条消息导致重复下单。同时数据库里也要有兜底订单表用user_id voucher_id建唯一索引这样就算消息被重复消费数据库也会拒绝第二条订单的插入。Redis挡洪峰数据库兜底双保险才算完整。4.4 全局唯一ID生成为什么需要它秒杀订单表是分表分库时最先被拆的表因此订单ID不能依赖数据库自增ID需要全局唯一。黑马点评里用Redis的INCR命令生成序列号再结合时间戳拼成ID。做法大致是62位Long型前32位是时间戳后32位是Redis自增序列。在秒杀场景下一天的自增序列量完全能控制在32位范围内不需要担心溢出。有人会问不用Redis自增用雪花算法不行吗雪花算法生成的ID带机器标识但依赖机器时钟时钟回拨会出现重复IDRedisINCR天然单调递增在同一段时间内生成的ID还能反推出下单先后顺序对后续数据分析更友好。黑马点评选择Redis生成ID和项目本身的Redis技术栈一致逻辑简单部署不依赖额外组件。生产环境如果你的订单ID需要跨全局唯一且量大可以结合两者用时间戳 机器ID Redis分段自增这也是一条可以展开说的优化思路。5. 高级数据结构实战Feed流、签到、UV、附近的店5.1 好友关注Feed流为什么选推模式好友关注动态很多人第一反应是“查数据库”查出我关注的所有用户ID再查找这些用户发布的Blog按时间倒序返回。这就是拉模式。但这种做法有两个问题第一用户关注的人很多时IN查询的列表非常长MySQL的性能急剧下降第二每个用户的主页刷新都要做一次实时聚合查询数据库压力巨大。黑马点评用的是推模式当我发一条笔记时系统会遍历我的所有粉丝把这条笔记的ID写入每一个粉丝的收件箱。收件箱在Redis里就是一个ZSetmember存笔记IDscore存发笔记的时间戳。推模式的好处是查询路径极短用户刷新Feed流时直接查自己的收件箱ZSet按分数倒序取就能展示。坏处是写放大一个拥有10万粉丝的用户发一条笔记就要写10万个Redis Key如果粉丝量巨大写放大会成为瓶颈。所以实际大型系统里都是混合模式普通用户发帖用推模式大V发帖用拉模式普通用户关注大V时要么拉取发帖列表中聚合要么静态化一份大V的Feed给粉丝读。面试被问到“如果用户有几百万粉丝怎么办”时能答出来这套推拉结合方案说明你真的理解了这个设计的本质而不是只会写代码。5.2 Feed流滚动分页为什么不用offsetFeed流的分页非常讲究。普通业务分页用LIMIT offset, size没有太大问题但Feed流是实时动态变化的用户刚刷新时看到第1页看的过程中有人发了新笔记那用户往下翻第2页时offset偏移量已经不对了会出现两条数据重复或者漏数据的情况。黑马点评采用的方案是滚动分页核心是三条信息上一次翻页的最后一条记录的score值minScore以及这一页记录里有多少条score值和minScore相同offset。查询下一次分页时使用ZREVRANGEBYSCORE feed:userId inf (minScore LIMIT offset count注意(minScore代表不包含该分数LIMIT从offset开始取count条。这样即使Feed流里有新数据插入分页游标也不会受新数据影响不会重复也不会遗漏。这里有个细节同一秒内发布了多条笔记score会相同。假如上一次翻页最后一页的score是1700000000123而且这个分数出现了3条offset3那么下一页就要从这三条的下一条开始取也就是ZREVRANGEBYSCORE key inf (1700000000123 LIMIT 3 5。如果不记录这个offset在有并发发布的情况下可能丢掉几条或者重复几条。这个细节面试聊起来非常加分。5.3 签到统计BitMap的位运算妙用签到功能用MySQL也能做每个用户每天插入一条记录查询时数天数。但一个月30天一年365天数据库里每个用户的签到记录会膨胀得很快。BitMap的优雅之处在于一个用户一个月的签到情况只需要4个字节32位一年也不到46个字节。黑马点评的签到设计是key为sign:userId:年月每天签到时执行SETBIT sign:1001:202512 dayOffset 1。dayOffset的计算方式是这个月第几天减1比如12月5日签到的offset就是40代表1号。连续签到天数的统计是面试高频题难点在于“从今天往回数连续1的个数”。拿到当天offset值之后用位运算把一个字节右移并逐位与1进行与运算数到第一个不是1的位就停止。更高效的做法是取出用户这个月所有的签到位后用~取反然后用Integer.numberOfTrailingZeros数末尾0的个数这就是断签的位置。这个函数一行代码就能算出来但背后理解到位的人不多。5.4 UV统计和附近商户UV统计的特点是量极大、精度要求不高Redis的HyperLogLog正好是为此设计的。一个HyperLogLog键最多占用约12KB内存标准误差是0.81%可以统计到2^64级别。项目里的思路是每个页面或活动创建一个HyperLogLog键用户访问页面时执行PFADD page:uv:202512 用户ID统计时执行PFCOUNT page:uv:202512。哪怕访问量到百万千万级12KB的内存固定不变性价比极高。不适合用它统计业务上必须精确的数据比如订单数、余额这个要特别注意。附近商户靠的是Redis的GEO模块。写入店铺经纬度时执行GEOADD shop:geo 经度 纬度 店铺ID搜索附近5公里的店铺时执行GEOSEARCH shop:geo FROMLONLAT 经度 纬度 BYRADIUS 5 km ASC COUNT 20。底层原理是GeoHash编码把经纬度二维坐标通过二进制区间编码转成一维字符串越相邻的地点字符串前缀越相似。Redis再用ZSet结构存储GeoHash值范围搜索就变成ZSet的区间查询非常高效。用GEO之前要把业务想清楚它不是精确的地理系统边界上的判断会有几米的误差做“附近门店搜索”够用做精确的电子围栏就不太合适。6. 踩坑记录、排查方法和面试常问的雷区6.1 我实际跑这个项目时踩过的四个坑第一个坑是锁的误删。我最初实现分布式锁时用setIfAbsent加锁业务结束后直接delete释放。压测时发现锁偶尔会提前消失排查了半天才意识到是线程A执行超时后锁自动过期线程B拿到新锁随后线程A的delete把B的锁删了于是B和C同时进入临界区。后来加上了“删除前比较value是否是自己写入的值”的Lua脚本问题消失。第二个坑是缓存空值导致的内存膨胀。给店铺查询做了缓存穿透防护后恶意请求不断拼不存在的商铺IDRedis里堆积了大量空值键内存上涨很明显。后续做法是给空值键设置极短的TTL2分钟同时限定同一个空值key只写一次其他请求直接返回“店铺不存在”而不写入。第三个坑是Redis Stream消费后没有ACK。我把消费消息的逻辑写在独立线程后手工停了服务再重启后发现有大量重复订单。原因就是消费线程已经从Stream读取了消息但没有执行XACKPending列表里的消息又被重新投递。加上XACK和数据库订单表唯一索引的兜底后重复下单问题才彻底解决。第四个坑是一人一单的锁粒度太大。初版把锁key设计成lock:order: 优惠券ID测试时发现不同用户都在抢占同一把锁吞吐量十分拉胯。改成lock:order: userId “:” voucherId 之后不同用户之间完全没有锁竞争秒杀接口的TP99大幅下降。6.2 常见问题快速排查表以下是我整理的一份排查速查表项目跑得不正常时按表排查比自己瞎试高效得多。现象可能原因排查思路解决方案商品库存变成负数扣库存SQL缺少stock 0条件查看秒杀接口执行的UPDATE语句UPDATE语句加条件配合乐观锁同一个用户买了两张券一人一单校验和创建订单不是原子操作看日志中两个请求的执行顺序用分布式锁或Lua脚本保证原子性接口偶发卡顿DB活着但响应慢Redis锁过期时间太短业务没执行完锁就释放查看锁的过期时间和业务耗时引入看门狗自动续期或改用RedissonRedis内存缓慢增长缓存空值过多或Feed流收件箱无限增长INFO memory查看内存占用SCAN统计空值键数量空值TTL缩短收件箱ZSet做容量裁剪缓存重建风暴一个热点Key过期后大量线程同时查DB观察Redis命中率和DB的QPS曲线互斥锁或逻辑过期方案消息重复消费产生重复订单Stream消费线程未ACK或消费逻辑未幂等查看XACK是否执行订单表索引是否唯一消费后立即ACK订单表加唯一索引6.3 容易被追问的四个问题把答案想透第一个缓存一致性最终怎么保证逻辑要闭环。我一直坚持的回答是更新DB后删除缓存设置TTL兜底必要时延迟双删。面试官追问“删除失败怎么办”时不要说“消息队列补偿”这种腾空的话而是说“先保障DB正确缓存最终靠TTL收敛同时做好监控报警真正需要强一致性的数据直接走DB不走缓存”。第二个分布式锁如果Redis宕机怎么办。黑马点评的单机Redis确实有单点问题这个很现实。回答思路可以是单机Redis锁用在低风险场景为了高可用可以引入RedLock算法多个Redis节点投票但RedLock本身也有争议而且极端情况下依然可能出现两个节点同时成功。生产上对锁需求严格的话建议使用强一致性的中间件比如ZooKeeper或etcd牺牲部分性能换取确定性。第三个Stream消息积压怎么办。消费者组支持动态扩容消费者实例每个实例负责部分分区可以平行扩展消费能力。还要设置“最大消息堆积数”的监控超过阈值直接触发告警人工排查是消费线程卡死还是数据库慢了。秒杀场景里流转速度是第一位的宁可丢那条消息再补一次也不要让积压拖垮后面的所有请求。第四个为什么不直接引入MQ做异步下单。我的回答是项目目的是展示Redis能解决什么Stream已经提供了消费者组、ACK、Pending List等近似MQ的语义。引入MQ会增加部署和运维成本且面试官更想听到的是“我理解异步的本质是什么”而不是“我会用哪个组件”。7. 项目复盘的最后一个建议复盘黑马点评的过程让我最感慨的不是某个命令用法而是“很多看似高级的方案本质上都是在跟几个成本做斗争”数据库连接成本、网络往返成本、数据一致性窗口成本。你理解了这些成本再看缓存穿透的缓存空值、秒杀的Lua原子脚本、Feed流的推模式就全都通了。它们不是技巧而是特定约束下的必然选择。最后分享一个实操建议不要只把黑马点评的代码跑通就完事试着拦下几个接口用Redis的MONITOR命令看看到底执行了哪些Redis指令试着把秒杀流程画成一张时间线图标出每条命令的触发时刻和失败分支。这个动作花不了几个小时但做完之后你对Redis的理解会比刷十篇文章深刻得多。如果你正在做这个项目或者准备用这个项目面试希望你也能从这里拿走一点真正属于自己的东西。