美团后端开发岗面经（01）

《面试题目》

1. 为什么采用 Caffeine 加 Redis 的多级缓存方案？
2. Redis 已经支持高并发，为什么还需要本地缓存？
3. 查询请求通过消息队列异步化后，结果如何返回给请求方？
4. Redis 集群中主节点写压力很大时如何处理？
5. 秒杀优惠券从用户请求到扣减库存会访问哪些数据？
6. 集群中某台机器的 Caffeine 本地缓存如何同步更新？
7. 如何设计订单超时自动取消，并处理并发问题？
8. RabbitMQ 如何保证可靠性，和 Kafka 有什么区别？
9. 消费者手动 ACK 和自动 ACK 分别适用于什么场景？
10. 如何设计一个短链服务？
11. MySQL 热点数据更新会带来哪些问题？
12. 如何选择分库分表的分片键并避免读扩散？

《参考解析》

1. Caffeine 命中延迟低，可降低 Redis 网络压力；Redis 负责跨实例共享和较长 TTL。两级缓存必须定义失效通知、版本或短暂不一致窗口，否则本地缓存会长期返回旧值。
2. 本地缓存省掉网络往返，适合读多写少的热点数据，但容量和一致性受单实例限制。使用前要评估命中率、更新频率和进程重启后的预热成本。
3. 请求可先返回任务 ID，客户端通过轮询、SSE 或 WebSocket 获取结果；也可让消费者把结果写入可查询存储。队列只负责解耦和削峰，不天然提供同步返回语义。
4. 可拆分写热点、按业务分片、批量合并更新或采用 Redis Cluster 的更多 hash slot。读写分离只能缓解读压力，不能解决单主节点的写瓶颈。
5. 先校验用户资格和幂等记录，再在 Redis 中原子扣减库存，随后异步落订单和数据库。每一步都要有唯一请求号，防止重试导致重复领取。
6. 通过 Redis Pub/Sub、Stream 或消息队列广播失效事件，各实例收到后删除或刷新本地项。事件丢失时要有 TTL、版本校验或定期对账作为补偿。
7. 数据库可记录到期时间，由定时扫描任务批量取消，并用条件更新确保只有一个执行者改变订单状态。取消和支付并发时必须以状态机和事务边界裁决先后。
8. RabbitMQ 通过持久化、生产确认、手动 ACK 和死信等机制提供较完整的投递控制；Kafka 以分区日志和顺序吞吐见长。两者都不能替业务保证绝对只消费一次。
9. 自动 ACK 在消息投递后立即确认，适合处理失败代价低的场景；手动 ACK 要等业务成功再确认，适合订单等重要操作，并配合重试、死信和幂等。
10. 短链需要生成唯一短码、持久化映射、缓存热点和统计跳转。短码冲突要重试，删除和过期策略不能影响仍有效的链接。
11. 热点更新会造成行锁竞争、缓存抖动和主从延迟。可拆分聚合计数、串行化热点写入、批量落库，并让读路径承受短暂最终一致。
12. 分片键应高基数、查询常带且分布均匀；跨分片查询可通过冗余索引、汇总表或搜索系统承接。只按数据量选键，容易造成热点和读扩散。