大家发现了吧现在面试八股文好像问的少了反倒是场景题多了起来毕竟现在AI如此强大总揪着这点底层基础也没多大意思。面试官张嘴闭嘴高并发、大数据量倒是真的别管实际业务是不是高并发但是你不会是进不来拧螺丝的。就像之前有同学被问“某音百万用户同时给一个视频点赞让你来要怎么设计”这类题肯定见过吧。咱们来简单拆解下这题我是一个小学生知识量有限不喜勿喷。这道题到底考察什么别上来就想用什么技术先明确面试官的考察点才能答到点子上高并发写入能力百万人同时操作瞬间 QPS 能冲到几十万如何避免数据库被打垮这是考察你对流量削峰的理解数据一致性用户点赞后必须立刻看到已赞状态点赞数可以有轻微延迟但不能错、不能丢这是对最终一致性的考察系统可用性就算后端服务波动用户点赞操作也得成功不能出现点了没反应的情况考察容错和降级思路资源优化百万次请求直接怼数据库肯定不行如何用缓存、消息队列等中间件减轻压力考察技术选型能力。换位思考很多人一上来就纠结怎么让百万次点赞实时写入数据库其实跑偏了。咱们站在用户角度想用户点击点赞后最关心的是有没有点赞成功而不是当前赞数到底是 10086 还是 10087赞数是给所有用户看的公共数据轻微延迟用户完全感知不到就算数据丢了用户也很难发现只是会想“咦”我之前点赞过一个视频没了就没然后了核心需求是操作成功率 99% 客户端状态实时反馈 赞数最终准确。想通这一点方案就清晰了把实时写入数据库的压力转移到中间件上用异步 缓存的思路解决高并发。选取方案咱们一步步拆解从用户点击点赞按钮开始整个流程是这样的1. 用户点赞先写消息队列客户端直接反馈成功用户点击点赞的瞬间客户端不会直接调用数据库接口而是做两件事向后端发送点赞请求后端收到后不操作数据库直接把用户ID 视频ID 点赞状态赞 / 取消赞封装成一条消息写入 KafkaReids 记录 用户ID 视频ID 的点赞状态增加 视频ID 的赞数量只要消息成功写入 Kafka后端就立刻返回点赞成功给前端客户端马上显示已赞状态。为啥选 Kafka 我就不说了。2. 客户端本地记录状态避免重复点赞客户端收到点赞成功后除了显示已赞还要在本地存储记录当前用户对该视频已点赞。这样做的好处是防止用户短时间内重复点击点赞前端直接拦截减少无效请求就算后续缓存没更新用户自己看到的状态也是准确的不影响个人体验。3. 查赞数直接读 Redis不用查数据库其他用户查看视频时需要显示赞数这时候客户端会调用查询赞数接口后端的处理逻辑是不查数据库直接从 Redis 里读取该视频的赞数缓存Redis 读性能极高支持每秒几十万次查询完全能扛住百万用户同时查看的压力这里的赞数可能不是实时最新的但只要延迟在可接受范围内用户完全没感觉。4. 后台任务定时同步 Redis 和数据库保证最终一致这一步是兜底负责把 Kafka 里的点赞消息处理掉同时更新 Redis 和数据库后端持续从 Kafka 里拉取点赞消息启动一个定时任务把 Redis 里所有视频的赞数批量同步到数据库里同步时要注意幂等性比如用户先赞后取消最终状态是未赞避免重复计算导致赞数错误。批量同步攒一批数据比如 1 万条再批量更新大大减少数据库的写入压力。而且定时任务可以根据业务调整频率比如高峰期每 1 分钟同步一次低峰期每 10 分钟同步一次灵活适配流量。方案优势这套方案没有复杂的架构但的确能解决百万级点赞的高并发问题核心优势在于几种中间件的组合使用高可用Kafka 保证消息不丢失Redis 保证查询不卡顿就算数据库暂时挂了用户点赞和查赞数都不受影响易扩展如果后续点赞量涨到千万级只需要增加 Kafka 的分区数、Redis 的集群节点就能轻松扛住低成本不用复杂的分布式事务不用实时计算框架用最基础的中间件就能实现开发和维护成本都低。写在最后其实很多高并发场景比如点赞、评论、秒杀核心思路都是异步解耦 缓存兜底。面试官考察的不是你知道多少冷门技术而是你能不能看透问题本质用户要的是体验和成功不是实时准确。不过这套方案看似简单但覆盖了 “削峰、缓存、异步、最终一致性” 等核心考点面试时把这个逻辑讲清楚再结合 Kafka 的消息可靠性、Redis 的高性能、定时任务的批量处理面试官起码会觉得你懂行。如果实际业务中赞数延迟要求极高比如直播场景需要实时显示赞数也可以把定时同步改成 Kafka 消费后实时更新 Redis数据库异步同步本质还是换汤不换药