Java后端最长的河？——黑马点评项目超全复盘｜从业务开发、Redis实战、高并发优化到面试总结

前言

作为Java后端开发者，黑马点评几乎是所有人从“CRUD新手”迈向“高并发实战”的分水岭项目。

在学习黑马点评之前，我写代码停留在：

- 只会写普通CRUD接口
- 只会用MySQL做数据存储
- 不懂缓存、不懂并发、不懂分布式问题
- 遇到高并发、超卖、缓存失效、会话丢失完全无从下手

完成黑马点评项目之后，我真正打通了 SpringBoot + MyBatis-Plus + Redis + 消息队列 + 分布式锁 + 多级缓存 的完整技术闭环。

本项目基于大众点评真实业务模型，复刻了企业级本地生活平台核心业务：短信登录、商户缓存、高并发秒杀、用户关注、点赞排行、附近商户、签到统计、UV统计等模块。

本文将万字完整复盘黑马点评所有知识点、踩坑记录、底层原理、优化方案、面试考点与简历包装思路，适合所有Java后端初学者收藏复盘。

项目架构图

黑马点评项目采用经典的三层架构设计，清晰分离前端展示、业务逻辑与数据存储，确保系统的高可用、高并发与可扩展性。以下是整体架构图：

flowchart TD subgraph A[前端层] A1[用户浏览器/App] A2[页面请求] A3[交互与秒杀下单] end subgraph B[业务服务层] B1[拦截器] B2[登录校验] B3[业务逻辑处理] B4[分布式锁] B5[消息队列生产者] end subgraph C[数据存储层] C1[MySQL 持久化存储] C2[Redis 缓存/会话/队列] C3[RabbitMQ 异步解耦] end A --&gt;|HTTP/HTTPS请求| B B1 --&gt;|Token校验| B2 B2 --&gt;|用户信息| B3 B3 --&gt;|读请求优先| C2 B3 --&gt;|写请求| C1 B3 --&gt;|高并发写| B5 B5 --&gt;|异步消息| C3 C3 --&gt;|消费者处理| C1 C2 --&gt;|缓存未命中| C1 C1 --&gt;|数据回写| C2</code></pre> 架构说明： 前端层：负责用户界面展示、页面请求发起和秒杀下单等交互操作，通过HTTP/HTTPS协议与后端服务通信。 业务服务层：核心业务处理层，包含拦截器（统一鉴权）、登录校验（分布式会话）、业务逻辑处理（商户查询、秒杀等）、分布式锁（防超卖）和消息队列生产者（异步削峰）。 数据存储层：MySQL负责持久化存储核心业务数据；Redis作为高速缓存存储会话、热点数据、分布式锁和计数器；RabbitMQ用于异步解耦，将高并发写操作转化为队列任务，保护数据库。 该架构体现了“读多写少场景全部缓存化、高并发写场景全部异步化、分布式问题全部中间件化解决”的核心设计思想。

一、项目整体介绍

1.1 项目定位

黑马点评是前后端分离的本地生活服务后端项目，对标大众点评、美团商户点评系统。

核心业务场景：

- 用户短信登录、登录状态持久化
- 商户查询、商户缓存加速
- 优惠券秒杀高并发场景
- 用户关注、取关、共同关注
- 探店笔记发布、点赞、点赞排行榜
- 用户连续签到统计
- 基于地理位置的附近商户查询
- 页面UV独立访客统计

1.2 技术栈（纯正版无魔改）

后端核心技术

- SpringBoot 2.7
- MyBatis-Plus
- MySQL 8.0
- Redis 6.2
- Redisson（分布式锁）
- RabbitMQ（消息异步削峰）
- Lua脚本（Redis原子操作）
- Caffeine（本地二级缓存）
- JWT、ThreadLocal、拦截器

1.3 项目架构设计

整体架构分为三层：

1. 前端层：页面请求、交互、秒杀下单
2. 业务服务层：接口拦截、登录校验、业务逻辑处理
3. 数据存储层：MySQL持久化、Redis缓存、MQ异步解耦

核心设计思想：
读多写少场景全部缓存化、高并发写场景全部异步化、分布式问题全部中间件化解决。

二、模块一：分布式短信登录（从Session痛点到Redis会话）

2.1 原生Session存在的致命问题

初学Java Web时，我们依赖Tomcat Session存储用户登录信息。

但集群部署下存在致命缺陷：

- 多台Tomcat服务器 Session不共享
- 用户第一次访问服务器A登录，第二次负载均衡到服务器B → 登录状态丢失
- 无法水平扩展，完全不适合线上集群环境

2.2 黑马解决方案：Redis实现分布式Session

核心思路：

1. 用户登录成功后，生成随机Token作为令牌
2. 将用户信息序列化存入Redis，设置过期时间
3. Token返回前端，前端每次请求携带Token
4. 拦截器拦截所有请求，根据Token从Redis获取用户
5. 存入ThreadLocal，供全局业务使用

2.3 关键优化点

