liquor
搜索 K

Appearance

你提供的简历内容技术栈非常丰富，涵盖了高并发、微服务、分库分表、中间件优化等核心痛点，这是一个很好的底子。

但是，存在以下几个显著问题，建议修改：

  1. 内容重复严重：例如“基因法分库分表”、“Redis+Lua库存扣减”、“Kafka异步下单”在项目描述、负责内容（架构）、负责内容（业务）和亮点总结中反复出现。简历需要精炼，同一个亮点讲一次透彻的即可。
  2. 逻辑分类不清晰：“架构”和“业务”界限模糊。例如“防刷”和“库存扣减”虽然是业务需求，但其核心是技术实现。建议合并为**“核心职责与技术攻坚”**。
  3. 部分数据和描述过于绝对或啰嗦：例如“资源利用率从50%提升到100%”这种描述容易被挑战（数据很难完全均匀），建议改为“解决了数据倾斜问题，实现均匀分布”。
  4. 堆砌感强：罗列了大量设计模式（工厂、策略、模板、装饰者、组合...），如果面试时不能每个都结合业务讲得很深，容易给自己挖坑。 以下是我为你重构并润色后的版本，更符合高级Java/架构师岗位的专业度：

项目名称：高并发演出票务服务平台（Microservices Ticketing Platform） ​

项目描述： 该项目是一个面向千万级用户的B2C高并发演出购票平台，涵盖节目管理、座位选座、订单交易、支付结算等核心业务。系统基于Spring Cloud Alibaba微服务架构，采用容器化部署。针对热门演出“秒杀”场景下的高并发流量（QPS x万+）、超卖、数据一致性等挑战，设计了多级缓存、异步削峰、分库分表及高可用容错方案。

技术选型：

  • 核心架构： Spring Boot, Spring Cloud Alibaba (Nacos, Sentinel), K8s, Docker
  • 数据存储： MySQL (ShardingSphere), Redis (Redisson), Elasticsearch
  • 消息/流处理： Kafka, RocketMQ (或注明仅用Kafka)
  • 监控/工具： Prometheus + Grafana, Arthas, SkyWalking (或MDC+ELK)
  • 其他技术： Lua, Caffeine, ThreadPool, Design Patterns (Strategy/Template/Decorator)

核心职责与技术攻坚（STAR法则优化）：

1. 高并发交易链路优化（库存与锁）：

  • Redis+Lua原子库存扣减： 针对秒杀场景，废弃传统的数据库行锁方案，设计 Redis + Lua 脚本 实现库存预扣减。利用Redis单线程特性保证操作原子性，通过 Kafka 异步 同步数据至DB，将下单接口吞吐量（TPS）提升 26%，并彻底解决了超卖问题。
  • 多级缓存防击穿： 构建 Caffeine（本地）+ Redis（分布式）+ DB 的三级缓存架构。针对热点演出数据，结合布隆过滤器防止缓存穿透；设计“互斥锁（Double-Check）”机制处理缓存击穿，确保热点Key失效时仅有一个线程回源数据库。
  • 分布式锁设计： 基于 Redisson 进行二次封装，结合 策略模式 与 工厂模式 提供多种锁类型（公平/读写/联锁）。利用 AOP 切面实现 @Lock 注解，通过 @Order 精准控制锁与事务的提交顺序，解决了“锁释放后事务未提交”导致的数据不一致问题。

2. 海量数据存储与分库分表：

  • 基因法分库分表： 针对 user_id 和 order_id 多维度查询需求，设计 “基因法” 策略。将分库基因（用户ID后几位）融入订单ID生成算法中，使得订单表既能均匀散列，又能同时支持C端用户和订单维度的路由查询，避免了非分片键查询导致的读扩散问题。
  • 动态扩容方案： 设计“数据 → 虚拟分片 → 物理库”的映射路由表，实现了在不迁移存量数据的情况下的灵活扩容（Resharding）。
  • 分布式ID优化： 解决 K8s 容器漂移导致 Snowflake 算法机器ID重复的问题，利用 Redis 原子递增 动态分配 WorkerID，并实现自动回收机制，确保全局ID唯一性。

3. 系统稳定性与服务治理：

  • 全链路异步化与兜底： 引入 Kafka 对下单流程进行解耦削峰。为解决 MQ 丢消息或 Redis 宕机风险，设计了 “本地消息表（Local Transaction Table）” 与 操作流水记录，配合定时对账任务，保证核心数据的最终一致性。
  • 高性能延迟队列： 针对“订单15分钟未支付自动关闭”需求，基于 Redisson DelayedQueue 进行优化。引入 分片思想 将大队列拆分为多个子队列，配合多线程并行消费，大幅提升了海量延迟任务的吞吐能力。
  • 全链路日志追踪： 扩展线程池（TransmittableThreadLocal）与 Logback MDC 机制，实现了 TraceID 在异步线程、微服务调用间的全链路透传，极大提升了分布式环境下的故障排查效率。

