面试蚂蚁金服鏖战一个半小时，人事小姐姐帮我神助攻拿下offer，奉上我的复习宝典！

面试前的小姐姐

来说说之前蚂蚁金服一面的情况。说来也是巧合，当时在群里有位蚂蚁金服的小姐姐发了个内推，看了下 JD 感觉可以试试于是就私聊了小姐姐发简历内推了。

就我个人而言面试的经验真的是少之又少，不超过一个手掌的数。因此我简历发给小姐姐之后又联系她，让她晚点推让我先找几个公司练练手。

但是小姐姐说她可以先帮我热热身，她也是面试官（小姐姐可真的是太好了！），挑了晚上和小姐姐语音了20多分钟，虽然不是具体的面试内容，但是内容比这个更干！她我说了说一面二面大致的问的方向和注重点，还有一些注意事项：

一面：

小姐姐：上来先会给两道编程题，二选一，不会是很难的算法那种，比较务实。基本上常年在一线编程的话能写的出来。是发个链接给你的邮箱，然后点击链接在线编程，没有代码提示，写不出来基本上就是没了。

我：假如有些方法实在记不起来能在 idea 写了拷过去吗？

小姐姐：这个你可以跟面试官提，不过就我而言比较减分，并且你idea写代码，面试官可能会把代码拿来跑而不是目测过了就好了。如果没跑过也基本上没了。

我：哦哦好的好的。

小姐姐：然后就是自我介绍，一面着重考察基础方面，比如锁啊、GC啊、常见集合等等。再会根据你的简历，比如我看你简历写了 dubbo，那就会问一些 dubbo 方面的问题。这么一堆谈下来差不多了，一面半小时左右。

我：哦哦好的好的。对了一面如果过了的话得多久才会有通知？周期会很长吗？

小姐姐：基本上2-3个工作日就会有结果了。

二面

小姐姐：二面的话比较考察项目，基本上会先让你描述一些项目整体的架构，从哪里到哪里数据怎么流转，项目的tps、qps等，基本上答不出来就认为你不是项目的核心人员。然后为什么这么设计，有哪些优化点？这是考察你对平日的工作有没有足够的思考。

我：哦哦好的好的(瑟瑟发抖)。

三面、四面

小姐姐：emm…你过了一面二面再说吧。

我：是是是！放眼当下。

其实我是真想先投几个公司先找下节奏的，但是小姐姐都这样说了我就只能直面人生了！过了两天面试官就来电话了，约个几天后的晚上7点，并且指明需要有电脑(小姐姐诚不我欺啊)，我问需要摄像头不，答：不需要，能上网就行。

下面附上我的复习宝典，这是我根据各大公司面试题整理的资料，以及自己写的一些笔记，包括了有基础知识、Java集合、JVM、多线程并发、spring原理、微服务、Netty 与RPC 、Kafka、日记、设计模式、Java算法、数据库、Zookeeper、分布式缓存、数据结构等等。需要的朋友点击这里备注csdn即可免费获取，诚意满满等你来拿，希望对你有帮助！

面试正文

其实我也忘记到底约的是7点还是7点半，反正我7点坐在电脑前面等了，内心激动的一批，饭都吃不下等到了7.35，终于等到你还好我没放弃！！

听到电话那头传来的温柔的小哥哥声音，来了他终于来了！我已经打开邮箱等待编程题的到来了！

小哥哥：来先做个自我介绍吧。

我：emm？？？不是说上来先做两道题吗？额可能是先自我介绍下再做题把？于是我就巴拉巴拉说了20秒，说到在现在公司做一部分前端开发的时候就被打断了。
小哥哥：说说你写前端有什么感触？

我：我想要换工作有很大一部分原因就是因为现在我需要做前端，前端对我而言吸引力不大，虽然对于后端而言前端给予的正反馈更加的明显和及时，但是我更喜欢后端在背后默默输出的感觉。

小哥哥：是的，前端对于后端而言更加的简单，掌握了几个框架基本上就够用了，天花板比较低。

我：是的是的，后端的东西太多了，涉及到的面很广(各位前端听友，上面的话是小哥哥说的，原话，雨我无瓜。我也是身不由己是吧，请海涵哈)

小哥哥：看你简历写了Dubbo、Redis、RocketMq，你挑个你最厉害的说说？

我：（我擦，我个人觉得这个问题看似为我考虑，实则暗藏杀机）redis吧？

