分享社招面经——懂车帝1面

懂车帝 - 后端开发 面试复盘 一、基本信息

• 公司:懂车帝(字节跳动)
• 岗位:后端开发
• 轮次:一面
• 面试形式:远程视频
• 候选人背景:小米数仓+服务端开发,2024届华中农业大学本科
• 已挂 二、面试问题与回答

1. 自我介绍

• 问题:简单自我介绍
• 回答:华中农业大学20届应届生,小米工作近两年,主要做数仓开发和服务端开发

2. Redis基础数据结构

• 问题:说一下Redis的几个基础结构
• 回答:
  • 五个基础数据结构:string、list、hash、set、zset
  • 其他数据结构:bitmap、geo、hyperlog等
  • string用于token、key-value存储
  • hash用于可重入锁设计,存储对象并计数
  • list用于队列,SDK全链路采集中用list作缓存队列,按批次写入PG数据库

3. 用户分数排行榜设计

• 问题:实现用户分数排行榜用什么数据结构
• 回答:用zset,它自带排序功能,可直接展示排序后的数据
• 追问:千万级别用户分数排行榜怎么实现
• 回答:
  • Redis集群部署,提高并发能力
  • 限流:使用Redis漏桶算法
  • 但对于千万级数据直接放在一个zset中的大key问题回答不清楚

4. 大key问题

• 追问:大key会造成什么问题
• 回答:
  • Redis是单线程,大key查询响应慢
  • 虽然有IO多路复用,但大key返回慢会影响整体性能
  • 对大key的具体处理方案和上限值回答不清楚

5. 热key问题

• 问题:如何防止热key失效导致的问题
• 回答:
  • 热key预热
  • 谨慎设置过期时间
  • 保证数据库中的key可以命中

6. 缓存一致性

• 问题:数据库写、缓存读,如何处理缓存一致性
• 回答:
  • 采用先更新数据库,再删除缓存的策略
  • 这样可以保证在高并发多线程情况下不会因为Redis和数据库更新顺序导致数据不一致

7. 布隆过滤器

• 问题:对布隆过滤器有了解吗
• 回答:
  • 用于解决缓存穿透问题
  • 当数据库和Redis都没有查询的数据时,请求会一直击穿
  • 布隆过滤器可以在访问Redis前返回结果,避免打到数据库

8. 点赞系统设计

• 问题:设计一个点赞系统,要求:
  1. 用户可以给文章点赞
  2. 进入文章详情知道有多少人点赞及我是否点过赞
  3. 作者知道有多少人给我点过赞 设计存储方案和表结构
• 回答:
  • 存储:MySQL持久化,Redis缓存
  • Redis用hash结构,key为"user_id|article_id",value为0/1表示是否点赞
  • MySQL表设计:
    • 用户表
    • 文章表
    • 点赞关联表(user_id、article_id、是否点赞)
  • 第三张表与Redis保持一致,每10分钟同步一次
  • 如果Redis挂掉,通过本地日志补偿机制恢复
• 追问:如何实现作者本人知道有多少人点赞
• 回答:文章表中有user_id字段,可以通过article_id关联找到作者

9. 日志文件最大同时在线人数

• 问题:日志文件记录用户登录登出时间(精确到秒),求:
  1. 全天最大同时在线人数
  2. 最大同时在线人数对应的持续时间段
• 回答:
  • 思路:行转列,把开始时间到结束时间拆分成每一秒
  • 统计每一秒有多少用户在线
  • 找到重复次数最多的时间点
  • 时间复杂度:O(logN) + O(N)
  • 面试官指出这个方案不够优化

10. 懂车帝业务介绍

• 问题:懂车帝主要做什么业务
• 回答:
  • 懂车帝有三个属性:选车(车型库)、买车(电商)、看车(内容)
  • 车型库和内容属于媒体阶段
  • 买车涉及经销商和电商
  • 该岗位偏向内容:内容发布、审核、模型特征处理、推荐算法、互动行为、作者生态
  • 懂车帝已独立,但基建还用字节的,公司独立但字节是大股东
  • 技术栈:Go语言 三、表现亮点
• 对Redis基础数据结构掌握较好,能结合实际项目说明使用场景
• 点赞系统设计思路清晰,考虑了缓存、持久化、补偿机制
• 对缓存一致性问题有正确的理解和方案
• 主动询问业务背景,展现对岗位的兴趣 四、不足与改进
• 对Redis大key问题理解不深,无法给出具体处理方案
• 千万级排行榜设计方案不完整,未考虑大key拆分
• 算法题思路不够优化,时间复杂度未达到最优
• 对布隆过滤器只有概念性了解,缺乏深入理解
• 点赞系统设计中,Redis挂掉的补偿机制描述不够清晰