互联网大厂 Java 面试实战：一次“高并发系统追问”下的真实对话

在大多数 Java 面试中真正拉开差距的从来不是“你会多少知识点”而是当系统出现问题时你是否知道该怎么扛。很多候选人熟悉各种八股文但一旦进入场景题就会卡住。下面通过一场更贴近真实大厂风格的面试对话式还原一个高并发系统设计与追问的全过程。这场面试的主角是Like不过这一次他面对的不是基础考察而是一场逐步深入的系统追问。面试开始。面试官我们现在有一个内容社区首页接口在高峰期 QPS 能到 5 万你来设计一下这个接口。Like这个接口我不会直接从数据库查数据而是会分层设计。首先是接口层提供一个统一的 feed 接口对外屏蔽内部复杂逻辑。这个接口内部会做数据聚合比如推荐内容、热门内容和广告内容。然后是缓存层首页数据一定是优先走缓存尤其是热点内容我会放在 Redis 里并且根据用户维度做一定的拆分避免所有请求打到同一个 key 上。最后是降级策略如果推荐服务不可用我会直接降级返回热门数据保证接口可用性。面试官如果缓存扛不住呢比如 Redis 出现问题Like我不会把 Redis 当成唯一依赖。首先会做 Redis 集群比如主从加哨兵避免单点问题。其次会加一层本地缓存比如使用 Guava 做热点数据兜底。如果 Redis 整体不可用请求会被限流防止直接打到数据库把数据库压垮。面试官那你刚刚提到缓存那缓存常见问题你怎么解决比如缓存穿透Like缓存穿透一般是请求不存在的数据比如恶意构造 userId。解决方式有两种一种是用布隆过滤器在入口处拦截非法请求另一种是对查询为空的结果做短时间缓存避免反复打数据库。面试官那缓存击穿呢Like缓存击穿是热点 key 在某一时刻失效比如一个明星发布内容瞬间流量暴涨。解决方案可以是对热点 key 加互斥锁保证只有一个线程去加载数据其它线程等待或者在缓存过期前通过定时任务提前刷新。面试官缓存雪崩呢Like缓存雪崩通常是大量 key 同时过期。我会在设置过期时间时加随机值让 key 分散过期同时可以设计多级缓存比如本地缓存加 Redis进一步降低风险。面试官好那我们再往下走。如果现在要把这个系统拆成微服务你会怎么做Like我不会一开始就拆而是先判断是否真的需要微服务。如果系统规模和团队规模还不大单体应用加模块化反而更稳定。如果确实需要拆我会按照业务边界划分服务比如用户服务、内容服务、推荐服务而不是按数据库表拆。面试官服务之间怎么通信Like同步调用我会用 OpenFeign适合查询类接口。异步场景我会用消息队列比如 Rocketmq用来做削峰填谷和服务解耦比如用户发帖后通过消息队列异步更新推荐系统。面试官那数据一致性怎么保证Like在分布式系统里我不会追求强一致性而是采用最终一致性。常见方案是数据库写成功后发送消息其他服务消费消息更新数据。为了避免消息丢失我会增加本地消息表确保消息一定能发送出去。面试官如果消息重复消费怎么办Like需要做幂等设计比如每条消息带唯一 ID在消费端做去重可以通过数据库唯一索引或者专门的去重表来实现。面试官如果消息丢了呢Like我会设计多层保障机制。第一是生产者发送消息时要有确认机制确保消息到达队列第二是消费端失败要支持重试第三是增加定时任务做数据对账如果发现数据不一致再进行补偿。面试官如果数据库也扛不住了呢Like那说明已经到系统瓶颈了。我会从几个方向优化。首先是读写分离把读流量分散到从库。其次是分库分表按用户 ID 或业务维度拆分数据。再进一步可以做热点数据缓存、接口限流以及降级非核心功能优先保证核心链路。面试官好的这一轮可以了后面会有同事再和你聊。这场面试看似只是几个问题但本质是在考察一个能力你是否具备“系统思维”。普通候选人往往停留在“会用什么技术”而更优秀的候选人会思考“系统出问题时怎么办”。