2025.4.9 元盟科技一二面

其实和我看到的大多数文章都不太一样(为此我还复习了Spring的八股),可能是因为我光做项目了 (技术栈没学的人是这样的( ),大部分都是项目拷打。

下午约的一面(实际上我没看到早上的消息,重新约面到下午了)

0手撕,八股也基本很少。两场面试官给我感觉还是很不错的,比较和蔼,愿意听我说,有时候被反问也没有想到一些问题。

一面(30min)

自我介绍

项目拷打...

我要自定义序列化和反序列化,对吧?那你觉得是在 OSI 的 7 层模型当中,哪一层。为什么,稍微聊下?(表示层)√

深翻页?深翻页为什么会慢?

我这边了解得差不多了。嗯,您看一下您这边有什么想了解的?

二面(40min)

二面约在了当天晚上,这次面试不知道为什么用的热点有点卡~~ 估计是比较影响ToT.我介绍的时候面试官都让我把视频关了,介绍完,后面不卡的时候我打开了,但是后面又比较卡了,😔

自我介绍

项目拷打...

DDD 这块你了解多少?那个实体是,你是怎么理解的?聚合根?

跨领域的一些个操作,那你认为现在放在哪呢?

RocketMQ消息乱序问题怎么解决?

MySQL深度翻页问题怎么解决?

那 ES 的话,嗯,也有深度分页问题啊。诶,那怎么解决呢?(早知道不提了,唐完了)

MySQL 的那个性能调优这方面。嗯,你有什么经验?

那如果是返回的 using condition index,那你觉得它还有没有优化的空间?

那你那个对加班有什么看法?

全部评论
接好运
1 回复 分享
发布于 04-11 00:12 浙江
建议润
点赞 回复 分享
发布于 05-08 21:24 广东
oc了吗
点赞 回复 分享
发布于 04-11 21:14 日本
佬OC了吗
点赞 回复 分享
发布于 04-10 20:56 广东

相关推荐

头像
05-09 16:23
已编辑
华南师范大学 Java
一面后1小时通知二面——————————#面试问题记录#整整一个小时的拷打,场景题+项目拷打 几乎无八股文🧠 个人背景与项目经历1.你自我介绍一下?2.你做的两个项目中,哪个是实习?哪个是练手项目?3.实习项目主要做了什么?用到了哪些技术和框架?4.练手项目是独立做的吗?用了哪些模块和功能?    5.你对这个练手项目熟悉吗?可以详细介绍一下它的功能模块?💻 技术能力 - 后端开发1.你项目的XX流程是怎么实现的?Redis + Lua 在其中起到什么作用?2.你项目的Redis 缓存预热结构是怎样的?怎么判断用户状态?3.你用 MQ 的目的是什么?为什么不是直接操作数据库?4.MQ 消费失败的情况下你是怎么处理的?有重试机制吗?5.死信队列和超时取消使用的是同一个吗队列?怎么区分消息类型?6.redis成功执行写入了但 MQ 落库消费失败怎么办?Redis 写成功就代表成功吗?7.JWT 是怎么生成和校验的?用了什么加密算法?8.用户主动登出是怎么实现的?🧵 多线程与分布式9.Redis 的原子性是怎么保证的?10.项目中你有没有考虑幂等性?怎么防止重复请求的幂等性?11.XX场景中是否能做到最终一致性?如何通知用户成功?☁ MQ & 延迟任务12.延迟队列的作用是什么?项目中用来处理哪类业务?13.死信队列是如何配置的?超时和消费者消费失败如何分别处理?14.如果 MQ 消息失败进入死信队列,你是如何排查和处理的?15.MQ 消息失败重试到上限后该怎么办?16.使用 RabbitMQ 是为了提高性能还是为了消息可靠性?17.项目中有没有处理 MQ 消息重复消费问题?🧩 MySQL & 数据库能力18.MySQL 的 B+树结构你了解吗?聚簇索引和非聚簇索引有什么区别?19.建立索引有什么原则?如何判断字段是否适合建索引?20.用“性别”字段建索引合适吗?为啥说选择性低不适合?21.全表扫描和使用区分度低的索引扫描哪种情况下更快?22.大分页 offset 性能差怎么优化?23.在实习中是怎么优化SQL的? 🎯场景题:高并发请求失败后处理方式💡 题目背景描述:你接入了一个第三方服务,该服务每天发送约 300 万次请求给你们系统。其中,每个请求都包含一个全局唯一的 requestId(一个 40 字节的 UUID 字符串)。如果因为网络中断、超时等原因导致第三方没有收到响应,它会重新发起完全相同的请求(带相同的 requestId),业务上有几个关键限制:    1、每个 requestId 表示一次业务处理,例如支付通知、回调、交易同步等。    2、你方必须保证对于每个 requestId,只能处理一次(典型的幂等性要求)。    3、不能重复请求第三方服务(第三方服务不具备幂等性)    4、由于网络波动或响应失败,同一个 requestId 有可能会在不同时间再次被发送过来,甚至有以下复杂时间分布:        4.1、绝大部分重复请求会在20 分钟内重发;        4.2、一小部分会在1 天内重发;        4.3、极个别(例如接口挂起重试)会在一年后突然重发。🤯 关键技术难点:    如何快速识别“是否已处理过某 requestId”?    如何既不误判(重复处理)又不滥用资源(存一年)?    如何兼顾吞吐量、IO压力、成本?
点赞 评论 收藏
分享
评论
3
1
分享

创作者周榜

更多
牛客网
牛客企业服务