跳到主要内容

黑马点评升级版：简历模板参考

plus 版本专属

此章节是黑马点评 Plus 版本中专有的内容，而在整套文档中将普通版本和 Plus 版本都融合在了一起，让大家更方便的学习。

从本章节开始，是对于项目的重点和难点总结，起到帮助大家能更好的提升技术和通过面试的作用，所以需要先学习黑马点评 Plus 版本的内容后，再来看此章节。

本文是在小伙伴学习完黑马点评升级版（Plus）项目后，教大家如何在简历中写好此项目，让面试官一眼看到你的价值点

关于项目和简历的思考​

简历的内容​

  • 首先简历上的内容并不是越多越多，内容在于质量而不在于数量，写上去的内容自己一定要从里到外，从底层原理到细节设计再到问题的解决都要弄懂，尤其是大厂，对这些要求苛刻。所以建议小伙伴一定要把 Plus 版本的内容弄懂，来应对面试官的各种轰炸。

  • 把简历上的每一处内容，都要准备成属于自己的一套话术流程。当面试官问到其中一个内容时，自己能非常的有线性和流畅地把这部分回答清楚，做到指哪打哪，哪怕面试官追问你细节，也能回答上来。

  • 通过辅导别人的经验来看，大厂很看重你这个人在介绍自己的项目时，是不是逻辑清晰，有条理，问你场景问题时是不是有自己思考的过程，这样能做到的话，让人感觉你是能够胜任的。

一、技术选型​

SpringBoot 3、MyBatis-Plus、Redis、Redisson、Kafka、MySQL、Lua、布隆过滤器、L1+L2 双层缓存、令牌权限申请、滑动窗口限流、令牌桶限流、分库分表与全局 ID、延迟队列（Redisson）、链路埋点与压测画像

二、项目描述​

这是一个面向“本地生活与商户运营”的综合实战项目，围绕“高并发优惠券秒杀”和“热点查询”提供端到端稳定性与一致性方案。升级版（Plus）在普通版基础上补齐高并发稳定性、入口前置流控、令牌授权、缓存治理组合解法、消息可靠性、对账与补偿闭环、可观测与压测分析等工程能力，并新增“订阅通知”“到券提醒”“Top 买家统计”“抢购取消回流”等运营玩法，显著提升用户体验与系统韧性。

三、负责内容​

3.1 架构方面​

1. 设计全链路流控：令牌签发 + 令牌桶 + 滑动窗口​

基于 Redis 构建“令牌签发（凭证到通行证）→ 令牌桶限流 → 滑动窗口兜底”的入口防护链路，将资格控制与速率控制前置到网关/接口层；支持动态阈值、分用户组配额与 VIP 优先级放行，显著降低秒杀接口瞬时洪峰压力。

2. 构建秒杀一致性闭环（扣减到落库全链路）​

设计“权限校验 → Redis 原子扣减 → Kafka 投递 → 异步消费创建订单 → 分库分表落库 → 定时对账补偿”的状态流转；通过扣减记录、订单对账日志保障 Redis 与 MySQL 最终一致，覆盖扣减成功但订单失败、消息延迟、消费超时等场景。

3. 抽象 MQ 可靠性组件​

在 Kafka 侧实现发布确认、失败重试（指数退避）、死信队列（DLQ）、消费异常分层处理；消费端按业务唯一键做幂等去重，统一处理“发送失败、消费前超时、消费中异常、消费后失败”等场景，形成可复用的可靠消息能力。

4. 设计缓存治理体系（防穿透 + 防击穿 + 多级一致性）​

实现 L1 本地缓存 + L2 Redis 双层缓存；引入布隆过滤器与空值缓存拦截非法请求；通过双重检测锁（DCL）+ 逻辑过期 + 异步重建治理热点击穿；建立多级缓存一致性策略与热点预热机制，降低 DB 回源与缓存抖动风险。

5. Redis 组件封装与规范化治理​

统一 Key 设计、TTL 策略、序列化协议与公共读写模板，沉淀可复用 Redis 组件；对热点 Key、空值占比、重建次数等关键指标做可观测埋点，提升缓存体系可维护性与可排障性。

6. 分布式锁与幂等组件建设​

基于 Redisson 落地读锁、写锁、公平锁、非公平锁等模型，支持注解式与命令式接入；结合接口幂等标识与业务去重键，避免重复提交、重复消费、并发覆盖，保障关键写链路数据一致性。

7. 分布式延迟队列与补偿任务协同​

基于 Redisson 延迟队列实现“开抢前预通知、订单超时关闭、异常延迟重试”等场景；配合补偿扫描任务形成自动化纠偏机制，减少人工介入成本。

8. 分库分表与全局 ID 路由设计​

围绕用户、优惠券、订单与对账日志等核心表完成分片设计；按用户 ID/订单号路由写入，结合雪花算法等全局 ID 方案保证跨分片唯一性；在分片内执行对账比对与差异补偿，提升大数据量场景吞吐与可扩展性。

