oppo后端16连问

捡田螺的小男孩

发布于 2022-05-23 14:00:49

5580

发布于 2022-05-23 14:00:49

文章被收录于专栏：捡田螺的小男孩捡田螺的小男孩捡田螺的小男孩

前言

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

聊聊你印象最深刻的项目，或者做了什么优化。
你项目提到分布式锁，你们是怎么使用分布式锁的?
常见分布式事务解决方案
你们的接口幂等是如何保证的？
你们的MySQL架构是怎样的？
常见的索引结构有？哈希表结构属于哪种场景？
给你ab,ac,abc字段，你是如何加索引的？
数据库隔离级别是否了解？你们的数据库默认隔离级别是？为什么选它？
RR隔离级别实现原理，它是如何解决不可重复读的？
你们项目使用了RocketMQ对吧？那你知道如何保证消息不丢失吗？
事务消息是否了解？场景题：比如下单清空购物车，你是如何设计的？
如何快速判断一个数是奇数还是偶数，除开对2取余呢。
Spring声明式事务原理？哪些场景事务会失效？
你们是微服务架构嘛？如果你来设计一个类似淘宝的系统，你怎么划分微服务？
你们是怎么分库分表的？分布式ID如何生成？
所有异常的共同祖先是？运行时异常有哪几个？

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

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

比如缓存数据库相关的，查询为空，你设置了一个-1到缓存，代表数据库没记录。下次判断-1，就不查库了，以解决缓存穿透问题。
又比如你设置缓存过期时间比较分散，解决缓存击穿问题，都可以条理清晰写到简历去，这样面试官很可能会问你相关的问题，这时候就对答如流啦。

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

如果是讲优化接口这一块的话，你可以看下我这篇文章哈：记一次接口性能优化实践总结：优化接口性能的八个建议，结合来一起讲。其实就是缓存、分批、并发调用、异步等那几个关键知识点。
如果是代码优化细节，可以结合我这篇:工作四年，分享50个让你代码更好的小建议。你可以挑个简单的来讲，比如复杂的if逻辑条件，可以调整顺序，让程序更高效，这样会让面试官眼前一亮哦。

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

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

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

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

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

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

select+insert+主键/唯一索引冲突
直接insert + 主键/唯一索引冲突
状态机幂等
抽取防重表
token令牌
悲观锁(如select for update，很少用)
乐观锁
分布式锁

大家平时是用哪个方案解决幂等的，最后结合工作实际讲讲哈。可以看下我之前这篇文章: 聊聊幂等设计

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

大家可以结合自己公司的MySQL架构聊聊。如果不是很清楚的话，可以结合我之前写的来看看哈：面试必备：聊聊MySQL的主从

数据的库高可用方案

双机主备
一主一从
一主多从
MariaDB同步多主机
数据库中间件

5.1 双机主备

优点：一个机器故障了可以自动切换，操作比较简单。
缺点：只有一个库在工作，读写压力大，未能实现读写分离，并发也有一定限制

5.2 一主一从

优点：从库支持读，分担了主库的压力，提升了并发度。一个机器故障了可以自动切换，操作比较简单。
缺点：一台从库，并发支持还是不够，并且一共两台机器，还是存在同时故障的机率，不够高可用。

5.3 一主多从

优点：多个从库支持读，分担了主库的压力，明显提升了读的并发度。
缺点：只有一台主机写，因此写的并发度不高

5.4 MariaDB同步多主机集群

有代理层实现负载均衡，多个数据库可以同时进行读写操作；各个数据库之间可以通过Galera Replication方法进行数据同步，每个库理论上数据是完全一致的。
优点：读写的并发度都明显提升，可以任意节点读写，可以自动剔除故障节点，具有较高的可靠性。
缺点：数据量不支持特别大。要避免大事务卡死，如果集群节点一个变慢，其他节点也会跟着变慢。

5.5 数据库中间件

mycat分片存储，每个分片配置一主多从的集群。
优点：解决高并发高数据量的高可用方案
缺点：维护成本比较大。

大家有兴趣可以看看我这篇文章哈：面试必备：聊聊MySQL的主从

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

哈希表、有序数组和搜索树。

哈希表这种结构适用于只有等值查询的场景
有序数组适合范围查询，用二分法快速得到，时间复杂度为 O(log(N))。查询还好，如果是插入，就得挪动后面所有的记录，成本太高。因此它一般只适用静态存储引擎，比如保存2018年某个城市的所有人口信息。
B+树适合范围查询，我们一般建的索引结构都是B+树。

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

这主要考察联合索引的最左前缀原则知识点。

这个最左前缀可以是联合索引的最左N个字段。比如组合索引（a,b,c）可以相当于建了（a），（a,b）,(a,b,c)三个索引，大大提高了索引复用能力。
最左前缀也可以是字符串索引的最左M个字符。

因此给你ab,ac,abc字段，你可以直接加abc联合索引和ac联合索引即可。

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