1. ThreadLocal存储用户信息
避免Controller、Service层层传参，实现全局用户透明获取。
2. 登录状态自动续期
每次访问接口，刷新Redis Key过期时间，实现“活跃用户永久在线”。
3. 短信验证码限流
利用Redis自增计数器，限制1分钟最多发送1次验证码，防刷接口。

2.4 面试高频问题

1. 为什么不用JWT纯令牌方案？

JWT无法主动失效，不适合单点登出、踢下线场景；Redis会话可随时删除，可控性更强。

2. ThreadLocal会内存泄漏吗？

项目拦截器请求结束必须remove用户信息，否则线程池复用会导致脏数据。

三、模块二：商户查询缓存（彻底吃透Redis缓存三大问题）

这是黑马点评最核心、最基础、面试问得最多的模块。

3.1 业务痛点

商户查询属于典型读多写少场景：

- 数据库查询压力大
- 重复查询相同商户SQL浪费资源
- 高并发场景数据库极易被打挂

因此必须引入Redis缓存优化查询。

3.2 基础缓存流程

1. 查询商户 → 先查Redis
2. 命中直接返回
3. 未命中查询MySQL
4. 查询完毕写入Redis，下次直接缓存命中

3.3 缓存更新策略（企业标准）

更新数据库 → 删除缓存
为什么不更新缓存？

- 频繁更新会导致大量无效缓存写入
- 删除缓存更轻量、更一致性

3.4 三大缓存问题完整解决方案（面试必背）

1）缓存穿透

问题：查询不存在数据，Redis、MySQL都查不到，请求直接打数据库。

解决方案：空值缓存
不存在的商户也缓存空数据，设置短期TTL，拦截大量恶意空查询。

2）缓存雪崩

问题：大量缓存Key同时过期，瞬间全部请求打数据库。

解决方案：TTL随机值
给缓存过期时间增加随机偏移量，避免批量Key同时失效。

3）缓存击穿（热点Key问题）

问题：超级热点商户缓存过期瞬间，海量并发直接打数据库。

黑马提供两套企业级方案：

方案1：互斥锁（保证一致性、牺牲性能）

缓存失效时，只放行一个线程查数据库，其他线程阻塞等待缓存重建完成。

方案2：逻辑过期（保证高性能、弱一致性）

热点数据提前设置逻辑过期字段，

- 未过期：直接返回旧缓存
- 已过期：异步线程重建缓存，用户依旧返回旧数据
零阻塞、超高并发

3.5 项目进阶亮点：Caffeine+Redis二级缓存

我在本项目完全落地企业二级缓存架构：

1. 一级缓存：Caffeine本地缓存（JVM内存）
- 无网络IO、速度极快
- 拦截80%热点请求
2. 二级缓存：Redis分布式缓存
- 保证集群数据共享

优势：

- 大幅减少Redis访问次数
- 降低网络开销
- 极大提升QPS

四、模块三：高并发优惠券秒杀（项目天花板、面试重中之重）

秒杀是后端最经典高并发场景，黑马点评秒杀模块涵盖几乎所有并发问题。

4.1 秒杀原生问题

1. 库存超卖：多线程同时扣减库存，库存负数
2. 一人多单：用户重复秒杀
3. 数据库压力巨大：大量请求直接落库
4. 同步下单阻塞严重：响应慢、超时多

4.2 阶段一：Redis预扣库存解决超卖

利用Redis原子操作判断库存、扣库存。

问题：多条Redis命令不保证原子性，依旧超卖。

4.3 阶段二：Lua脚本保证绝对原子性

将：判断库存 + 扣库存 + 判断用户是否已秒杀
三条逻辑写在同一个Lua脚本

Redis单线程执行Lua，彻底杜绝超卖。

4.4 阶段三：Redisson分布式锁实现一人一单

单机synchronized无法集群生效。

使用Redisson分布式锁：

- 锁定用户ID
- 保证同一个用户只能创建一单
- 解决集群环境重复秒杀问题

4.5 阶段四：RabbitMQ异步削峰（最终企业方案）

流程最终优化为：

1. 前端秒杀请求
2. Redis + Lua预扣库存、校验资格
3. 秒杀成功发送消息到MQ
4. 前端直接返回排队成功
5. 消费者异步创建订单、落库

优势

- 秒杀请求毫秒级响应
- 彻底削峰，不压垮数据库
- 支持超大流量秒杀场景

4.6 秒杀完整链路总结

限流 → 缓存预扣 → Lua原子校验 → 分布式锁防重 → MQ异步落库

这就是真实互联网秒杀架构雏形。

五、模块四：Redis高阶数据结构实战（面试加分大招）

黑马点评最大亮点：把Redis所有高频数据结构全部落地业务

5.1 String

- 分布式登录会话
- 验证码存储、限流计数

5.2 Hash

- 用户信息缓存、商户信息缓存

5.3 Set

- 用户关注列表
- 共同好友求取（Set交集）

5.4 ZSet（有序集合）

