滴滴网约车部门一面至三面面经！史上最强汇总！包括所有面经答案！

目录

一面（30min）

1、自我介绍

2、考研 or 保研 （很奇怪）

3、实习（包含八股）

4、手撕代码

二面 （大概1h）

手撕代码

三面（1h10min）

1、自我介绍

2、八股

3、科研

4、实习经历

5、代码

6、反问

总结一下

八股文答案

1、分布式存储的一致性怎么保证？

2、怎么在底层保证一致性的策略？

3、主节点和从节点断开连接，怎么去保证从节点能正常读到数据

4、分布式的一致性存储的问题有哪些问题？

5、同步、异步、阻塞、非阻塞有什么关系吗？

6、同步改造成异步有什么好处？

7、解释一下io几种模型？

8、有一个模型是非阻塞的，它是属于同步和异步的哪种呢？

9、怎么理解io的？

10、索引失效的场景？

11、索引在使用时因注意什么？

12、redis两种持久化方式的优缺点？

13、redis都能用来干什么？

14、pv和uv 的区别？

---

一面（30min）

1、自我介绍

2、考研 or 保研 （很奇怪）

3、实习（包含八股）

•  分布式存储的一致性怎么保证？
• 怎么在底层保证一致性的策略？
• 主节点和从节点断开连接，怎么去保证从节点能正常读到数据
• 分布式的一致性存储的问题有哪些问题？
• 同步、异步、阻塞、非阻塞有什么关系吗？
• 同步改造成异步有什么好处？
• 解释一下io几种模型？
• 有一个模型是非阻塞的，它是属于同步和异步的哪种呢？
• 怎么理解io的？

        这个没回答出来！然后面试官说我回答了一半一半，然后把手撕做出来就给我过。侥幸代码撕出来了

4、手撕代码

• 力扣原题，二叉树中序遍历非递归
• 它的时间复杂度是多少？O(N)

二面 （大概1h）

        忘记录音了，大多记得不太清楚，只记得写了2个sql语句，然后问了很多关于mysql、redis相关八股

手撕代码

       力扣原题，删除倒数第n个链表，只遍历一次，我第一次写遍历了2次，然后面试官提醒了一下，我又重新写了第二个版本，然后过了。

三面（1h10min）

1、自我介绍

        如果去滴滴，需要转go，能不能接受？

2、八股

• sql两道题，第二道题需要用到子查询，然后我写了两个sql语句，并且提到了子查询，后来面试官说用子查询，我没写出来，面试官说跳过不纠结了
• 索引失效的场景？
• 索引在使用时因注意什么？
• redis两种持久化方式的优缺点？（RDB 它的刷盘比较慢，但是它的写入特别快，而AOF在刷盘的时候时候速度较快，但是写入的速度较慢，主要是因为AOF存储的是sql语句，它需要执行sql语句）
• redis都能用来干什么？
• pv和uv 的区别？（简单可以说uv 是去重的，pv是不去重的）

3、科研

       科研能力，有发过什么论文吗？

       深度学习相关内容？

4、实习经历

       找到一个影响最大，比较证明你能力的一件事情

       cpu夯死的原因是什么？

5、代码

       力扣原题：从一个字符串里找出最长的回文字符串

6、反问

       业务？

       什么时候出结果？他这马上给出结果，具体看hr那边，如果过了话，后面还会有一轮hr面。

       Java转 go 过渡期时间？ 可能长达一个月，校招生在网约车的体验会非常棒。

总结一下

        三面的面试体验相当不错，面试官一直在引导，其中有2个八股没回答出来，面试官还细心引导，然后面试官思路比较清楚，明说今天从几方面进行考察，感觉从他口中听到网约车这个部门应该还不错，有没有都是网约车的兄弟来聊聊是不是都在池子里，大家都是go的吗，因为我个人是java，不知道会不会因为这个原因被排到很后面

        一面感觉问的偏向os，整体答得不是很好，二面偏向java和数据库，答得还不错，三面的话中规中矩

八股文答案

• 1、分布式存储的一致性怎么保证？

        1. 优先使用异步消息。

        使用异步消息 Consumer 端需要实现幂等。

        幂等有两种方式，一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。

        另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库，发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。

        2. 有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。

        比如 A 同步调用 B，C。A 本地事务成功的时候更新本地事务记录状态，B 和 C 同样。如果有一次 A 调用 B 失败了，这个失败可能是 B 真的失败了，也可能是调用超时，实际 B 成功。则由一个中心服务对比三方的事务记录表，做一个最终决定。假设现在三方的事务记录是 A 成功，B 失败，C 成功。那么最终决定有两种方式，根据具体场景：

1. 重试 B，直到 B 成功，事务记录表里记录了各项调用参数等信息；

2. 执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。

        对 b 场景做一个特殊说明：比如 B 是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候