前两天小伙伴面了个系统设计，题目直接一上来就给你来个“百万级 QPS 收藏系统”，说白了就是设计 Roblox 这种收藏/点赞的后端。这种题大家别一看以为简单，就什么 Redis + MySQL 一顿操作猛如虎，上来直接凉凉！

📚 面试题目长这样：

• 用户想知道某个商品自己有没有收藏（1M QPS）
• 用户可以收藏/取消收藏（100k QPS）
• 用户想看某个商品的总收藏数（1M QPS）
• （加分项）用户想看自己收藏了哪些商品（50k QPS）

直接大写加粗：读多写少的经典场景！

---

💡 面试官：你觉得这种系统最重要的是什么？

候选人直接不慌，先来一句：“先不说怎么设计，看到 1M QPS 的读请求就知道这系统必须是个读多写少，强烈依赖缓存的架构。”

这话一出，面试官脸色明显缓和，知道是个明白人了。

---

📝 数据库 Schema 怎么设计？

候选人一点不墨迹：

• UserFavorites 表
  • user_id (PK)
  • item_id (PK)
  • favorited_at
• ItemFavoriteCount 表（缓存总数）
  • item_id (PK)
  • favorite_count

就这两张表，读写需求全搞定了。你问事务一致性？对不起，我们追求最终一致性，强一致？不存在的！

---

📦 系统架构直接上图（这可是原汁原味面试白板图）：

候选人直接说：“面对这种高并发，缓存和异步批处理才是王道！”

• 用户操作先打到 Redis Cache，减少直接 DB 压力。
• 后台搞个 Batch Aggregator，每 5-10 分钟汇总一次，把 Redis 里的热数据慢慢写回数据库。
• S3 + Spark 日志分析，每天再来个大 reconciliation，防止长期累计误差。

---

🤔 面试官追问：那双写冲突、缓存不一致你怎么处理？

直接一句：“冷却时间 + 悲观锁 + 条件更新。”

• 前端直接加个按钮冷却时间，防止用户手速狂点。
• 后端 Redis 和 DB 写入搞个 CAS（Compare and Swap），有就更新，没有就新插入，别问为什么，问就是防脏数据。
• Redis 和 DB 同步写，保证持久化，Redis 真挂了也能从 DB 恢复。

---

🛠️ 扩展一波 Fault Tolerance：

• DB 直接用 DynamoDB，让 AWS 帮你搞定容灾复制。
• Redis 搞个主从，多活分区，写入先落盘，别光靠内存。
• Kafka 拉满消息持久化，消息至少保留 1 周，真的挂了还能翻日志回血。
• Prometheus + Grafana 全程监控，不怕宕机怕你不知道。

---

最后面试官直接表示，这种系统讲清楚缓存策略、异步批处理和最终一致性就已经很不错了。

经过csoahelp的面试辅助，候选人获取了良好的面试表现。如果您需要面试辅助或面试代面服务，帮助您进入梦想中的大厂，请随时联系我。

If you need more interview support or interview proxy practice, feel free to contact us. We offer comprehensive interview support services to help you successfully land a job at your dream company.