9. 可观测与压测画像体系​

建设链路埋点、异常聚合、告警上报能力，沉淀秒杀核心指标（QPS、P95/P99、锁等待、消息积压、补偿成功率）；通过版本化压测对比持续定位并优化瓶颈。

10. 多场景故障容灾与自愈机制​

针对 Redis 扣减后宕机、Lua 执行过程中宕机、主从切换数据丢失、MQ 宕机后消息丢失、消费延迟导致数据不一致等真实故障场景，逐一设计对应的容灾策略：可重入 Lua 脚本保障扣减操作幂等；扣减记录与数据库订单做比对匹配，发现差异自动进入补偿队列；Kafka 发送失败时配合事务回滚与本地消息表兜底；消费延迟时通过对账扫描任务检测半事务状态并执行回滚或重试，确保中间件故障恢复后系统能自动修复不一致状态，减少人工介入。

11. 分布式 ID 生成器定制与优化​

基于雪花算法定制全局 ID 生成器，优化区域 ID 分配策略，避免多机房/多实例场景下 ID 碰撞；针对 K8s 容器环境下 Pod 重启导致的 Worker ID 重复问题，引入动态注册与回收机制；增加时钟回拨检测与容忍策略，避免因服务器时间漂移产生重复 ID，保障分库分表场景下跨分片 ID 的全局唯一性与有序性。

12. 布隆过滤器工程化封装与自动配置​

对布隆过滤器进行高级 API 封装，实现自动配置化、高级注册 Bean 与工厂化创建，业务方只需声明即可接入；支持按业务分区管理（商户/优惠券/用户等不同集合）、基于数据库合法 ID 批量初始化与增量写入，保证线上布隆与真实集合一致性收敛；与空值缓存协同形成防穿透双保险，暴露阻断率、误判样本率与重建开销等可观测指标。

3.2 业务方面​

1. 抢购流程与页面交互优化​

  • 抢购前增加资格校验与限流提示，明确“可抢/不可抢”状态，减少无效请求。

  • 抢购中增加过程反馈与结果兜底，区分排队中、成功、失败等状态，提高用户感知。

  • 抢购成功后支持取消订单，触发库存回流与链路补偿，提升业务灵活性。

2. 无库存订阅与到券通知​

优惠券售罄时支持用户一键订阅；库存补充或取消回流后，按订阅时间与优先级公平分配通知名额，完成“订阅 → 入队 → 触达 → 领取”的闭环。

3. 开抢前预通知与通知领取策略​

基于延迟队列在活动开始前 2 分钟触发预通知，从用户等级集合与活跃用户集合筛选目标人群；通过去重控频避免重复骚扰，提高通知有效触达率与领取转化。

4. 店铺每日 Top 买家运营能力​

按店铺维度基于 SortedSet 统计用户贡献值（消费金额/订单数），支持每日 TopN 榜单、榜单快照和营销触达，为活动运营与复购增长提供数据支撑。

5. 券务运维与数据一致性保障​

围绕订单取消、库存修改、并发写冲突等高风险场景建立标准处理流程；通过 Redis 与数据库差异对比、自动补偿执行与异常回滚，保证核心券务数据可信。

6. 面向业务增长的稳定性建设​

在”秒杀抢购、订阅通知、库存回流、用户触达”全流程引入异常监控与补偿机制，保障活动高峰期可用性，兼顾系统稳定与用户体验。

7. 订单超时自动关闭与库存释放​

基于 Redisson 分布式延迟队列实现订单超时未支付自动关闭，触发 Redis 库存原子回补与数据库订单状态同步更新；释放的库存自动进入订阅通知链路，按订阅时间优先触达已订阅用户，形成”超时关闭 → 库存回流 → 订阅触达 → 再次领取”的完整业务闭环，避免恶意占库存导致真实用户无法购买。

8. 库存修改的双轨一致性保障​

运营侧修改优惠券库存时，同步更新 Redis 缓存与数据库记录，通过版本号校验与分布式写锁控制防止并发修改冲突；修改结果写入对账日志，配合定时校验任务发现 Redis 与数据库差异并自动补偿，避免出现超卖或少卖，保障券务核心数据可信。

9. 订阅用户公平性分配与控频降噪​

库存补充或取消回流触发通知时，基于 ZSet 按订阅时间最早或用户优先级最高的策略公平分配通知名额；通过去重控频机制避免同一用户在短时间内被重复通知骚扰；结合用户等级集合与活跃用户集合筛选目标人群，提高通知有效触达率与领取转化率，在提升用户体验的同时降低系统负载。

四、项目亮点总结​