- 探店笔记点赞排行榜
- 按点赞数自动排序

5.5 BitMap

- 用户签到统计
极大节省内存：千万用户签到仅几MB内存

5.6 GeoHash

- 经纬度计算
- 附近商户距离排序、范围查找

5.7 HyperLogLog

- 页面UV独立访客统计
极小内存实现亿级UV统计

学完本项目，你再也不是只会set/get的Redis新手，而是懂场景、懂选型、懂优化的实战开发者。

六、模块五：社交业务（关注、点赞、排行、探店笔记）

6.1 用户关注与共同关注

核心：

- Set存关注用户
- Set交集求共同关注

6.2 点赞功能防重复

利用Redis Set唯一性：

- 存点赞用户ID
- 判断是否存在实现不可重复点赞

6.3 点赞排行榜

ZSet score=点赞数，自动排序，实时榜单。

6.4 探店笔记异步发布

采用MQ异步发布笔记，减少主线程压力，提升接口速度。

七、模块六：性能优化与架构思维升华

7.1 所有读请求优先缓存

MySQL只做兜底持久化。

7.2 所有高并发写请求异步化

避免同步阻塞、避免数据库压力堆积。

7.3 所有热点数据内存化

本地缓存 + 分布式缓存双层兜底。

7.4 所有并发问题原子化

Lua、分布式锁解决并发安全。

八、学习本项目前后能力对比

学习前

- 只会普通CRUD
- 不懂缓存原理
- 不懂并发安全
- 不懂分布式问题
- 面试只会背概念，无实战支撑

学习后

- 能独立设计缓存架构
- 能解决穿透、击穿、雪崩三大经典问题
- 能独立开发高并发秒杀系统
- 熟练掌握Redis七种数据结构真实业务场景
- 掌握分布式锁、会话共享、异步削峰
- 具备企业级后端业务设计思维

这就是校招面试官最想看的实战能力

九、项目踩坑记录（真实开发问题）

1. 缓存更新策略错误导致数据不一致
未采用删缓存，而是更新缓存，引发脏数据。
2. 秒杀不加锁导致超卖
普通Java锁无法集群生效。
3. 不用Lua脚本导致原子性失效
4. ThreadLocal不清除导致内存泄漏
5. 热点Key无逻辑过期导致数据库瞬间压力暴涨
6. TTL固定值引发缓存雪崩隐患

所有坑全部在项目中手动踩过、修复过、理解透彻。

十、简历标准包装文案

项目名称：黑马点评本地生活商户平台

技术栈：SpringBoot、MyBatis-Plus、MySQL、Redis、Redisson、RabbitMQ、Lua、Caffeine

项目描述
独立复刻仿大众点评本地生活后端项目，实现分布式短信登录、商户多级缓存、高并发优惠券秒杀、用户社交关注、点赞排行、附近商户、签到UV统计等核心业务。通过多级缓存、异步削峰、分布式锁、Lua原子脚本解决海量查询与秒杀并发问题，具备完整互联网高并发项目架构思维。

核心职责

1. 基于Redis+拦截器+ThreadLocal实现分布式会话登录，解决集群会话共享与登录状态刷新问题。
​
2. 搭建Caffeine本地缓存+Redis分布式缓存二级架构，完整解决缓存穿透、击穿、雪崩三大问题，大幅降低DB压力。
​
3. 基于Lua脚本+Redisson分布式锁实现高并发秒杀，防止库存超卖与用户重复下单，结合RabbitMQ异步下单削峰，提升系统吞吐量。
​
4. 熟练运用Redis Geo、BitMap、ZSet、HyperLogLog等数据结构实现附近商户、签到统计、点赞排行、UV统计等业务。

十一、面试高频10问（黑马点评必问）

1. 缓存穿透、击穿、雪崩分别是什么？怎么解决？
​
2. 为什么用Redis做分布式Session不用JWT？
​
3. 秒杀为什么要用Lua脚本？
​
4. 一人一单怎么实现？
​
5. 互斥锁和逻辑过期优缺点？
​
6. 二级缓存架构优势和数据不一致怎么解决？
​
7. RabbitMQ在秒杀中的作用？
​
8. 为什么删缓存不更新缓存？
​
9. GeoHash原理是什么？
​
10. BitMap、HyperLogLog适用场景？

十二、项目总结与个人感悟

黑马点评不是一个简单练手项目，
它是Java后端从零基础进阶工程化、高并发、分布式的必修项目。

完成本项目，我真正掌握了：

- 真实企业缓存架构设计
​
- 高并发秒杀完整解决方案
​
- Redis全场景业务落地
​
- 分布式锁、异步队列工程化使用
​
- 性能优化、并发安全、系统稳定性思维

很多人学SpringBoot只会CRUD，而我通过黑马点评真正学会了“后端架构”。

未来我将继续深入微服务、分布式事务、多级架构、限流熔断，持续夯实后端核心竞争力。



原创不易，欢迎点赞收藏，持续更新后端实战系列复盘！