我其实大脑快速过滤了一下感觉redis比较稳，我觉得能问的无非是：
redis为什么单线程？IO多路复用？
redis和memcached的优缺点？
redis五个对象？每个对象的底层数据结构？
redis的布隆过滤器(我还可以给你引申个布谷鸟过滤器)、hyperLogLog(我还给你说出是基于伯努利实验)
redis的过期删除机制？淘汰机制？
redis的RDB和AOF？
redis的事务？
redis的主从?哨兵？集群？
redis的分布式锁？redlock？(来嘛martin大神对刚redis作者的内容我都说的出来)
redis的一些优化？大key拆分？通过游标分批返回避免key*等命令阻塞？禁止swap？考虑内存碎片等等？
感觉好像挺稳的那就redis吧！

小哥哥：redis集群介绍一下

我：（来了来了！）redis的集群是将一共16384个槽分给集群中节点，每个节点通过gossip消息得知其它节点的信息，并在自身的clusterState中记录了所有的节点的信息和槽数组的分配情况

小哥哥：客户端是如何访问集群的？

我：客户端会先访问集群中的一个节点，如果槽命中直接访问，如果不命中，则会返回MOVED指令，并告知槽实际存在的节点，然后再去访问。(这里其实还有个迁移中的情况，如果访问的槽正在迁移，则返回ask命令，客户端会被引导去目标节点查找)

小哥哥：你们公司是用集群么？

我：是主从

小哥哥：知道关晓彤么？

我：？？？(什么情况这个跨度这么大吗？)

小哥哥紧接着说：就是和鹿晗那次把微博弄挂了的情况

我：哦哦哦知道知道

小哥哥：微博这么大的公司了，而且出了这么多这种事故？为什么还会挂了？

我：（我擦，为什么这么出了这么多次情况还会挂我咋知道！这么大公司监控服务很到位的啊，并且报警自动扩缩容这一套组合拳下来感觉不应该挂的啊，它为啥挂了…）我弱弱的说了句热点key的问题？太热了顶不住

小哥哥：那怎么处理呢？

我: 首先保障热点 key 过期问题，给不同的热点key分配随机的过期时间，保证过期的平滑。然后可以通过在 Redis 中设置分布式锁，只有获取到锁的请求才能够穿透到数据库，保证同一时间只有一个请求可以穿透到数据库更新缓存。

小哥哥：不是，我不是这个意思，我是问这个热点key的访问要如何解决？

我：可以通过 hash 分 key，把一个 key 拆分成多个 key，分布到不同的节点，防止单点过热。比如一个 key 之前就分到一个节点上，我把 key 做了拆分，就像一致性 hash 的虚拟节点，分散访问。

小哥哥：你说到一致性 hash？那和普通hash有什么区别？

我：一致性hash把hash的空间虚拟成一个圆环，key做hash落在圆环上，按顺时针查找，遇到的第一个缓存节点就命中。通过虚拟节点避免缓存分布不均，并且使得某个节点挂了之后，下面的节点只需要承担一部分的流量而不会因为需要承担所有流量而挂了，然后发生雪崩

小哥哥：好，那我们说回刚才的问题，你刚说的是一种解决方案那还有什么别的方案么？

我：（还有？？我真的没了，我思考了十秒钟，一片空白不知道了）不知道了。

其实还有本地缓存，简单点就一个HashMap就行，或者Guava cache或者Ehcache。用本地缓存来应对极热数据。

小哥哥：那好吧，来说说MQ吧

我：（小哥哥有点失望的样子，哎也是不应该但是脑子就是想不起来…）常见的有RocketMQ、KafKa等，RocketMQ更适合业务，注重时延的优化。Kafka因为存在攒一波的思想，吞吐更高，并且适合大数据场景，不适合业务。

小哥哥：攒一波是什么意思？

我：攒一波就是发消息默认不是一条一条发，是等一波再发(其实攒一波思想很常见，例如tcp的纳格算法，pageCache的批量刷盘等等)

面试结果

文章的最后我想说的是面试前一定要注重复习，只要复习的好，面试一定不会紧张，下面附上我的复习宝典：

对于大厂面试，我最后想要强调的一点就是心态真的很重要，是决定你在面试过程中发挥的关键，若不能正常发挥，很可能就因为一个小失误与offer失之交臂，所以一定要重视起来,以上资料都是免费获取的，有需要的朋友点击这里备注csdn即可领取，希望能帮助到你们，帮你们拿到自己心仪的offer，最后依然祝福大家，求妻得妻，求子得子，求offer得offer。

标签：小姐姐,offer,哥哥,redis,面试,key,金服,节点
来源： https://blog.csdn.net/jiagouwgm/article/details/110291497