4.1 技术架构亮点​

  1. 令牌前置授权 + 令牌桶限流 + 滑动窗口兜底的入口流控

  2. Redis 扣减的一致性闭环与补偿队列

  3. Kafka 生产确认、重试退避、DLQ、延迟队列、消费幂等

  4. L1+L2 双层缓存 + 空值缓存 + 布隆过滤器 + 逻辑过期

  5. Redisson 分布式锁与注解式幂等

  6. 分库分表路由与全局 ID，分片内对账与差异补偿

  7. 链路埋点、异常聚合、压测对比的可观测能力

  8. Redis/MQ 多故障场景容灾与自愈，覆盖宕机、数据丢失、主从切换

  9. 定制雪花算法解决 K8s 环境 ID 重复与时钟回拨

  10. 布隆过滤器工程化封装，自动配置化与工厂化创建

4.2 业务价值亮点​

  1. 秒杀链路在突发流量下稳定可控

  2. 端到端一致性与故障闭环，数据可信

  3. 订阅通知与预通知提升活动参与度

  4. Top 买家统计支撑精准运营与触达

  5. 用户体验优化（可取消、过程提示、到券提醒）

  6. 订单超时自动关闭与库存释放，防止恶意占库存

  7. 库存修改双轨一致性，Redis 与数据库自动对账补偿

  8. 订阅用户公平性分配与控频降噪，提升通知转化率

五、面试话术建议​

5.1 当面试官问“你的核心贡献”时​

回答示例：
“我负责设计入口流控与扣减一致性闭环，并在 Kafka 上实现可靠消息能力。通过令牌前置授权 + 令牌桶限流，将资格与速率控制前置到入口；扣减链路采用 对账日志 + 补偿队列构建故障闭环；消费端以业务键做幂等与去重。最终在高并发抢购场景下显著提升稳定性与数据一致性。”

5.2 当面试官问“如何应对缓存穿透/击穿”时​

回答示例：
“我们采用组合解法：空值缓存与布隆过滤器防穿透；双层缓存降低跨网络成本；热点采用双重锁检测与逻辑过期 + 异步重建，保证只有一个线程重建，其余快速返回旧值并异步刷新，削峰填谷。”

5.3 当面试官问“如何保证扣减链路的一致性”时​

回答示例：
“扣减成功到订单落库采用对账模式，确保‘写库成功即可投递’的最终一致性；引入订单对账日志，定时对账发现差异进入补偿队列；消费端幂等与去重避免状态污染。”

5.4 当面试官问“MQ 可靠性与延迟队列如何设计”时​

回答示例：
“生产端做发布确认与指数退避重试，失败入 DLQ；消费端以业务唯一键做幂等与去重；延迟队列用于预通知与订单超时关闭等场景，结合停车场模式做人工回溯与异常处置。”

5.5 当面试官问”分库分表与路由如何落地”时​

回答示例： “按用户或店铺维度分片；订单按订单号或用户 ID 路由；使用全局 ID 保证跨分片唯一性；在分片内做对账与差异补偿，保障在大数量场景下的写入与查询性能。”

5.6 当面试官问”Redis 或 MQ 宕机了怎么办”时​

回答示例： “我们针对不同故障场景设计了专项容灾方案。Redis 扣减成功后宕机，通过扣减记录，服务恢复后自动补发消息并对账；Lua 执行中宕机，脚本设计为幂等可重入，补偿任务扫描半事务状态做回滚或重试；主从切换数据丢失，关键扣减记录同步落地到对账日志表，周期性校验修复。MQ 宕机时，本地消息表兜底保证消息不丢；消费延迟时，对账扫描任务检测不一致并触发补偿。整体思路是'记录 + 对账 + 补偿'的三段式闭环。”

5.7 当面试官问”全局 ID 如何保证不重复”时​

回答示例： “我们基于雪花算法做了定制优化：首先优化区域 ID 分配，避免多机房碰撞；针对 K8s 环境 Pod 重启导致 Worker ID 重复的问题，引入动态注册与回收机制；同时增加时钟回拨检测，在检测到回拨时进入等待或切换备用序列，避免产生重复 ID。”

六、项目价值总结​

  1. 工程化能力全面：流控、缓存治理、消息可靠性、对账补偿、可观测

  2. 业务玩法丰富：订阅通知、到券提醒、Top 买家，驱动拉新与复购

  3. 稳定性与一致性：面对 Redis/MQ 故障与主从切换仍能闭环纠偏

  4. 成本与体验平衡：入口削峰、热点治理、异步重建保障用户体验

七、使用建议​

  1. 简历中的“项目描述”控制在 200 字左右，突出高并发与一致性

  2. “负责内容”选择 4–5 个你最熟悉的架构亮点展开

  3. 熟悉面试话术，准备好对缓存、流控、消息、一致性的深入追问

  4. 准备压测与故障案例的数据佐证，提高可信度与说服力

八、注意事项​

  1. 根据真实参与度调整措辞，切勿全量复制

  2. 不熟悉的技术点提前补课，能解释设计动机与权衡

  3. 强调“问题—方案—效果”的闭环，避免只罗列技术名词

🎁优惠