四大数据库隔离级别，分别是读未提交，读已提交，可重复读，串行化（Serializable）。

读未提交：事务即使未提交，却可以被别的事务读取到的，这级别的事务隔离有脏读、重复读、幻读的问题。
读已提交：当前事务只能读取到其他事务提交的数据，这种事务的隔离级别解决了脏读问题，但还是会存在不可重复读、幻读问题；
可重复读：限制了读取数据的时候，不可以进行修改，所以解决了不可重复读的问题，但是读取范围数据的时候，是可以插入数据，所以还会存在幻读问题。
串行化：事务最高的隔离级别，在该级别下，所有事务都是进行串行化顺序执行的。可以避免脏读、不可重复读与幻读所有并发问题。但是这种事务隔离级别下，事务执行很耗性能。

MySQL选择Repeatable Read（可重复读）作为默认隔离级别，我们的数据库隔离级别选的是读已提交。

8.1 为什么MySQL的默认隔离离别是RR?

binlog的格式也有三种：statement，row，mixed。设置为statement格式，binlog记录的是SQL的原文。又因为MySQL在主从复制的过程是通过binlog进行数据同步，如果设置为读已提交（RC）隔离级别，当出现事务乱序的时候，就会导致备库在 SQL 回放之后，结果和主库内容不一致。

比如一个表t，表中有两条记录：


CREATE TABLE t (  
     a int(11) DEFAULT NULL,  
     b int(11) DEFAULT NULL,  
     PRIMARY KEY a (a),
     KEY b(b)
   ) ENGINE=InnoDB DEFAULT CHARSET=latin1;  
   insert into t1 values(10,666),(20,233);

两个事务并发写操作，如下：

在读已提交（RC）隔离级别下，两个事务执行完后，数据库的两条记录就变成了（30,666）、(20,666)。这两个事务执行完后，binlog也就有两条记录，因为事务binlog用的是statement格式，事务2先提交，因此update t set b=666 where b=233优先记录，而update t set a=30 where b=666记录在后面。

当bin log同步到从库后，执行update t set b=666 where b=233和update t set a=30 where b=666记录，数据库的记录就变成（30,666）、(30,666)，这时候主从数据不一致啦。

因此MySQL的默认隔离离别选择了RR而不是RC。RR隔离级别下，更新数据的时候不仅对更新的行加行级锁，还会加间隙锁（gap lock）。事务2要执行时，因为事务1增加了间隙锁，就会导致事务2执行被卡住，只有等事务1提交或者回滚后才能继续执行。

并且，MySQL还禁止在使用statement格式的binlog的情况下，使用READ COMMITTED作为事务隔离级别。

我们的数据库隔离级别最后选的是读已提交（RC）。

那为什么MySQL官方默认隔离级别是RR，而有些大厂选择了RC作为默认的隔离级别呢？

提升并发

RC 在加锁的过程中，不需要添加Gap Lock和 Next-Key Lock 的，只对要修改的记录添加行级锁就行了。因此RC的支持的并发度比RR高得多，

减少死锁

正是因为RR隔离级别增加了Gap Lock和 Next-Key Lock 锁，因此它相对于RC，更容易产生死锁。

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

9.1 什么是不可重复读

先回忆下什么是不可重复读。假设现在有两个事务A和B：

事务A先查询Jay的余额，查到结果是100
这时候事务B 对Jay的账户余额进行扣减，扣去10后，提交事务
事务A再去查询Jay的账户余额发现变成了90

事务A被事务B干扰到了！在事务A范围内，两个相同的查询，读取同一条记录，却返回了不同的数据，这就是不可重复读。

9.2 undo log版本链 + Read View可见性规则

RR隔离级别实现原理，就是MVCC多版本并发控制，而MVCC是是通过Read View+ Undo Log实现的，Undo Log 保存了历史快照，Read View可见性规则帮助判断当前版本的数据是否可见。

Undo Log版本链长这样：

Read view 的几个重要属性

m_ids:当前系统中那些活跃(未提交)的读写事务ID, 它数据结构为一个List。
min_limit_id:表示在生成Read View时，当前系统中活跃的读写事务中最小的事务id，即m_ids中的最小值。
max_limit_id:表示生成Read View时，系统中应该分配给下一个事务的id值。
creator_trx_id: 创建当前Read View的事务ID

Read view 可见性规则如下：

如果数据事务IDtrx_id < min_limit_id，表明生成该版本的事务在生成Read View前，已经提交(因为事务ID是递增的)，所以该版本可以被当前事务访问。
如果trx_id>= max_limit_id，表明生成该版本的事务在生成Read View后才生成，所以该版本不可以被当前事务访问。
如果min_limit_id =<trx_id< max_limit_id,需要分3种情况讨论

