去 OPPO 面试, 被问麻了。。。

最近有粉丝私信说被oppo的后端面试问麻了,所以今天给大家推荐一篇整理了16道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，就不查库了，以解决缓存穿透问题。

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

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

• 如果是讲优化接口这一块的话，其实就是缓存、分批、并发调用、异步等那几个关键知识点。

• 如果是代码优化细节，你可以挑个简单的来讲，比如复杂的if逻辑条件，可以调整顺序，让程序更高效，这样会让面试官眼前一亮哦。

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 双机主备