互联网大厂 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 或业务维度拆分数据。再进一步可以做热点数据缓存、接口限流，以及降级非核心功能，优先保证核心链路。

面试官：好的，这一轮可以了，后面会有同事再和你聊。

这场面试看似只是几个问题，但本质是在考察一个能力：你是否具备“系统思维”。普通候选人往往停留在“会用什么技术”，而更优秀的候选人会思考“系统出问题时怎么办”。