题目一:介绍一下Spring事务
题目二:MySQL索引、实际项目怎么去优化MySQL
题目三:里面涉及 Redis 和 DB，DB 的数据什么时候进 Redis？
题目四:Redis 和 DB 的锁单数据怎么同步？
题目五:如果 Redis 先扣了名额，DB 写失败怎么办？
题目一:介绍一下Spring事务
，我分四点清晰说：
- 实现原理 底层靠 AOP 动态代理，拦截带 @Transactional 的方法，自动帮我们开启、提交、回滚事务，不用手动写 JDBC 事务代码。
- 两种使用方式 一是编程式，用 TransactionTemplate 手动控制，很少用；二是声明式注解 @Transactional，项目主流写法。
- 注解核心配置 传播行为控制嵌套事务、隔离级别解决脏读幻读、rollbackFor 指定哪些异常回滚，还有超时、只读属性。
- 常见失效场景 方法不是 public、同类方法内部调用、异常被 try-catch 吃掉、数据库引擎不支持事务，都会让事务不生效。
题目二:MySQL索引、实际项目怎么去优化MySQL
我先讲 MySQL 索引基础，再讲项目实际优化手段：
一、索引基础
- InnoDB 主键索引是聚簇索引，数据和索引存一起；普通索引是二级索引，只存主键；
- 索引失效常见：like % xxx、字段隐式转换、or 无索引、not in/not null、联合索引不遵循最左前缀。
二、项目里 MySQL 优化实操
- 建表索引优化 高频查询字段建索引，联合索引遵循最左匹配；区分度低的字段不建索引；大文本不建索引。
- SQL 语句优化 用 explain 分析执行计划，避免回表、全表扫描；少用 select *，只查需要字段；分页深分页用主键过滤优化。
- 存储引擎与字段 统一用 InnoDB，支持事务行锁；字段选合适长度，用 tinyint/varchar 代替大类型，减少内存占用。
- 架构层面优化 读写分离，主库写、从库分担查询；大表分库分表，避免单表数据千万级以上拖慢查询；热点数据放 Redis 缓存，减少 DB 访问压力。
- 运维优化 调整缓冲池大小，定期清理慢 SQL 日志，定时优化表、避免碎片。
题目三:里面涉及 Redis 和 DB，DB 的数据什么时候进 Redis？
项目里 DB 数据载入 Redis 分三种常用时机：
- 项目启动预加载 系统初始化时，把优惠券、商品分类这类不常变动的基础数据一次性查库存入 Redis，后续查询直接走缓存，减少数据库压力。
- 查询时懒加载（最常用） 用户查询时先查 Redis，没命中缓存就去数据库查，查到后把数据写入 Redis 再返回；下次相同请求就能直接读缓存。
- 数据库更新同步写入 新增、修改、删除 DB 数据后，同步更新或删除对应 Redis 缓存，保证缓存和数据库数据一致。 额外还有定时全量刷新：针对会过期、量大的数据，定时任务定时查库覆盖缓存，防止缓存长期脏数据。
题目四:Redis 和 DB 的锁单数据怎么同步？
分两种主流同步方案，都是锁库存场景用的：
1. 先更新数据库，再删缓存（标准方案）
修改库存事务提交完成后，直接删除 Redis 里对应的缓存。 下次用户查询会触发懒加载，从 DB 拉取最新数据写入 Redis，能保证数据一致。 并发下可能短暂脏读，但不影响库存扣减核心逻辑。
2. 先更新缓存，再更新数据库（秒杀预扣专用）
秒杀 Lua 脚本先扣 Redis 库存，再发消息异步更新 DB 库存； 用消息队列削峰，DB 最终同步 Redis 的扣减数量，适合高并发抢购场景。
兜底补偿
定时任务定时对比 DB 真实库存和 Redis 缓存库存，发现不一致就刷新缓存，修复同步偏差。
题目五:如果 Redis 先扣了名额，DB 写失败怎么办？
Redis 预扣名额成功但数据库写入失败，核心要做库存补偿，分三层处理：
- 实时回滚补偿（优先） 捕获数据库操作异常，立刻执行 Lua 脚本，把 Redis 里预扣掉的名额加回去，及时恢复库存，避免少库存。
- 消息异步兜底 扣完 Redis 后发送事务消息 / 可靠消息，数据库下单失败就触发消息重试，重试多次仍失败则走死信队列，人工核查归还库存。
- 定时任务兜底（最终保障） 定时任务对比 Redis 预扣记录和数据库有效订单，只在 DB 生成成功订单才真正扣减库存；无对应订单的预扣记录，统一归还 Redis 名额，解决消息丢失、程序崩溃导致的库存不一致。
补充：数据库层增加乐观锁二次校验，就算 Redis 补偿遗漏，更新库存时where stock>0也能防止超卖。