问题一:Redis 和数据库不一致会造成什么影响？
问题二:这个场景一定要上 Redis 吗？数据库已经到瓶颈了吗？
问题三:锁单是什么逻辑？
问题四:是多人抢一个单，还是有限库存扣减到 0？
问题五:RabbitMQ 怎么实现延时消息？
问题一:Redis 和数据库不一致会造成什么影响？
造成影响
- 业务数据错乱：前端查 Redis 拿到旧数据，和真实数据库不一致，展示错误。比如商品库存缓存没更新，页面库存和真实库存对不上。
- 超卖 / 重复下单：库存缓存、数据库数值不一样，并发下单出现库存扣多、超卖。
- 订单、账单出错：缓存和库数据不同步，对账失败，财务核对出现差额。
- 脏数据长期残留：缓存一直没刷新，后续所有查询全是错误数据。
一句话速记
数据展示错误、库存超卖、账单对账失败，产生脏数据，业务逻辑出错。
如何解决Redis缓存与数据库数据不一致的问题？
如何保证Redis缓存与数据库数据的一致性？
除了Redis，还有哪些常用的缓存数据库？
问题二:这个场景一定要上 Redis 吗？数据库已经到瓶颈了吗？
不是所有场景必须用 Redis
- 低并发、访问量小：MySQL 完全扛得住，没必要额外引入 Redis，增加架构复杂度、多了缓存一致性维护成本。
- 数据极少重复查询：缓存收益很低，没必要搭建缓存。
2、需要引入 Redis 的判断（数据库遇到这些瓶颈再上）
- 大量高频读请求压垮 MySQL，数据库 CPU、IO 打满，查询缓慢；
- 热点数据重复访问多，适合缓存减轻库压力；
- 需要分布式锁、限流、计数器等 MySQL 不好实现的能力。
总结话术
数据库无高并发、无大量热点查询，不用 Redis；当数据库读请求压力大出现性能瓶颈，依靠 Redis 扛读流量。
问题三:锁单是什么逻辑？
整体流程
- 用户下单，先锁住对应商品库存，锁定一段时间（比如 15 分钟），此时库存被占用，其他人无法下单；
- 限时内完成支付，正式扣减真实库存，订单生效；
- 超时未付款，自动解锁库存，库存回流，商品可重新被抢购。
核心目的
防止用户占着库存不付钱，导致库存被空占、商品卖不出去；用延时消息自动回收超时锁。
一句话速背
下单临时锁定库存，限时付款；超时自动释放库存，避免库存冻结浪费。
问题四:是多人抢一个单，还是有限库存扣减到 0？
两种业务区分
- 多人抢一个单（秒杀孤品） 库存总量 = 1，所有人争抢唯一商品，成功一人，其余全部失败。适合限量单件抢购。
- 有限库存扣减到 0（常规秒杀） 初始有批量库存（如 100 件），并发下单不断扣减库存，库存扣为 0 后禁止下单。绝大多数商品秒杀采用该模式。
项目常规选型
业务大多是库存扣减至 0；孤品、限量单品才是多人抢一单。
一句话速记：单件抢购 = 抢 1 个；批量商品 = 库存扣到 0 为止。
问题五:RabbitMQ 怎么实现延时消息？
两种主流方案
方案 1：死信队列（最常用，推荐）
- 消息发到普通队列，设置过期时间 TTL；
- 消息超时没被消费，自动进入死信交换机、路由至死信队列；
- 业务监听死信队列，实现延时执行。 优点：原生支持，无需装插件，稳定。
方案 2：延时插件 rabbitmq-delayed-message-exchange
- 安装插件，创建延时交换机；
- 发消息时直接指定延迟时长，到点消息投递； 优点：灵活，可动态改延迟时间；缺点：需要额外装插件。
背诵一句话
生产常用死信 TTL 做延时；需要灵活改延迟就装延时交换机插件。