小姐姐面试蚂蚁金服被虐经历,敖丙心疼...

小姐姐面试蚂蚁金服被虐经历,敖丙心疼...
文章图片
面试前的小姐姐
来说说前不久蚂蚁金服一面的情况 。 说来也是巧合 , 当时在群里有位蚂蚁金服的小姐姐发了个内推 , 看了下JD感觉可以试试于是就私聊了小姐姐发简历内推了 。
我16年也就是大三上就开始实习了 , 到现在其实不到三年的经验 。 就我个人而言面试的经验真的是少之又少 , 不超过一个手掌的数 。 因此我简历发给小姐姐之后又联系她 , 让她晚点推让我先找几个公司练练手 。
但是小姐姐说她可以先帮我热热身 , 她也是面试官(小姐姐可真的是太好了!) , 挑了晚上和小姐姐语音了20多分钟 , 虽然不是具体的面试内容 , 但是内容比这个更干!她我说了说一面二面大致的问的方向和注重点 , 还有一些注意事项:
一面:
我:假如有些方法实在记不起来能在idea写了拷过去吗?小姐姐:这个你可以跟面试官提 , 不过就我而言比较减分 , 并且你idea写代码 , 面试官可能会把代码拿来跑而不是目测过了就好了 。 如果没跑过也基本上没了 。
我:哦哦好的好的 。
小姐姐:然后就是自我介绍 , 一面着重考察基础方面 , 比如锁啊、GC啊、常见集合等等 。 再会根据你的简历 , 比如我看你简历写了dubbo , 那就会问一些dubbo方面的问题 。 这么一堆谈下来差不多了 , 一面半小时左右 。
我:哦哦好的好的 。 对了一面如果过了的话得多久才会有通知?周期会很长吗?
小姐姐:基本上2-3个工作日就会有结果了 。
二面
小姐姐:二面的话比较考察项目 , 基本上会先让你描述一些项目整体的架构 , 从哪里到哪里数据怎么流转 , 项目的tps、qps等 , 基本上答不出来就认为你不是项目的核心人员 。 然后为什么这么设计 , 有哪些优化点?这是考察你对平日的工作有没有足够的思考 。
我:哦哦好的好的(瑟瑟发抖) 。
三面、四面
小姐姐:emm....你过了一面二面再说吧 。
我:是是是!放眼当下 。
其实我是真想先投几个公司先找下节奏的 , 但是小姐姐都这样说了我就只能直面人生了!过了两天面试官就来电话了 , 约个几天后的晚上7点 , 并且指明需要有电脑(小姐姐诚不我欺啊) , 我问需要摄像头不 , 答:不需要 , 能上网就行 。
面试正文
其实我也忘记到底约的是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就行 , 或者Guavacache或者Ehcache 。 用本地缓存来应对极热数据 。
小哥哥:那好吧 , 来说说MQ吧
我:(小哥哥有点失望的样子 , 哎也是不应该但是脑子就是想不起来..)常见的有RocketMQ、KafKa等 , RocketMQ更适合业务 , 注重时延的优化 。 Kafka因为存在攒一波的思想 , 吞吐更高 , 并且适合大数据场景 , 不适合业务 。
小哥哥:攒一波是什么意思?
我:攒一波就是发消息默认不是一条一条发 , 是等一波再发(其实攒一波思想很常见 , 例如tcp的纳格算法 , pageCache的批量刷盘等等)
小哥哥:那Kafka是哪种模式?
我:什么意思?什么模式?
小哥哥:就是消息不是有推和拉两种模式
我:额...(我不知道 , 我就知道RocketMQ的 , 是基于拉的 , 虽说有个pushConsumer , 但是本质上也就是拉 , 只是broker先hold住了拉的request 。 我也知道拉模式和推模式的优缺点 , 只是我当时傻了 , 我当时脑子想我简历就没写Kafka , 为啥问我Kafka不问我RocketMQ , 其实我应该先说说推拉模式的优缺点然后说了RocketMQ是采用什么的 , 然后说下我对Kafka不太熟 , 只是我当时傻了...)我说推?应该是推吧?不对不对好像是拉....(我真的是神操作)
小哥哥:不知道就说不知道 , 不要乱说一通 。
我:是是是 , 我不知道对不起 。 (是的不知道就直接说不知道 , 然后应该把自己知道的说出来 , 弥补下)
【小姐姐面试蚂蚁金服被虐经历,敖丙心疼...】小哥哥:说说synchronize和lock区别


    推荐阅读