1. 项目整体拆解黑马点评到底在教什么1.1 业务形态与教学定位黑马点评是黑马程序员后端的经典实战项目很多人第一次接触它的时候会以为就是一个“仿大众点评”的CRUD练习实际跟完一遍你会发现这个项目的定位远比“增删改查”深得多。它把一个真实互联网业务里的核心问题全部压缩到一个可运行、可演示、可被面试官追问的闭环里包括缓存设计、高并发秒杀、分布式锁、流式推送、位图统计等。我做这套项目的时间点比较早最初是冲着“点评”两个字去的想看看商户查询和用户点评怎么做。结果越往后越发现项目核心根本不是点评而是Redis的多场景深度使用。商户数据缓存、点赞排行榜、好友关注Feed流、签到统计、秒杀优惠券几乎每一章都在教你“某个业务场景该用Redis的哪种数据结构和哪种设计策略”这个思路放到任何互联网后端面试里都能直接迁移使用。适合谁一句话Java后端基础学完懂Spring Boot会用Redis简单命令但不知道真实项目里Redis怎么落地的人。这个项目恰好补齐了“会用”和“会用对”之间的那段距离。1.2 核心业务链路梳理整个黑马点评的业务链路并不复杂主线可以分成五条商户查询与缓存用户打开App首页、搜索附近门店、查看商铺详情背后都是高并发读场景。优惠券秒杀定时开放一批限量券大量用户同时抢购涉及库存扣减、一人一单、瞬时流量削峰。点赞与排行榜用户对笔记点赞需要实时统计点赞数、展示点赞排行榜。好友关注与Feed流推送用户关注博主后能刷到博主发布的笔记类似简化版微博时间线。签到统计用户连续签到记录每日签到状态并统计连续天数。这五条链路几乎覆盖了Redis五种常用数据结构String、Hash、List、ZSet、Set还额外扩展了Geo、HyperLogLog、BitMap以及Stream队列。把这五条链路看懂Redis就不再是面试题里孤立的知识点而是一张能挂到业务上的知识网。我的建议是不要一上来就盯着代码敲先把这五条链路的请求入口、数据流方向、涉及的数据结构画清楚。这一遍“结构化”的工作决定你是学会了还是只是“跟着写完了”。2. 缓存设计的三个坑与应对2.1 缓存穿透布隆过滤器 VS 缓存空值商户查询是黑马点评最先接触缓存的场景套路很典型先查Redis没有就查数据库再把结果写回缓存。这个套路看着简单实际一压测就崩因为它默认了一个前提——数据库里一定查得到数据。真实世界里用户拿着一个不存在的商铺ID来查或者恶意用户拿随机ID批量请求缓存永远不命中所有流量直接打到数据库这就叫缓存穿透。黑马点评里给出了两个解决方案一个是缓存空值一个是布隆过滤器。缓存空值的意思是数据库查不到结果时也把“空”写进缓存设置一个较短的过期时间比如两到三分钟。好处是直观、不需要额外组件坏处是大量不存在的ID会产生一批无用缓存且可能短暂造成数据不一致。布隆过滤器则是预先把所有合法ID映射进一个位图结构请求进来先判断ID是否可能存在不存在直接拒绝连缓存都不用查。优点是拦截更前置、内存占用极低缺点是存在误判率会把少量不存在的ID放过而且要求ID集合相对稳定新增ID需要同步更新过滤器。实际项目中我倾向于把两者结合布隆过滤器拦截绝大多数无效请求缓存空值兜底那些“合法但无结果”的查询。黑马点评里虽然单独讲你完全可以组合使用。关键点在于空值缓存的过期时间要短并且要设定一个开关压测或活动期间能动态调整。2.2 缓存雪崩与缓存击穿逻辑过期方案实战如果说穿透是“查了没有”那击穿就是“查了突然过期了再排队进”。一个热点商户的缓存正好在某一刻过期下一秒成千上万请求同时发现缓存Miss全部涌向数据库这一下就能把数据库打挂。雪崩则更恐怖——大量缓存在同一时间段集中失效数据库瞬间承受全部流量。黑马点评给出的解决方案是“逻辑过期”而不是缩短过期时间或者加随机值这是一个很实际的处理手法。做法是给每个缓存value增加一个逻辑过期时间字段比如存一个JSON里面既有商户数据也有一个过期时间戳。每次读取到缓存数据时先比较逻辑过期时间如果没过期直接返回缓存数据如果过期了返回“旧数据”的同时启动一个独立线程去重建缓存。这个方案乍一看违反直觉——用户读到了过期数据不脏吗但分布式系统里这类场景本身就允许一定时间内的数据短暂不一致。换取的是系统可用性即使热点Key失效也不会打垮数据库。对比一下业界常用方案互斥锁分布式锁Maintain缓存重建能保证数据绝对一致但会让请求排队等待吞吐量严重受损。逻辑过期方案牺牲了一致性换来了更高的并发能力而且不需要像Redis官方推荐的“提前更新”策略那样精确控制时间。我在真实项目里把逻辑过期做成了一个公用组件缓存对象额外包一层RedisData 结构封装了过期时间戳和真实数据序列化时统一处理。黑马点评教学里没把这个封装成独立类但你在简历上写“设计并实现通用的带逻辑过期缓存组件”面试官会高看你一眼。2.3 双写一致性延迟双删与Canal缓存和数据库的双写一致性问题在黑马点评里其实没有大篇幅展开但被问到的概率极高尤其是“商品更新后缓存怎么更新”这种问题。最朴素的想法是“先更新数据库再删除缓存”但这有个经典坑并发情况下A线程更新数据库后还没来得及删除缓存B线程刚好读到了旧缓存并把它回填到了Redis里结果A的删除被覆盖缓存里永远是旧数据。黑马点评里用的方案是“延迟双删”先删除缓存再更新数据库隔几百毫秒再删除一次缓存。第二次删除就是为了清掉并发期间B线程回填的脏缓存。这个方案简单却有个参数很讲究——延迟多久。太短B线程还没写完缓存你就删了太长用户会一直读旧缓存。我在实际项目中一般取500毫秒到1秒具体看业务的读多写少程度和数据库耗时。如果你追求更彻底的方案线上高并发系统更推荐用Canal订阅MySQL的binlog变更监听到数据变更后由独立服务异步删除缓存或者直接更新缓存。Canal方案的优势是解耦应用层不用管缓存更新逻辑但引入了一套新的中间件成本。黑马点评没讲那么深面试时你主动提一嘴“我知道延迟双删的局限生产级方案一般用订阅binlog做异步刷新”这就能和大部分背答案的候选人拉开差距。3. 秒杀场景的分布式锁演进3.1 从SetNX到Redisson锁黑马点评的优惠券秒杀是整个项目最硬核的部分也是面试官最喜欢深挖的一段。秒杀的核心矛盾就两个库存不能超卖一人不能买多单。而实现这两个约束绕不开分布式锁。项目初期的版本是用Redis的SetNX命令手写锁代码很短思路是抢到锁就执行下单抢不到就返回“抢购失败”。但手写锁的问题很快就暴露了——如果拿到锁的线程在执行过程中挂了锁永远不会释放其他线程全被卡死。于是加了过期时间结果新的问题又出来如果业务执行时间超过了锁的过期时间锁自动释放了别的线程进来抢到锁两个线程同时操作库存照样超卖。所以项目就引入了Redisson。Redisson的锁是基于看门狗机制实现的默认锁的租约是30秒如果持有锁的线程还没执行完看门狗会自动续期每隔10秒续一次彻底解决了“锁过期但业务没跑完”的尴尬。另外Redisson锁还支持可重入同一个线程可以多次加锁而不死锁这比手写SetNX靠谱得多。我试过在压测时对比手写锁和Redisson锁库存1000张券10000个请求打进来手写锁在某些极端延迟场景下出现了库存负数Redisson全程零超卖。这个项目的意义就在这里——它让你踩一遍手写锁的坑再给你看正规军的解法这种对比式学习比直接讲API有效得多。3.2 Lua脚本封装原子操作分布式锁解决了并发问题但性能损耗也是一个隐患。每个秒杀请求都要经历一次锁的获取和释放即使Redisson优化得很不错锁竞争本身也是开销。黑马点评后面的版本用了更彻底的一招把库存扣减和订单判断直接封装进一段Lua脚本在Redis服务端一次性原子执行全程不需要分布式锁。Lua脚本的思路是这样的判断库存充足、扣减库存、创建订单三个步骤全部写进脚本里Redis是单线程执行脚本的天然保证了这些操作的原子性不会出现“判断完库存充足但扣减前另一线程先扣了”的竞态问题。不仅性能高而且代码逻辑更清晰——锁的问题直接绕开了。关键还是脚本怎么组织。黑马点评项目里秒杀的Lua脚本核心逻辑是接收用户ID和优惠券ID先用Redis的Hash结构检查用户是否已经买过一人一单判断再用String或Hash里的库存字段判断是否大于0都通过就扣减库存并标记该用户已购买。这里有个细节值得注意所有判断和操作都在一个脚本内完成任何一步失败都直接返回Redis脚本执行过程中不会被其他命令插入所以安全性是完全有保障的。用Lua脚本还有一个额外收益就是减少网络RTT。原来可能三到四次请求的操作合并成一次脚本执行在高并发秒杀场景里这一点性能提升可能就决定压测能不能过。3.3 防超卖的乐观锁CAS思路黑马点评里还讲了一个非常经典的数据库层面方案——乐观锁。在扣减库存的SQL里加一个version条件例如UPDATE tb_voucher_stock SET stock stock - 1, version version 1 WHERE voucher_id #{voucherId} AND stock 0 AND version #{version}这个写法的巧妙之处在于它把“判断库存是否够”和“扣减库存”合并到一个原子SQL里通过受影响行数来判断是否扣减成功。如果返回0说明库存不够或版本不对就重试或返回失败。乐观锁和分布式锁最大的区别是“不阻塞”分布式锁是悲观地认为一定有人竞争所以强制排队乐观锁是乐观地认为大多数请求不会冲突只在最后更新时校验。从教学角度看黑马点评的这个章节安排得很有层次先从数据库乐观锁兜底再演进到Redis锁提高并发再演化到Lua脚本消除锁竞争层层递进。面试被问到“秒杀你怎么做”的时候你能把这套演进路径讲清楚远比只背一个“用Redisson加锁”要高级得多。注意乐观锁的version不需要真的在业务里存一个字段直接用stock 0作为条件也是一个简化版本。但如果你要在简历里写更专业的做法是加上version字段能应对面试官后续问ABA问题的场景。4. Redis数据结构在业务中的实战映射4.1 Geo与附近门店商户查询模块里有一个非常贴合真实生活的功能——附近门店。用户打开App定位到当前经纬度系统返回半径5公里内的门店并按距离排序。如果这个功能用MySQL做不现实因为你得对几十万门店做两两距离计算。黑马点评这里用的是Redis的Geo结构。Redis的Geo底层其实就是ZSet只是每个成员的score被编码成了经纬度的GeoHash值因此你可以直接用geoRadius或新版GEORADIUS命令传入经纬度和半径Redis会返回半径内的所有成员还能带距离信息。写这个功能的时候有一个容易踩的坑经纬度坐标是字符串拼接进去的长期运行后会积累大量无效的历史坐标点而且门店数量不少不建议全量加载。更好的做法是Geo只存活跃门店或上线门店的ID并且在新增门店时同步写入Geo结构。另外业务上通常可以再加一道内存缓存把热门商圈的查询结果缓存在JVM里进一步降低对Redis的访问频率。4.2 ZSet与点赞排行榜点赞功能是黑马点评另一个有教学价值的点。需求很明确用户可以对笔记点赞同时查看某篇笔记点赞用户排行榜。如果用数据库做排行榜每次查询都要做一次大排序代价不小。而Redis的ZSet天生就是为排行榜设计的——每个成员自带一个分数用ZINCRBY做点赞、ZREVRANGE取TopN都是O(logN)级别的操作。黑马点评的点赞设计里有一个很贴心的细节同一用户不能重复点赞。方案是给每个笔记维护一个Set保存已经点赞过的用户ID。每次点赞前先用SISMEMBER判断是否已存在不存在才写入并同步对ZSet做ZINCRBY这样就同时实现了“防重复点赞”和“排行榜实时更新”。删除点赞则反向操作。实战中这个模块最容易被忽略的是ZSet成员过期问题。一篇笔记过了热度过期时间ZSet里的数据可能会一直堆积你可以通过设置ZSet的过期时间或定时清理过期笔记ID来解决。另外如果需要展示排行榜中的用户头像和昵称可能会引发缓存穿透问题所以这个场景可以顺势结合前文讲的缓存方案来做用户信息的缓存整个项目在这里就形成了一个技术闭环。4.3 Stream与异步秒杀队列秒杀模块除了并发控制还有一个性能瓶颈是“同步创建订单”。如果抢购请求量大到一定程度即使Lua脚本能扛住Redis侧的压力数据库侧的订单写入也可能扛不住。黑马点评的高阶版本引入了Redis Stream做异步队列Lua脚本只负责扣库存和发送一条“用户ID优惠券ID”的消息到Stream业务后端异步消费Stream消息再去做订单落库。Redis Stream是5.0版本引入的队列结构可以简单理解成加强版List支持消费者组、消息确认、消息持久化。用Stream做队列和直接用RabbitMQ这类MQ的区别在于不需要引入额外中间件项目部署更轻量RabbitMQ能保证的持久化和消费组语义Stream也能提供最基本的部分。这里必须提醒一下Redis Stream毕竟是内存为主的组件消息积压太多时会受内存限制并且极端场景下可能存在消息丢失线上数据一致性要求非常高的业务不要碰Stream做真正的交易消息。但黑马点评作为教学项目用Stream展示“如何用Redis做异步化”已经完全足够了。面试时你还可以提一句“我知道Stream和真正MQ的可靠性差别”这反而显得你思考过技术选型的边界。4.4 BitMap与签到统计签到这个功能在真实App里看着简单但背后的数据结构设计很值得聊。从需求上看用户每天签到一次需要看本月签到记录、统计连续签到天数。如果每个用户每天的签到状态都存一条数据库记录一个月就是30条一年就是365条对高日活产品来说数据量非常吓人。黑马点评选用Redis BitMap来压缩存储每个用户每个月对应一个位图位图的每一位代表一天“1”表示签到“0”表示未签到。一个用户一年的签到数据只需要365个bit也就是不到50字节。这里用到的命令是SETBIT和GETBIT统计连续签到天数则是从今天开始往前位数8个字节做位运算count。写这段代码时最需要注意的就是跨月和跨年的边界问题。我第一次实现的时候没考虑这个月1号往前回溯时可能踩到上个月的位图导致连续签到天数多算了一天。后来在业务代码里加了一道判断——如果今天是当月1号连续签到要重新从今天开始算并把上个月的尾部和这个月的开头衔接起来处理。BitMap扩展到别的场景也很香比如用户活跃统计、每日是否登录、功能开关这类布尔型状态集都能用BitMap一键压缩这也是黑马点评里Redis设计深度的体现。5. 关注与Feed流推送推拉模式的选择5.1 拉模式与推模式的取舍黑马点评的关注Feed流模块是我整个项目里越琢磨越有东西的一章。业务设定了用户关注多个博主博主发布新笔记后关注他的用户需要在自己的首页刷到这条笔记。这是一个典型的Feed流推送场景和微博、抖音的“关注页时间线”本质上是同一个问题。实现层面有两种主流模式拉模式和推模式。拉模式的思路是用户打开首页时把所有关注博主的最近笔记ID列表拉出来做一次聚合去重排序再向内容服务批量查出笔记详情。优点是实现简单、实时性天然好缺点是每次打开首页都要实时聚合计算粉丝量多时查询和排序成本会爆炸。推模式的思路是博主发布笔记时往他所有粉丝的“收件箱”里都插入一条笔记ID。用户打开首页只需按时间倒序读取自己的收件箱即可不需要实时聚合。读过很多大厂的技术文章可能对“粉丝发送时写扩散”有印象就是新闻订阅场景下最经典的推模式场景。黑马点评用的也是推模式用Redis里每个用户的一个List或ZSet作为发件箱博主发布时往粉丝的List里LEFT_PUSH一个笔记ID用户查看Feed时从List里取最近N条。5.2 收件箱时间线优化如果只是简单用List存ID当内容量很大时首页分页拉取旧数据会越拉越深性能会退化。黑马点评在这块的处理方案是用ZSet代替List分数的值用时间戳这样可以通过ZREVRANGE实现按时间倒序分页。实际面试时如果你能主动提出“用ZSet的score做时间戳既能保证排序又能做游标式分页”会让面试官明显感觉你所理解的不只是照抄代码。还有一个细节值得注意推模式下博主发布到粉丝收件箱的操作是写放大尤其是博主粉丝很多的时候。所以黑马点评的代码里也提到了一个权衡——对于粉丝量大的头部博主可以降级为“拉模式”或者采用“混合模式”比如大V走拉、普通用户走推。我见过不少团队在自研Feed流时踩过这个坑上线初期推模式跑得好好的突然一个百万粉丝博主发了一条动态瞬间把Redis写爆。你在面试时可以主动聊这个场景面试官会非常感兴趣。实操心得收件箱里的笔记ID写完一定要设置过期时间比如7天。因为用户的Feed流通常只关心最近的动态旧数据保留太久会白白占用内存。我线上就把Feed流ZSet的过期时间设为24小时用户基本感知不到区别但Redis内存降了30%。6. 高频面试问题的答案模板与避坑经验6.1 黑马点评相关的经典追问“黑马点评”在简历上是很常见的项目经历正因为常见面试官对它的追问往往也更狠。我问了一圈身边做技术面试的朋友总结了几个被问频率最高的点“缓存穿透、击穿、雪崩分别是什么你的项目里怎么解决”这个问题几乎必问。回答要有层次先解释清楚三个概念差异再结合商户查询场景说明选了哪种策略、为什么。提逻辑过期的时候主动说说它和其他方案互斥锁的取舍这是加分点。“Redis分布式锁怎么实现的为什么不用数据库乐观锁”一定要能从并发角度讲清楚异同。别只背“用Redisson”要能解释看门狗机制的原理以及为什么Redis锁要解决“锁过期但业务未完成”的问题。“秒杀超卖是怎么避免的”这是一个分水岭问题。停留在“加锁”层面的答案只能算及格讲到乐观锁CAS、Lua脚本原子操作、异步队列削峰三层方案才算真正理解了秒杀链路。“点赞功能保证同一用户只能点赞一次你是怎么实现的”这里考察数据中心结构组合的能力Set判重ZSet排行简单有效。“Feed流用了推模式如果博主有几十万粉丝你还用推吗”这个问题很毒表面上问方案实际考察你对瓶颈的感知。直接说“大V用拉、普通用户用推”再举一个实际的线上案例。把这些点都弄明白之后你再看黑马点评就不觉得它只是个“仿大众点评项目”了更像是一张浓缩了高并发场景的Redis实战地图。6.2 项目里容易踩的坑清单跟着黑马点评敲一遍代码有几个坑几乎所有人都会踩提前列出来能帮你省不少调试时间Redis连接不上很多教程的Redis配置还是老版本密码、IP、端口、序列化方式默认JDK序列化导致乱码这几件事在项目初始化时就一次处理好别等到代码跑起来才去排查。缓存预热没做商户数据没有提前写入缓存上线后第一批请求全部穿透到数据库数据库直接被打满。黑马点评里虽然提到过但很多人跳过了预热代码。直接写一个CommandLineRunner在应用启动时把热点商户和商品加载到Redis。秒杀场景没有压测就上线我自己初学时用Jmeter模拟1000个并发请求第一次就出现了库存为负。秒杀模块写完先跑一轮压测重点看库存是否正确扣减、是否有重复订单再谈其他优化。逻辑过期误用了物理过期逻辑过期是业务层判断的额外时间戳很多人直接设置了Redis的TTL那就成了普通缓存根本没有击穿防护效果。点赞模块没有处理取消点赞业务需求一旦加上“取消点赞”只做INCR是不够的要同时做Set的删除和ZSet的分数递减逻辑还和点赞互为镜像。6.3 简历写法与后续扩展思路如果你打算把黑马点评写进简历千万不要只写“基于Spring Boot Redis实现仿大众点评项目”这种平铺直叙的描述。从一个面试官的角度我会建议简历上突出三个点一是技术难点例如“通过Redis ZSet实现点赞排行榜基于Lua脚本保证秒杀扣库存原子性”二是业务场景例如“实现Feed流推送对比推拉模式后采用ZSet收件箱方案支持分页拉取”三是数据指标例如“通过缓存空值与逻辑过期方案将热点商户查询QPS提升300%数据库压力下降70%”。黑马点评做完之后如果你想更进一步我强烈建议做两个方向的小重构一是把缓存逻辑封装成一个starter级别的通用模块支持注解或API方式一键接入缓存和逻辑过期二是给秒杀订单模块引入真正的消息队列RocketMQ或Kafka和Redis Stream做一个对比实现记录两种模式下各自的延迟和吞吐量差距。我在实际带新人的过程中发现能把黑马点评学到这个程度的人基本都能在简历上和面试中体现出明显的“系统设计感”而不是只会背项目流程。对比那些只写了一行“实现了商户管理功能”的候选人项目深度的差距在面试前两分钟就能体现出来。