阿里淘天 Java 后端二面面经
1. 你们系统里如果用了消息队列，怎么保证消息不丢失、不重复消费，并且实现最终一致性？
答案：
- 先保证生产者发送可靠，发送失败要重试，关键业务可以配合事务消息或本地消息表。
- Broker 这一层要做持久化和副本，避免机器故障导致消息丢失。
- 消费者要在业务处理成功后再 ack，不能先确认再执行业务。
- MQ 一般只能保证至少一次投递，所以消费者一定要做幂等。
- 幂等常见做法是业务唯一 ID、去重表、Redis 去重、数据库唯一索引。
- 最终一致性一般靠异步重试、死信队列、补偿机制来保证。
- 面试里可以总结一句：生产者可靠发送，Broker 持久化，消费者幂等消费，失败靠补偿实现最终一致。
2. 分布式事务有哪些常见方案？项目里一般怎么选？
答案：
- 常见方案有 2PC、TCC、事务消息、本地消息表、Saga。
- 2PC 强一致性比较强，但性能差、阻塞明显，互联网场景一般不常用。
- TCC 适合一致性要求高的场景，比如支付、账户，但开发成本比较高。
- 事务消息和本地消息表更常见，适合大部分互联网业务，走最终一致性。
- Saga 适合流程长、步骤多、需要补偿的业务。
- 项目里怎么选，主要看业务要求。
- 如果是核心资金类业务，会偏向 TCC；如果是订单、积分、通知类，一般会选事务消息或本地消息表。
3. 数据库出现主从延迟时，会带来哪些问题？一般怎么处理？
答案：
- 最典型的问题就是写后读不一致。
- 比如刚下单，马上查订单列表可能查不到；刚更新资料，查出来还是旧数据。
- 处理方式第一种是关键查询直接走主库。
- 第二种是写操作后的一小段时间内强制读主库。
- 第三种是尽量走缓存，减少直接查从库。
- 对于非核心场景，可以接受短暂不一致。
- 如果主从延迟严重，还要排查慢 SQL、大事务、从库压力、复制线程、网络问题。
4. 讲一下 InnoDB 的 MVCC 原理，它解决了什么问题？
答案：
- MVCC 是多版本并发控制，主要是为了解决读写冲突，提高并发性能。
- 它的核心有三个：隐藏字段、undo log、ReadView。
- 数据更新时不会直接把旧数据覆盖掉，而是保留历史版本到 undo log。
- 查询时根据 ReadView 判断当前事务能看到哪个版本。
- 这样普通读大多数情况下不需要加锁。
- 它的主要作用就是提升并发，减少锁冲突。
- 在 RC 下每次查询都会生成新的 ReadView，在 RR 下一个事务里通常复用同一个 ReadView。
5. 为什么数据库索引底层通常使用 B+ 树，而不是红黑树或者哈希？
答案：
- 因为数据库是磁盘场景，最重要的是减少磁盘 IO。
- B+ 树是多叉树，树高低，查询时访问磁盘页的次数更少。
- 红黑树是二叉树，数据量大时树会更高，IO 次数更多。
- 哈希结构适合等值查询，但不适合范围查询和排序。
- B+ 树叶子节点有序，还能通过链表连接，范围查询效率很高。
- 所以数据库索引更适合用 B+ 树。
- 面试里可以总结成一句：B+ 树兼顾了等值查询、范围查询和磁盘 IO 效率。
6. Spring AOP 的底层原理是什么？JDK 动态代理和 CGLIB 有什么区别？
答案：
- Spring AOP 本质上就是动态代理。
- 它会在目标对象外面生成一个代理对象，在方法前后做增强。
- 常见场景有事务、日志、权限校验。
- JDK 动态代理是基于接口实现的，目标类必须实现接口。
- CGLIB 是基于继承实现的，不要求目标类有接口。
- 如果类没有实现接口，Spring 一般会用 CGLIB。
- 区别可以简单记成：JDK 代理靠接口，CGLIB 靠继承。
7. Spring Boot 自动配置的原理是什么？为什么很多配置不用手写？
答案：
- Spring Boot 的核心是自动配置。
- 启动类上的
@SpringBootApplication里包含了@EnableAutoConfigu。
剩余60%内容，订阅专栏后可继续查看/也可单篇购买
Java面试圣经 文章被收录于专栏
Java面试圣经，带你练透java圣经