4. 基础组件封装与设计模式应用：

  • 通用组件封装： 深度应用设计模式重构代码。利用 模板方法模式 统一应用启动时的初始化任务（缓存预热、配置加载）；利用 组合模式 编排复杂的下单校验逻辑（校验链），提升了代码的可维护性与扩展性。
  • 灰度发布路由： 基于 Spring Cloud LoadBalancer 自定义服务过滤器，通过解析请求头中的灰度标识，实现生产环境与灰度环境的流量精准隔离与平滑切换。

面试官视角的模拟追问（请务必准备好答案） ​

如果我看到修改后的简历，我会重点问以下问题，请你自测：

  1. 关于基因法：

    • “你提到把用户ID融入订单ID，那如果我的查询条件是‘商家ID’或者‘时间范围’怎么办？这种非分片键的查询怎么解决？”（答案方向：异构索引表、ES宽表）。
    • “订单号里融入了基因，那订单号会变得多长？是否影响索引效率？”

  2. 关于库存扣减：

    • “Redis扣减成功了，但是Kafka发消息失败了，或者消费者入库失败了，这时候Redis里的库存和DB里的库存就不一致了，这怎么处理？”（答案方向：本地消息表、RocketMQ事务消息、Redis回滚机制）。
    • “Lua脚本执行时间过长会阻塞Redis主线程，你们的脚本逻辑复杂吗？有没有做过压测？”

  3. 关于锁与事务：

    • “你提到用@Order控制锁和事务的顺序，具体是锁在事务外还是事务在锁外？为什么？”（答案：必须是 锁在事务外。加锁 -> 开启事务 -> 提交事务 -> 释放锁。如果锁在事务内，事务提交前锁释放，并发线程可能读到脏数据）。

  4. 关于设计模式：

    • “你说用了装饰者模式封装线程池，具体装饰了什么功能？”（答案：TtlRunnable，或者处理MDC上下文丢失的问题）。

修改建议总结： 新的简历将原本散落在各处的知识点串联成了解决方案。面试官更喜欢看**“遇到了什么问题 -> 用了什么技术 -> 解决了什么 -> 达到了什么效果”**的闭环，而不是单纯的技术名词堆砌。加油！

1. 分布式锁（Redisson） ​

使用场景 ​

在票务系统中，当多个用户同时购买同一场次的票时，需要保证库存扣减的原子性，防止超卖。

