去 OPPO 面试，被问麻了

前言

最近有位读者去面试了 oppo，给大家整理了面试真题的答案。希望对大家有帮助哈，一起学习，一起进步。

1. 聊聊你印象最深刻的项目，或者做了什么优化。

2. 项目提到分布式锁，你们是怎么使用分布式锁的?

3. 常见的分布式事务解决方案

4. 你们的接口幂等是如何保证的？

5. 你们的 MySQL 架构是怎样的？

6. 常见的索引结构有？哈希表结构属于哪种场景？

7. 给你 ab,ac,abc 字段，你是如何加索引的？

8. 数据库隔离级别是否了解？你们的数据库默认隔离级别是？为什么选它？

9. RR 隔离级别实现原理，它是如何解决不可重复读的？

10. 你们项目使用了 RocketMQ 对吧？那你知道如何保证消息不丢失吗？

11. 事务消息是否了解？场景题：比如下单清空购物车，你是如何设计的？

12. 如何快速判断一个数是奇数还是偶数，除开对 2 取其余呢。

13. Spring 声明式事务原理？哪些场景事务会失效？

14. 你们是微服务架构吗？如果你来设计一个类似淘宝的系统，你怎么划分微服务？

15. 你们是怎么分库分表的？分布式 ID 如何生成？

16. 所有异常的共同祖先是？运行时异常有哪几个？

1. 聊聊你印象最深刻的项目，或者做了什么优化。

大家平时做的项目，如果很多知识点跟面试八股文相关的话，就可以相对条理清晰地写到简历去。

• 比如缓存数据库相关的，查询为空，你设置了一个-1 到缓存，代表数据库没记录。下次判断-1，就不查库了，以解决缓存穿透的问题。

• 又比如你设置缓存过期时间比较分散，解决缓存击穿问题，都可以条理清晰写到简历去，这样面试官很可能会问你相关的问题，这时候就对答如流啦。

还有平时你做的项目，有一些比较好的设计，都可以说一下哈，比如你是如何保证数据一致性的，怎么优化接口性能的。

2. 你项目提到分布式锁，你们是怎么使用分布式锁的?

一般你讲述你做的项目时，面试官会根据你项目涉及的一些面试点，然后抽他感兴趣的一两个来问。所以大家对哪些知识点熟悉，讲述项目时，就说你用该知识点，解决了什么问题。

3. 常见分布式事务解决方案

分布式事务：就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单来说，分布式事务指的就是分布式系统中的事务，它的存在就是为了保证不同数据库节点的数据一致性。

聊到分布式事务，大家记得这两个理论哈：CAP 理论 和 BASE 理论

分布式事务的几种解决方案：

• 2PC(二阶段提交)方案、3PC

• TCC（Try、Confirm、Cancel）

• 本地消息表

• 最大努力通知

• seata

2PC(二阶段提交)方案

2PC，即两阶段提交，它将分布式事务的提交拆分为 2 个阶段：prepare 和 commit/rollback，即准备阶段和提交执行阶段。在 prepare 准备阶段需要等待所有参与子事务的反馈，因此可能造成数据库资源锁定时间过长，不适合并发高以及子事务生命周长较长的业务场景。并且协调者宕机的话，所有的参与者都收不到提交或回滚指令。

3PC

两阶段提交分别是：CanCommit，PreCommit 和 doCommit，这里不再详述。3PC 利用超时机制解决了 2PC 同步阻塞问题，避免资源被永久锁定，进一步加强了整个事务过程的可靠性。但是 3PC 同样无法应对类似的宕机问题，只不过出现很多数据源中数据不一致问题的概率更小。

TCC

TCC 采用了补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：Try-Confirm-Cancel

• try 阶段：尝试去执行，完成所有业务的一致性检查，预留必须的业务资源。

• Confirm 阶段：该阶段对业务进行确认提交，不做任何检查，因为 try 阶段已经检查过了，默认 Confirm 阶段是不会出错的。

• Cancel 阶段：若业务执行失败，则进入该阶段，它会释放 try 阶段占用的所有业务资源，并回滚 Confirm 阶段执行的所有操作。

TCC 方案让应用可以自定义数据库操作的粒度，降低了锁冲突，可以提升性能。但是应用侵入性强，try、confirm、cancel 三个阶段都需要业务逻辑实现。

本地消息表

ebay 最初提出本地消息表这个方案，来解决分布式事务问题。业界目前使用这种方案是比较多的，它的核心思想就是将分布式事务拆分成本地事务进行处理。可以看一下基本的实现流程图：

 

最大努力通知

最大努力通知方案的目标，就是发起通知方通过一定的机制，最大努力将业务处理结果通知到接收方。

 

seata

Saga 模式是 Seata 提供的长期事务解决方案。核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

Saga 的并发度高，但是一致性弱，对于转账，可能发生用户已扣款，最后转账又失败的情况。

4. 你们的接口幂等是如何保证的？

如果你调用下游接口超时了，是不是考虑重试？如果重试，下游接口就需要支持幂等啦。

实现幂等一般有这 8 种方案：

• select+insert+主键/唯一的索引冲突

• 直接 insert + 主键/唯一索引冲突

• 状态机密等

• 抽取防重表

• token 令牌

• 悲观锁(如 select for update，很少用)

• 乐观说

• 分布式锁

大家平时是用哪个方案解决幂等的，最后结合工作实际讲讲哈。

5. 你们的 mySQL 架构是怎样的？

大家可以结合自己公司的 MySQL 架构聊聊。

数据的库高可用方案

• 双机主备

• 一主一从

• 一主多从

• MariaDB 同步多主机

• 数据库中间件

5.1 双机主备