颍上新闻,颍上资讯

这段时期分享了诸多校招的面经，有不少读者表示想看社招的，实际上社招面试是依据你的工作项目来展开提问的，比如说你项目运用了xxx技术，那么面试就会进一步询问你项目是怎样运用xxx技术的，碰到了什么难点以及挑战，随后再考查一下这个xxx技术的原理。

就今天分享一位快手社招面经，岗位为后端开发，问题皆关乎项目涵盖的相关技术栈从而就此展开交流，并且最后还会存在算法题。

项目 Redis

Redis有哪些数据类型

从这些当中进行回答，有String，有list，在其之中又包含map，再加上这个和set，另外还有Zset，以及stream，还有hyperloglog 。。。

（打断）追问：map怎么扩容，扩容时会影响缓存吗

回应：底层存在两个字典，其中一个字典承担请求职责，当抵达负载比例时实施扩容，以渐进方式扩容，一部分一部分地转移至新的字典 。

追问：扩容时访问key怎么处理?

作答：首先去旧的dict那儿将key获取，要是查找不到的情形下，接着自新的dict把key获取 。

小林补充：

进行 rehash 的时候，需要用上 2 个哈希表了。

img

于正常服务请求阶段之时，所插入的数据，全部都会被写入至「哈希表 1」当中，而在这个时候的「哈希表 2」，并未被分配有空间。

伴随数据一点点地增多，引发了 rehash 操作，此过程划分成三步：。

我将 rehash 的这三个过程，画在了下面这张图，目的是为了让你理解起来更方便， 。

img

这个过程，看上去简单，然而实际上，第二步存在很大问题，要是「哈希表 1 」的数据量极大，那么在迁移到「哈希表 2 』时，鉴于会牵涉众多数据拷贝，这时有可能给 Redis 带来阻塞，使之无法服务别的请求。

在数据迁移进程里，为防止 rehash 因拷贝数据所耗时长的缘故，对 Redis 性能造成影响这种情形出现，Redis 采用了渐进式 rehash，即数据迁移工作并非一次性迁移完毕，而是分多次来迁移。

渐进式 rehash 步骤如下：

为此，巧妙地进行分摊，将一次性大量数据迁移时候的开销，分摊至多次处理请求这件事儿，在这个过程里，避免了那一次性操作所带来的耗时，也就是避免了 rehash 这种操作所耗费的时间 。

在开展渐进式 rehash 的进程当中，存在着两个哈希表，因而在渐进式 rehash 实施期间，哈希表元素的删除、查找以及更新等操作，均会在这两个哈希表予以进行。举例而言，若要查找一个 key 的值，首先会于「哈希表 1」之中展开查找，要是未找到，接着便会持续到哈希表 2 里面去查找。

此外，于渐进式rehash开展之际，当新增一个key - value时，它会被存至「哈希表2」当中，然而「哈希表1」不再开展任何添加行为，如此确保了「哈希表1」的key - value数量只会变小，随rehash操作的结束，最终「哈希表1」会变为空表。

跳表结构了解吗

回答：第一层是双向链表，会有多层来作为链表的索引。

追问：和二叉树有什么区别，从时间复杂度和空间复杂度分析

应答：对于二叉查找树而言，其时间复杂度为 O(logn)，其空间复杂度为 O(n) ；就跳表来讲，其时间复杂度为 O(log_{k}n)，这里的 k 是跳表索引步长，其空间复杂度为 O(n) 。

MySQL

MySQL事务用过吗，应用场景是什么

自己学习的demo里用过，场景：银行转账

追问：假如是跨行转账怎么解决事务

回答：我想一想。。。

小林补充：用分布式事务

（打断）追问：暂且不说跨行的那些事儿，先讲讲不跨行这边，先讲一讲单库事务，事务有着四个基本特性 。

回答：原子性，一致性，隔离性，持久性

追问：一致性指的是什么

回答：一致性所指的乃是在事务提交之前与之后，数据库的状态保持一致，它是由原子性、隔离性以及持久性整合而成的 。

追问：隔离级别有哪几种

回答：读未提交，读已提交，可重复读，序列化

追问：可重复读是是什么意思，怎么实现的

在同一个事务里，多次去读取，其结果会保持一致，借助Read View以及MVCC来达成，于事务开始之际，创建出一个Read View，在那之后，全都运用这个Read View。

追问：可重复读具体实现细节