关键类与调用链 ​

  • [ProgramService.getById()](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\ProgramService.java#L567-L586) 方法使用 [@ServiceLock](file://D:\Java_projects\damai\damai-redisson-framework\damai-redisson-service-framework\damai-service-lock-framework\src\main\java\com\damai\servicelock\annotion\ServiceLock.java#L16-L59) 注解
  • [ProgramService.simpleGetByIdMultipleCache()](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\ProgramService.java#L539-L546) 方法涉及缓存更新
  • 调用链：业务方法 → ServiceLockTool → Redisson → Redis

业务上为什么需要它 ​

在高并发场景下，多个用户同时查询或更新同一个节目信息时，如果没有分布式锁保护，可能导致缓存击穿或数据不一致问题。特别是在缓存失效时，大量请求同时穿透到数据库，造成数据库压力过大。

技术要点与实践注意事项 ​

  1. 锁粒度控制：通过 keys = {"#programId"} 实现针对具体节目ID的细粒度锁定
  2. 锁类型选择：使用读锁([LockType.Read](file://D:\Java_projects\damai\damai-redisson-framework\damai-redisson-service-framework\damai-service-lock-framework\src\main\java\com\damai\servicelock\LockType.java#L19-L19))允许多个读操作并发执行，提高性能
  3. 避免死锁：在finally块中确保锁的释放
  4. 可迁移性经验：分布式锁适用于所有需要保证数据一致性的场景，如库存扣减、账户余额更新等

2. 多级缓存架构 ​

使用场景 ​

节目详情信息的查询，结合本地缓存(Caffeine)+分布式缓存(Redis)的多级缓存策略

关键类与调用链 ​

  • [ProgramService.simpleGetByIdMultipleCache()](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\ProgramService.java#L539-L546)
  • [LocalCacheProgram](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\cache\local\LocalCacheProgram.java#L21-L76) (本地缓存)
  • [RedisCache](file://D:\Java_projects\damai\damai-redis-tool-framework\damai-redis-framework\src\main\java\com\damai\redis\RedisCache.java#L21-L1301) (Redis缓存)
  • 调用链：Controller → Service → LocalCache → RedisCache → DB

业务上为什么需要它 ​

热点节目的详情信息访问频次极高，单层缓存无法满足性能要求。本地缓存提供最快的访问速度，Redis缓存作为二级缓存，数据库作为兜底数据源，形成高效的缓存体系。

技术要点与实践注意事项 ​

  1. 缓存穿透防护：空值也缓存，防止恶意请求穿透到DB
  2. 缓存雪崩预防：设置随机过期时间，避免大量缓存同时失效
  3. 缓存更新策略：采用先更新DB，再删除缓存的方式，避免双写不一致
  4. 可迁移性经验：多级缓存是高并发系统必备架构，特别适合读多写少的场景

3. Redis Lua脚本原子操作 ​

使用场景 ​

座位选择和订单创建过程中的库存扣减与状态更新

关键类与调用链 ​

  • [ProgramCacheCreateOrderResolutionOperate.programCacheOperate()](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\lua\ProgramCacheCreateOrderResolutionOperate.java#L39-L42)
  • [ProgramSeatCacheData](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\lua\ProgramSeatCacheData.java#L23-L61) 类加载Lua脚本
  • 调用链：订单创建 → 座位锁定 → Lua脚本执行 → Redis原子操作

业务上为什么需要它 ​

座位选择和库存扣减需要保证原子性，避免出现超卖现象。传统的先查后改操作在高并发下会出现竞态条件，导致库存数据不准确。

技术要点与实践注意事项 ​

  1. 原子性保障：Lua脚本在Redis中是原子执行的，避免了并发问题
  2. 减少网络开销：多个操作合并为一次网络请求
  3. 脚本预加载：通过@PostConstruct初始化脚本，避免重复加载
  4. 可迁移性经验：对于需要强一致性的业务操作，都应该考虑使用Lua脚本实现原子操作

4. 延迟队列（Delayed Queue） ​

使用场景 ​

订单自动取消功能，下单后未支付的订单在指定时间后自动取消

关键类与调用链 ​

  • [DelayOrderCancelSend.sendMessage()](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\delaysend\DelayOrderCancelSend.java#L48-L92) 发送延迟消息
  • [DelayOperateProgramDataConsumer.execute()](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\delayconsumer\DelayOperateProgramDataConsumer.java#L26-L35) 消费延迟消息
  • 调用链：订单创建 → 发送延迟消息 → 延迟到期 → 消费消息 → 取消订单

业务上为什么需要它 ​

电商系统中常见的订单超时自动取消功能，避免无效占用库存。传统定时任务轮询方式效率低下，延迟队列可以精确控制执行时间。

技术要点与实践注意事项 ​

  1. 时间精度控制：合理设置延迟时间，避免过早或过晚执行
  2. 幂等性处理：延迟消息可能存在重复消费，需要做好幂等性校验
  3. 异常处理：消费失败时要有重试机制和告警通知
  4. 可迁移性经验：延迟队列适用于所有需要延时处理的业务场景，如订单超时、活动开始提醒等

5. 组合模式（Composite Pattern）校验 ​

使用场景 ​

订单创建前的多重参数校验和业务规则校验

关键类与调用链 ​

  • [AbstractProgramCheckHandler](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\composite\AbstractProgramCheckHandler.java#L11-L17) 校验处理器基类
  • [ProgramUserExistCheckHandler](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\composite\impl\ProgramUserExistCheckHandler.java#L35-L131) 用户存在性校验
  • [ProgramDetailCheckHandler](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\composite\impl\ProgramDetailCheckHandler.java#L23-L60) 节目详情校验
  • 调用链：订单创建 → 组合校验器 → 多个校验处理器依次执行

业务上为什么需要它 ​

订单创建涉及多个维度的校验，**如用户合法性、节目有效性、座位可用性等。**组合模式可以灵活组装不同的校验规则，便于扩展和维护。

技术要点与实践注意事项 ​

  1. 校验顺序控制：通过[executeOrder()](file://D:\Java_projects\damai\damai-server\damai-pay-service\src\main\java\com\damai\pay\PayStrategyInitHandler.java#L19-L22)方法控制执行顺序，确保依赖关系正确
  2. 责任分离：每个校验器只负责单一校验逻辑，符合单一职责原则
  3. 易于扩展：新增校验规则只需添加新的校验器实现类
  4. 可迁移性经验：组合模式非常适合处理复杂的业务校验逻辑，可广泛应用于各种需要多步骤校验的场景

6. 熔断限流机制 ​

使用场景 ​

高并发场景下的接口保护，防止系统被突发流量冲垮

关键类与调用链 ​

  • [@RepeatExecuteLimit](file://D:\Java_projects\damai\damai-redisson-framework\damai-redisson-service-framework\damai-repeat-execute-limit-framework\src\main\java\com\damai\repeatexecutelimit\annotion\RepeatExecuteLimit.java#L13-L38) 注解实现重复执行限制
  • [ProgramOrderV3Strategy](file://D:\Java_projects\damai\damai-server\damai-program-service\src\main\java\com\damai\service\strategy\impl\ProgramOrderV3Strategy.java#L25-L57) 等订单策略类使用限流注解
  • 调用链：接口调用 → 限流检查 → 正常处理/拒绝请求

业务上为什么需要它 ​

票务系统在热门演出开票时面临巨大流量冲击，必须通过限流保护系统稳定性，防止因瞬时高并发导致系统崩溃。

技术要点与实践注意事项 ​

  1. 限流算法选择：令牌桶或漏桶算法平衡突发流量和平均速率
  2. 分布式限流：单机限流无法应对集群部署场景，需使用Redis等实现分布式限流
  3. 降级策略：限流触发时应提供友好提示而非直接失败
  4. 可迁移性经验：限流熔断是微服务架构的基本保障，任何对外暴露的接口都应考虑限流保护

这些技术点在项目中相互配合，形成了一个高可用、高性能的票务系统架构，具有很强的学习和借鉴价值。