1. 你们系统里如果用了消息队列，怎么保证消息不丢失、不重复消费，并且实现最终一致性？

答案：

1. 先保证生产者发送可靠，发送失败要重试，关键业务可以配合事务消息或本地消息表。
2. Broker 这一层要做持久化和副本，避免机器故障导致消息丢失。
3. 消费者要在业务处理成功后再 ack，不能先确认再执行业务。
4. MQ 一般只能保证至少一次投递，所以消费者一定要做幂等。
5. 幂等常见做法是业务唯一 ID、去重表、Redis 去重、数据库唯一索引。
6. 最终一致性一般靠异步重试、死信队列、补偿机制来保证。
7. 面试里可以总结一句：生产者可靠发送，Broker 持久化，消费者幂等消费，失败靠补偿实现最终一致。

2. 分布式事务有哪些常见方案？项目里一般怎么选？

答案：

1. 常见方案有 2PC、TCC、事务消息、本地消息表、Saga。
2. 2PC 强一致性比较强，但性能差、阻塞明显，互联网场景一般不常用。
3. TCC 适合一致性要求高的场景，比如支付、账户，但开发成本比较高。
4. 事务消息和本地消息表更常见，适合大部分互联网业务，走最终一致性。
5. Saga 适合流程长、步骤多、需要补偿的业务。
6. 项目里怎么选，主要看业务要求。
7. 如果是核心资金类业务，会偏向 TCC；如果是订单、积分、通知类，一般会选事务消息或本地消息表。

3. 数据库出现主从延迟时，会带来哪些问题？一般怎么处理？

答案：

1. 最典型的问题就是写后读不一致。
2. 比如刚下单，马上查订单列表可能查不到；刚更新资料，查出来还是旧数据。
3. 处理方式第一种是关键查询直接走主库。
4. 第二种是写操作后的一小段时间内强制读主库。
5. 第三种是尽量走缓存，减少直接查从库。
6. 对于非核心场景，可以接受短暂不一致。
7. 如果主从延迟严重，还要排查慢 SQL、大事务、从库压力、复制线程、网络问题。

4. 讲一下 InnoDB 的 MVCC 原理，它解决了什么问题？

答案：

1. MVCC 是多版本并发控制，主要是为了解决读写冲突，提高并发性能。
2. 它的核心有三个：隐藏字段、undo log、ReadView。
3. 数据更新时不会直接把旧数据覆盖掉，而是保留历史版本到 undo log。
4. 查询时根据 ReadView 判断当前事务能看到哪个版本。
5. 这样普通读大多数情况下不需要加锁。
6. 它的主要作用就是提升并发，减少锁冲突。
7. 在 RC 下每次查询都会生成新的 ReadView，在 RR 下一个事务里通常复用同一个 ReadView。

5. 为什么数据库索引底层通常使用 B+ 树，而不是红黑树或者哈希？

答案：

1. 因为数据库是磁盘场景，最重要的是减少磁盘 IO。
2. B+ 树是多叉树，树高低，查询时访问磁盘页的次数更少。
3. 红黑树是二叉树，数据量大时树会更高，IO 次数更多。
4. 哈希结构适合等值查询，但不适合范围查询和排序。
5. B+ 树叶子节点有序，还能通过链表连接，范围查询效率很高。
6. 所以数据库索引更适合用 B+ 树。
7. 面试里可以总结成一句：B+ 树兼顾了等值查询、范围查询和磁盘 IO 效率。

6. Spring AOP 的底层原理是什么？JDK 动态代理和 CGLIB 有什么区别？

答案：

1. Spring AOP 本质上就是动态代理。
2. 它会在目标对象外面生成一个代理对象，在方法前后做增强。
3. 常见场景有事务、日志、权限校验。
4. JDK 动态代理是基于接口实现的，目标类必须实现接口。
5. CGLIB 是基于继承实现的，不要求目标类有接口。
6. 如果类没有实现接口，Spring 一般会用 CGLIB。
7. 区别可以简单记成：JDK 代理靠接口，CGLIB 靠继承。

7. Spring Boot 自动配置的原理是什么？为什么很多配置不用手写？

答案：

1. Spring Boot 的核心是自动配置。
2. 启动类上的 @SpringBootApplication 里包含了 @EnableAutoConfigu。