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，就不查库了，以解决缓存穿透问题。

 

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

 

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

 

 •  如果是讲优化接口这一块的话，你可以看下我这篇文章哈：记一次接口性能优化实践总结：优化接口性能的八个建议，结合来一起讲。其实就是缓存、分批、并发调用、异步等那几个关键知识点。

 

 •  如果是代码优化细节，可以结合我这篇:工作四年，分享50个让你代码更好的小建议。你可以挑个简单的来讲，比如复杂的if逻辑条件，可以调整顺序，让程序更高效，这样会让面试官眼前一亮哦。

如果是慢SQL优化这一块，可以看下我之前MySQL专栏系列文章，理解透之后，还是挺稳的：

 

 •  看一遍就理解：order by详解
 •  看一遍就理解：group by详解
 •  实战！聊聊如何解决MySQL深分页问题
 •  后端程序员必备：书写高质量SQL的30条建议
 •  阿里一面，给了几条SQL，问需要执行几次树搜索操作？
 •  生产问题分析！delete in子查询不走索引？！
 •  面试官问如何优化慢SQL？

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

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

 

比如，你看了田螺哥的 《七种方案！探讨Redis分布式锁的正确使用姿势》，很熟悉，就可以说用分布式锁解决了超卖问题什么的。
如果你看了田螺哥的《美团二面：Redis与MySQL双写一致性如何保证？》，你就可以说你是用什么方案保证缓存和数据库一致性的。

 

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的并发度高，但是一致性弱，对于转账，可能发生用户已扣款，最后转账又失败的情况。

 

整理了这几篇分布式事务文章，大家可以看看哈：

 

 •  看一遍就理解：分布式事务详解
 •  1.4 w字，25 张图让你彻底掌握分布式事务原理
 •  后端程序员必备：分布式事务基础篇