3.1 如果m_ids包含trx_id,则代表Read View生成时刻，这个事务还未提交，但是如果数据的trx_id等于creator_trx_id的话，表明数据是自己生成的，因此是可见的。
3.2 如果m_ids包含trx_id，并且trx_id不等于creator_trx_id，则Read View生成时，事务未提交，并且不是自己生产的，所以当前事务也是看不见的；
3.3 如果m_ids不包含trx_id，则说明你这个事务在Read View生成之前就已经提交了，修改的结果，当前事务是能看见的。

9.3 RR 如何解决不可重复读

查询一条记录，基于MVCC，是怎样的流程

获取事务自己的版本号，即事务ID
获取Read View
查询得到的数据，然后Read View中的事务版本号进行比较。
如果不符合Read View的可见性规则，即就需要Undo log中历史快照;
最后返回符合规则的数据

假设存在事务A和B，SQL执行流程如下

在可重复读（RR）隔离级别下，一个事务里只会获取一次Read View，都是副本共用的，从而保证每次查询的数据都是一样的。

假设当前有一张core_user表，插入一条初始化数据,如下：

基于MVCC，我们来看看执行流程

A开启事务，首先得到一个事务ID为100
B开启事务，得到事务ID为101
事务A生成一个Read View，read view对应的值如下

变量	值
m_ids	100，101
max_limit_id	102
min_limit_id	100
creator_trx_id	100

然后回到版本链：开始从版本链中挑选可见的记录：

由图可以看出，最新版本的列name的内容是孙权，该版本的trx_id值为100。开始执行read view可见性规则校验：

min_limit_id(100)=<trx_id（100）<102;
creator_trx_id = trx_id =100;

由此可得，trx_id=100的这个记录，当前事务是可见的。所以查到是name为孙权的记录。

事务B进行修改操作，把名字改为曹操。把原数据拷贝到undo log,然后对数据进行修改，标记事务ID和上一个数据版本在undo log的地址。

事务B提交事务
事务A再次执行查询操作，因为是RR（可重复读）隔离级别，因此会复用老的Read View副本，Read View对应的值如下

变量	值
m_ids	100，101
max_limit_id	102
min_limit_id	100
creator_trx_id	100

然后再次回到版本链：从版本链中挑选可见的记录：

从图可得，最新版本的列name的内容是曹操，该版本的trx_id值为101。开始执行read view可见性规则校验：

min_limit_id(100)=<trx_id（101）<max_limit_id（102);
因为m_ids{100,101}包含trx_id（101），
并且creator_trx_id (100) 不等于trx_id（101）

所以，trx_id=101这个记录，对于当前事务是不可见的。这时候呢，版本链roll_pointer跳到下一个版本，trx_id=100这个记录，再次校验是否可见：

min_limit_id(100)=<trx_id（100）< max_limit_id（102);
因为m_ids{100,101}包含trx_id（100），
并且creator_trx_id (100) 等于trx_id（100）

所以，trx_id=100这个记录，对于当前事务是可见的，所以两次查询结果，都是name=孙权的那个记录。即在可重复读（RR）隔离级别下，复用老的Read View副本，解决了不可重复读的问题。

大家可以回头多看几遍我这篇文章哈：看一遍就理解：MVCC原理详解

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

一个消息从生产者产生，到被消费者消费，主要经过这3个过程：

生产者产生消息
消息发送到存储端，保存下来
消息推送到消费者，消费者消费完，ack应答。

因此如何保证MQ不丢失消息，可以从这三个阶段阐述：

生产者保证不丢消息
存储端不丢消息
消费者不丢消息

10.1 生产者保证不丢消息

生产端如何保证不丢消息呢？确保生产的消息能顺利到达存储端。

如果是RocketMQ消息中间件的话，Producer生产者提供了三种发送消息的方式，分别是：

同步发送
异步发送
单向发送

生产者要想发消息时保证消息不丢失，可以：

采用同步方式发送，send消息方法返回成功状态，即消息正常到达了存储端Broker。
如果send消息异常或者返回非成功状态，可以发起重试。
可以使用事务消息，RocketMQ的事务消息机制就是为了保证零丢失来设计的

10.2 存储端不丢消息

如何保证存储端的消息不丢失呢？确保消息持久化到磁盘，那就是刷盘机制嘛。

刷盘机制分同步刷盘和异步刷盘：

同步刷盘：生产者消息发过来时，只有持久化到磁盘，RocketMQ的存储端Broker才返回一个成功的ACK响应。它保证消息不丢失，但是影响了性能。
异步刷盘：只要消息写入PageCache缓存，就返回一个成功的ACK响应。这样提高了MQ的性能，但是如果这时候机器断电了，就会丢失消息。

除了同步刷盘机制，还有一个维度需要考虑。Broker一般是集群部署的，有主节点和从节点。消息到Broker存储端，只有主节点和从节点都写入成功，才反馈成功的ack给生产者。这就是同步复制，它保证了消息不丢失，但是降低了系统的吞吐量。与之对应即是异步复制，只要消息写入主节点成功，就返回成功的ack，它速度快，但是会有性能问题。