回答：Read View的结构涵盖这些，其一为当前事务id，其二是active事务id列表，其三是最小active事务id被称作min_txn_id，其四是next事务id被记作max_txn_id。要是record所对应的事务id，小于最小active事务id，那就直接读取；不然的话就去读取最小active事务id之前版本的数据（这块的逻辑回答存在问题，在通过语言进行表达的时候有点混乱，能够私下里多进行练习练习表达） ！

小林补充：

我们需要了解两个知识：

那 Read View 到底是个什么东西？

img

Read View 有四个重要的字段：

知晓了Read View的字段，我们尚须去明白聚簇索引记录里的两个隐藏列。 ， 。

假设着呢，在账户余额表那儿插入一条记录，这条记录是小林的余额为 100 万，之后呢，我把那两个隐藏列也给画出来瞧见它，该记录的整个示意图呈现出来是这样的：

图片

对于数据库表，其使用InnoDB存储引擎，它的聚簇索引记录里均含有下面这两个隐藏列，。

当创建了Read View之后，对于记录里的trx_id，我们能够把它划分成这三种情形：

img

一个事务，在去访问记录之际，除了自身的更新记录始终是可见的以外，还存在着这几种情形：

MySQL的binlog，redolog 以及 undolog 之间存在着区别 ， 。

作出的答复是这样，从这三种log所具备的功能着手展开分析，undolog的作用是用以进行事务回滚，redolog的功用是针对mysql出现宕机情况或者进程意外挂掉之时，来处理相关的数据恢复事宜，binlog能够记录下每一项数据的修改操作，可以将其用于全量的数据恢复工作，还能够实现主从复制，关于后一点当时一时没有回答出来，是这样的 。

小林补充：

binlog（二进制日志），它记录着所有针对MySQL数据库的修改操作，像插入、更新以及删除等等。binlog主要用以把数据恢复到指定的时间点，或者说是指定的事务上。通过使用mysqlbinlog命令，能够将binlog文件解析成SQL语句，进而恢复MySQL数据库的状态。

记录所有针对MySQL数据库而言所作修改操作的redolog（重做日志），不过仅仅记录了诸如页的修改这般的物理操作，redolog主要是为MySQL在崩溃之后的恢复所用，也就是在MySQL崩溃后，借助redo日志，把数据库恢复到最近一次提交时的状态，能够采用Forcing InnoDB Recovery来开展崩溃恢复。

记录事务回滚操作的undolog（回滚日志），是InnoDB存储引擎特有的日志，和其他存储引擎不同，主要作用于MySQL的回滚操作，像使用ROLLBACK语句回滚事务时，会在事务执行过程中若发生回滚，就将回滚操作记录到undolog中。

追问：binlog和redolog做数据恢复的区别

回答：redolog存在大小方面的限制，数据存在被覆盖的可能性，其作用是处理紧急的数据库故障，binlog是全量操作的日志能进行全量数据恢复的操作 。

小林补充：

MySQL数据库所用到的日志之中，存在着binlog以及redolog这两种，它们都能够被运用到数据恢复这一方面的操作上不过呢，它们在实际的使用场景以及具体的恢复方法上，却有着不一样的地方。

binlog属于MySQL的二进制性质日志，它记载了全部针对MySQL数据库的修改类操作，涵盖插入、更新以及删除等情况。binlog能够用以把MySQL数据库恢复至特意指定的时间点或者特意指定的事务。详细来讲，可以借助mysqlbinlog命令将binlog文件解析成SQL语句，并把这些SQL语句再予以执行，进而恢复MySQL数据库的状态。

redolog属于MySQL的重做日志，它记载了全部针对MySQL数据库的修改举动，只是记载了物理操作，像页的修改。redolog能够用以恢复MySQL数据库的崩溃情况，也就是在MySQL崩溃后，凭借重做日志，把数据库恢复至最近一次提交的状态。详细来讲，可以运用innodb_recovery命令来实施崩溃恢复，该命令会依照重做日志来恢复数据库。

所以，binlog以及redolog均能够用以数据恢复，然而它们的运用场景跟恢复办法存在差异。binlog重点是用以将数据恢复至指定的时间点或者指定的事务，而redolog主要是用于MySQL的崩溃恢复。

面对算法相关面试进行总结，觉得在基础知识方面回答得还算尚可，然而在编程部分却有所欠缺，存在不足之处 。

有些地方的表达逻辑不够清晰，代码得多写。