【面经合集】当 deepseek 遇上字节的面试｜后端｜01

🌟【友情提示】本篇面经来自粉丝投稿+智能润色，点击进入 -> 🔗互联网面经大全 围观25届校招修罗场！！每个技术细节都经过脱敏处理，请勿对号入座~

🌈 面试官：

今天咱们主要聊聊中间件相关的设计思路哈。先说说你在项目里用Redis做缓存时，持久化机制是怎么设计的？

💬小基：

当时我们项目同时开启了RDB和AOF两种持久化方式。RDB就像定时拍快照，每五分钟全量备份一次，好处是恢复数据快，而且备份文件比较小。不过要是服务器突然宕机，可能会丢五分钟的数据。

AOF这边是实时记录所有写操作命令，每秒刷盘一次。这样最多丢1秒的数据，但是文件会越来越大，所以我们设置了当AOF文件超过上次两倍时自动重写，把冗余命令合并精简。

🌈 面试官：

那如果线上遇到缓存穿透怎么办？怎么区分是正常流量还是恶意攻击？

💬小基：

我们当时用了个组合拳！首先在网关层做了基础的风控，过滤明显异常的请求。缓存层用布隆过滤器把关，把不存在的数据直接挡掉。对于极少数漏过的请求，我们会在Redis里存个空值标记，设置5分钟短过期时间。

区分流量的话主要看三点：一看请求参数是否合乎业务逻辑，比如查询的ID明显超出业务范围；二看请求频率，恶意的往往集中在某个key疯狂请求；三看客户端特征，比如新注册账号突然大量请求。

🌈 面试官：

消息队列的重复消费问题遇到过吗？你们的解决方案是？

💬小基：

确实踩过这个坑！比如订单支付回调消息重复推送的情况。我们后来在消费端做了三层防护：

1. 数据库层面给业务主键加唯一索引
2. 在Redis用setnx存已处理的消息ID，设置24小时过期
3. 消费逻辑里先查业务表是否存在记录 这样就算消息重发，最多也就是多查几次缓存，不会产生脏数据。

🌈 面试官：

最后来个场景题：设计个短链系统，怎么保证生成的短码不重复？

💬小基：

我们当时调研了两种方案：第一种是预生成号段，用发号器每次取1000个号码放到内存队列，快用完时异步补充。第二种是结合哈希算法+重试，比如用MurmurHash生成62进制8位码，发生碰撞时自动加盐重试三次，再不成功就返回错误。

最终选了第二种方案，因为业务量还没到需要预生成的程度。实测下来千万级数据量碰撞概率不到0.3%，重试机制完全够用，还能节省存储空间。