企业官网建设流程全解析

Java大厂面试实战：Spring Boot+Redis+Kafka电商高并发场景深度解析

最近这段时间很多朋友问我，大厂Java面试到底在考什么。说来说去，其实绕不开一个组合：Spring Boot + Redis + Kafka，而且面试官几乎都会把它们塞进同一个场景里——电商高并发。不是让你背八股文，而是给你一个真实业务场景，比如大促秒杀、订单峰值，然后问你缓存怎么做、消息队列怎么用、数据一致性怎么保证。这篇文章我就以电商高并发为主线，把这套技术栈的面试考点、底层原理和实操方案一次性讲透。不管是准备面试、还是在公司做系统设计，这套思路都能直接复用。

我尽量用大白话拆解，让你搞明白每个方案“为什么这么做”，而不是单纯背答案。内容涵盖Redis穿透/击穿/雪崩、缓存与数据库一致性、分布式锁、Kafka削峰填谷、顺序消费、消息不丢失等核心考点，最后还有大厂面试的速答思路和排查经验，信息量很大，建议收藏慢慢看。

1. 业务场景与课程整体思路拆解

1.1 电商高并发场景到底难在哪

先别急着聊技术，我们把问题定义清楚。电商系统里，高并发压力最典型的场景就是大促秒杀和热点商品抢购，比如某商品限量1000件，开售后10秒内有10万人同时点购买按钮。这时候系统面临的不是什么“慢一点”的问题，而是随时可能被打挂。

难点主要有四个层面，面试时你可以从这几个角度切入：

• 流量层面：瞬时QPS极高，数据库连接池根本扛不住，哪怕你上了连接池、读写分离，一个热点行更新就能把主库拖死。
• 数据层面：高并发下“读多写少”的特征非常明显，100次请求里可能99次都在查同样的商品信息、库存余量、活动配置，重复查数据库就是找死。
• 一致性层面：库存扣减必须准确，不能超卖；下单后支付回调、积分赠送、物流通知这些操作不能因为某个下游服务挂掉就全链路失败。
• 资源层面：系统资源（CPU、内存、带宽、连接数）是有限的，要保证在有限资源下扛住尽可能大的流量，必须做削峰、排队、分流。

明白了痛点，才能理解为什么要引入Redis和Kafka。Redis解决“读”的高并发，Kafka解决“写”的流量缓冲和异步解耦，Spring Boot则把这两者快速集成起来，形成一套完整的高并发处理骨架。

1.2 为什么用Redis扛读、用Kafka扛写

很多候选人把Redis和Kafka的选型理由说得支离破碎，面试官一问就露馅。这里我帮你把底层逻辑捋顺。

先看Redis。它是纯内存操作，单线程模型避免了并发竞争和上下文切换，官方数据是单实例QPS可以达到10万+，实际业务中压到5万-8万是很常见的。MySQL呢，单机读性能也就几千QPS，加从库以后读写分离能到上万，但跟Redis比还是差了一个数量级。所以电商系统里，商品详情、库存余量、用户购物车这些“读多写少”的数据，必须前置一层Redis做缓存。

再看Kafka。它是一个分布式的消息队列，核心能力是削峰填谷。比如订单创建接口峰值1万TPS，如果直接同步地调用优惠券服务、积分服务、短信服务、物流服务，任何一个下游抖动都会导致整个下单失败。引入Kafka后，订单服务只需把“订单创建成功”这个事件写入Kafka，下游服务各自订阅消息异步处理。相当于把一条笔直但狭窄的公路，改成了带缓冲区的高速入口，车再多也能慢慢消化。

Spring Boot在这里的作用就是胶水层，用starter的方式把RedisTemplate、KafkaTemplate集成进来，加上配置中心和监控手段，让你能快速把上述能力组装成微服务。面试时你可以把它理解为：Spring Boot解决“怎么快速落地”，Redis和Kafka解决“为什么能高并发”。

1.3 一套能贯穿始终的电商业务主链路

为了让后面的技术点不散，我建议所有面试回答都围绕一条主链路展开。比如：用户浏览商品 → 查询Redis缓存 → 缓存未命中则查数据库并回填缓存 → 用户点击购买 → 分布式锁控制库存扣减 → 扣减成功发送Kafka消息 → 下游服务异步处理订单后续流程。

这条链路几乎涵盖了所有核心考点，面试官问任何一环你都能快速定位上下文。我在模拟面试时经常告诉候选人，不要被动地“面试官问什么答什么”，而是主动把问题挂载到这条链路上，体现你有全局架构能力。后面所有的技术解析，我们也都基于这条主链路展开。

2. Redis缓存设计与高并发实战

2.1 缓存穿透、击穿、雪崩：一道送命题的完整解法

大厂面试Redis，几乎必问缓存三兄弟：穿透、击穿、雪崩。别只会背概念，一定要结合电商场景说解法。

缓存穿透：查询一个根本不存在的数据。比如用一个不存在的商品ID去查详情，缓存和数据库都没有，请求直接打到数据库。如果攻击者用大量不存在的ID循环请求，数据库瞬间就崩了。

我常用的解法有两个。第一个是缓存空值：即使数据库没有查到，也在Redis里写一个空值，过期时间设置短一点，比如60秒。这样后续同类请求直接命中空缓存，不会再打到数据库。第二个是布隆过滤器：把所有存在的商品ID预先放入布隆过滤器，请求进来先判断ID是否存在，不存在直接返回。布隆过滤器有误判率，但对“一定不存在”的判断是精确的，这点很适合拦截恶意请求。

缓存击穿：某个热点key在缓存过期的瞬间，大量并发请求同时穿透到数据库。这跟穿透的区别在于，击穿打的是“热点key”，穿透打的是“不存在的数据”。解法很经典：互斥锁（分布式锁）或者逻辑过期。

互斥锁的思路是：当缓存过期后，不是所有线程都去查数据库，而是让第一个线程获取分布式锁去查库并重建缓存，其他线程稍等片刻后重试读取缓存，从而保护数据库。逻辑过期则是缓存中不设置物理过期时间，而是存一个逻辑过期字段，查询时发现逻辑过期则开启异步线程重建缓存，请求先返回旧数据，体验上无限接近“无过期”。

缓存雪崩：大量key在同一时间集中过期，导致请求全部打到数据库。解法也比较固定：设置过期时间时加随机数，比如300秒加上0-60秒的随机值，避免集体过期；热点数据可以设置永不过期，由后台任务定时刷新；再加一层熔断和降级保护兜底。

我面试候选人时会追问一句：你们线上怎么优化过期时间的？如果你能说出“基础过期时间+随机偏移量”这样的细节，就能跟背概念的人拉开差距。

2.2 缓存与数据库双写一致性：先更库还是先删缓存

这是Redis面试里最容易引发争论的问题。电商场景中库存修改、商品信息更新都会触发缓存更新，一旦处理不好，用户会看到脏数据。

先给结论，主流方案是Cache Aside Pattern，也就是先更新数据库，再删除缓存。为什么不先更新缓存？因为数据库是数据的最终权威，缓存只是加速层，如果先更新缓存再更新数据库，数据库更新失败就会造成缓存与库不一致。而先更新库再删缓存，即使删缓存失败，还可以通过后续的“延迟双删”和消息队列兜底。

延迟双删是我强烈建议你掌握的一个技巧，操作顺序是：先删除缓存 → 更新数据库 → 休眠一小段时间（比如500ms）再删除一次缓存。为什么要删两次？因为并发场景下，A线程删完缓存后，B线程可能已经读了旧数据回填缓存，等A更新完数据库，这个旧缓存就成了脏数据。延迟二次删除可以把这种“漏网之鱼”清掉。

这里有个关键点：休眠时间怎么定？一般取值为业务的读耗时上限，比如你的业务查询耗时在50-200ms之间，休眠500ms通常就够了。这个细节面试官非常喜欢追问，你能讲出来说明你真的实践过。

2.3 Redis分布式锁在库存扣减中的应用

电商秒杀场景里，库存扣减是最容易超卖的地方。很多人第一反应是“加synchronized”，但那是单机锁，微服务多实例下根本没有用。正确的做法是用Redis分布式锁。

基于Redis实现分布式锁，核心是使用SET key value NX EX timeout命令，这个命令的原子性保证了同一时刻只有一个客户端能拿到锁。拿锁后执行库存扣减，执行完释放锁，释放前要校验value是否还是自己设置的唯一标识（防止误删别人的锁），用Lua脚本保证“检查+删除”的原子性。

更进阶的做法是使用Redisson框架，它提供了封装好的可重入锁，还内置了“看门狗”机制，可以自动续期。什么场景需要续期？如果你的业务执行时间超过了锁的过期时间，锁提前释放了，其他线程就能进入临界区，可能造成并发安全。Redisson的看门狗默认每10秒续期一次，把锁的存活时间拉长到30秒，避免锁提前失效。

我还遇到过很多候选人把分布式锁用得很重，所有写操作都加锁。其实没必要，锁的粒度要尽量小：不是锁整个下单接口，而是只锁“库存扣减”那几行代码。锁的时间也要尽量短：不要在锁内调用远程接口或做耗时操作，否则Redis连接被长时间占用，性能下降非常严重。

注意：Redisson默认的看门狗续期逻辑，如果业务里自己设置了leaseTime参数，看门狗就不会生效；所以如果你不确定业务耗时，建议别手动设置过期时间，让框架默认管理。

3. Kafka消息队列在高并发下的应用

3.1 削峰填谷：用Kafka把1万QPS变成平稳的2000 QPS

理解了Redis扛读，我们再来看Kafka怎么扛写。电商大促时，下单请求瞬间爆发，如果所有下游服务同步调用，链路中任何一个慢接口都会成为瓶颈。引入Kafka之后，订单服务把订单事件迅速写入消息队列，响应速度极快，下游消费者按照自己的处理能力去消费，这就叫削峰填谷。

有一个容易被忽略的细节是：Kafka为什么能撑住极高的写入吞吐？因为它充分利用了顺序写磁盘和Page Cache。Kafka的消息虽然落盘，但写的是追加日志文件，磁盘顺序写的速度可以接近内存随机写；再加上操作系统Page Cache的缓存加速，大部分写入实际是在内存中完成的。面试时能把这一层原理讲出来，比单纯说“Kafka性能好”要有说服力得多。

然后是生产者端的配置优化。电商场景里我会设置linger.ms和batch.size，让消息在缓冲区攒一批再发，提升吞吐；acks级别通常设置为all，保证分区副本都写入成功后再返回，防止消息丢失。这些参数都是面试官喜欢追问的点，你可以把选择和理由串起来讲。

3.2 消息不丢失：生产者、Broker、消费者三端分别怎么做

Kafka的可靠性是个经典考点，面试官问“Kafka如何保证消息不丢失”时，你要分三端来答。

生产者端：设置acks=all，表示Leader和所有ISR副本都写入成功才算成功；同步发送时捕获异常并做重试；异步发送时定义回调函数，失败时记录日志或转入其他投递机制。还有一点，retries要设置为大于0的值，避免网络抖动导致发送失败。

Broker端：设置min.insync.replicas=2，意思是至少有两个副本同步完成才返回成功；这两个参数要和acks=all配合使用，单独设置任何一个都保证不了不丢消息。Topic的replication.factor至少设置为3，副本分布在不同的Broker上，单点宕机不影响数据。

消费者端：这是最容易丢消息的地方。核心是关闭自动提交位移，也就是enable.auto.commit=false，改为处理完业务逻辑后再手动提交offset。道理很简单，如果先提交了offset，再处理消息过程中程序挂掉了，这部分消息就永远消费不到了。手动提交时我习惯用同步提交加失败重试，确保提交成功。

补充一个幂等性设计。消息不丢失不代表业务不重复，Kafka的at-least-once语义下，消费者可能收到重复消息。下单场景中，重复消费“发放优惠券”就会给用户发两次。解法是让消费逻辑具备幂等性：在业务表里加唯一订单号约束，或使用Redis的SETNX做去重。面试时如果你能把“不丢失”和“幂等”分开讲，说明你理解得足够深。

3.3 顺序消费与消息积压的排查方案

顺序消费也是高频考点。比如电商中“创建订单→支付成功→发货”这三条消息，必须按照顺序处理，如果支付成功先被消费，而订单创建还没处理完，业务上就乱套了。

Kafka保证顺序消费的基本条件是：同一个业务key的消息进入同一个分区，并且一个分区只能被同一个消费者组里的一个消费者消费。具体做法是在生产者发送时根据订单ID做key，比如KeyedMessage<>(topic, orderId, message)，Kafka会根据key的哈希值选择分区，这样同一个订单的所有消息都进了同一个分区。消费者端同一个分区在一段时间内只被一个线程处理，自然就保证了顺序。

但高并发下，顺序消费会牺牲吞吐，因为同一分区没法并行处理。折中方案是：把顺序性要求很高的消息（如订单状态流转）单独放到一个topic、使用单分区，把顺序性要求不高的消息（如短信通知）放到多分区并行消费。

消息积压是线上非常头疼的问题，面试也会问。现象是消费速度跟不上生产速度，Kafka的Lag（消费滞后量）持续增大。排查思路从这几步走：

1. 先看消费者是否挂掉，进程没了当然不消费。
2. 再看消费者是否有异常导致一直重试，比如消费逻辑里抛出未捕获异常，导致消息反复消费失败。
3. 然后看下游依赖是否变慢，比如消费消息后要调用外部API，外部服务超时导致整体吞吐下降。
4. 最后看分区数是不是不够，分区数决定了最大并行度，消费能力上不去就扩容分区和消费者实例。

如果是临时积压且业务允许，最快的恢复手段是临时增加消费者实例，让每个实例分担更少的分区；或者启动一个临时的“清扫消费者”只做转发，把积压消息转发到新的topic，再用多消费者并行处理。注意临时扩容只能缓解，根治还是要优化消费逻辑。

4. Spring Boot集成Redis与Kafka的实操细节

4.1 环境准备与版本选择建议

开始写代码之前，先把环境准备好。开发机建议用Docker快速拉起Redis和Kafka，避免本地装软件踩坑，比如用docker run -d -p 6379:6379 --name redis redis:7启动Redis，Kafka则建议用docker-compose同时启动Zookeeper和Kafka容器。线上生产环境请使用Kafka集群，至少3个Broker，同时开启SASL认证，避免端口裸奔。

Spring Boot集成这块，版本选择很关键，不然会出现各种莫名其妙的不兼容问题。我目前比较稳的组合是：

• Spring Boot 2.7.x 或 3.x（JDK 17）
• Redis客户端使用Spring Data Redis默认的Lettuce
• Kafka客户端使用Spring Kafka 3.x

如果你用的是Spring Boot 3，记得关注javax到jakarta的包名变更，很多老教程的代码是跑不起来的。

注意：Spring Boot 3.x 对Java版本要求是17+，如果你的生产环境还是JDK 8，选Spring Boot 2.7系列更合适，不要盲目追求新版本。

4.2 基于Spring Boot的缓存实操

下面给出一段可以直接抄作业的代码。先配置好RedisTemplate，指定序列化方式，否则用默认的JDK序列化会出现一堆乱码问题：

@Configuration public class RedisConfig { @Bean public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) { RedisTemplate<String, Object> template = new RedisTemplate<>(); template.setConnectionFactory(factory); // key使用String序列化 StringRedisSerializer stringSerializer = new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jacksonSerializer = new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); // value使用JSON序列化 template.setValueSerializer(jacksonSerializer); template.setHashValueSerializer(jacksonSerializer); template.afterPropertiesSet(); return template; } }

然后写一个缓存工具类，封装查询操作，核心是“缓存未命中时的互斥回填”：

@Service public class CacheService { @Resource private RedisTemplate<String, Object> redisTemplate; public Object queryWithMutex(String key, long expire, Callable<Object> dbLoader) { Object value = redisTemplate.opsForValue().get(key); if (value != null) { return value; } // 使用分布式锁，只允许一个线程查库回填 String lockKey = key + ":lock"; String requestId = UUID.randomUUID().toString(); boolean locked = Boolean.TRUE.equals(redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, 5, TimeUnit.SECONDS)); if (locked) { try { value = redisTemplate.opsForValue().get(key); if (value != null) { return value; } value = dbLoader.call(); redisTemplate.opsForValue().set(key, value, expire, TimeUnit.SECONDS); return value; } catch (Exception e) { throw new RuntimeException(e); } finally { // 释放锁，校验持有者 String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end"; DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>(script, Long.class); redisTemplate.execute(redisScript, List.of(lockKey), requestId); } } else { // 没拿到锁，短暂休眠后重试，让拿到锁的线程完成缓存重建 try { Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return redisTemplate.opsForValue().get(key); } } }

这套代码就是互斥锁解决缓存击穿的落地实现。面试时你如果能随手写出类似的代码结构，并且解释清楚Lua脚本的原子性，一定是加分项。

4.3 基于Spring Boot的Kafka消息收发实操

Spring Kafka的用法比较简单。第一步在application.yml里配置：

spring: kafka: bootstrap-servers: localhost:9092 producer: key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.springframework.kafka.support.serializer.JsonSerializer acks: all retries: 3 properties: linger.ms: 5 batch.size: 16384 consumer: group-id: order-group key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer enable-auto-commit: false auto-offset-reset: latest properties: spring.json.trusted.packages: "*"

第二步写生产者和消费者。生产者非常简单，注入KafkaTemplate后直接发送：

@Service public class OrderEventPublisher { @Resource private KafkaTemplate<String, Object> kafkaTemplate; public void publishOrderCreated(OrderEvent event) { // 以订单ID作为key，保证同一订单消息进入同一分区 CompletableFuture<SendResult<String, Object>> future = kafkaTemplate.send("order-events", event.getOrderId(), event); future.whenComplete((result, ex) -> { if (ex == null) { log.info("消息发送成功: topic={}, partition={}, offset={}", result.getRecordMetadata().topic(), result.getRecordMetadata().partition(), result.getRecordMetadata().offset()); } else { log.error("消息发送失败: {}", event.getOrderId(), ex); } }); } }

消费者要特别处理“手动提交offset”和“幂等消费”。下面的代码是核心模板：

@Component public class OrderEventConsumer { @KafkaListener(topics = "order-events", groupId = "order-group") public void onOrderEvent(ConsumerRecord<String, OrderEvent> record, Acknowledgment ack) { try { String orderId = record.key(); OrderEvent event = record.value(); // 幂等判断：Redis里setnx，成功则处理，失败说明已处理过 Boolean first = redisTemplate.opsForValue() .setIfAbsent("order:consumed:" + orderId, "1", 1, TimeUnit.DAYS); if (Boolean.FALSE.equals(first)) { // 已经消费过，直接提交offset ack.acknowledge(); return; } // 处理业务：调用优惠券服务、发送短信等 handleBusiness(event); // 业务处理成功后再提交offset ack.acknowledge(); } catch (Exception e) { // 记录异常，稍后批量重试，避免一直卡在单条消息上 log.error("消费订单事件失败, orderId={}", record.key(), e); } } }

这段代码你在面试时可以重点强调：先做幂等判断，再处理业务，最后提交offset。如果处理失败就不要提交offset，让消息在下次poll时再次被拉到，但前提是你要有配套的重试次数控制和死信队列，防止一条坏消息卡死整个分区。

4.4 一套高并发压测验证的闭环思路

技术方案写完了，不能光靠“我觉得可以”，要能拿出来验证。大厂面试官很喜欢问“你怎么验证你的系统能扛住高并发”，你如实回答用JMeter、压测脚本、监控大盘做验证，有理有据即可。

我给的实操建议是：用JMeter构造一个秒杀场景脚本，设置线程数从100逐步升到5000，观察三个关键指标：接口响应时间P99、错误率、系统吞吐量TPS。同时配合Redis的INFO命令和Kafka的kafka-consumer-groups.sh --describe命令监控缓存命中率和消费Lag，确保压测过程中缓存命中率不低于95%、Kafka Lag不持续增长。

具体指标可以参考这样一个基线：查询接口P99不超过200ms，下单接口P99不超过500ms，错误率低于0.1%，TPS达到3000以上。如果压测发现系统在1500 QPS时数据库连接池被打满，基本可以推断是缓存命中率不够或者Kafka消费者消费能力不足，逐项排查，形成闭环优化后再压测一轮。这个过程不仅面试能用，实际接线上容量评估的时候同样有效。

5. 高并发场景面试题速答与实战总结

5.1 八股文必考点：Redis与Kafka高频面试题速答

我在模拟面试时整理了一套高频题目，这里挑最具代表性的几道给出速答思路，你可以作为备考清单。

Redis为什么快？答：纯内存操作避免磁盘IO；单线程模型避免锁竞争和上下文切换；IO多路复用机制（epoll）支撑海量连接；高效的数据结构编码。

Redis持久化RDB和AOF怎么选？答：RDB是定时快照，恢复快但可能丢数据；AOF记录操作日志，数据更完整但文件大、恢复慢。生产环境建议两者结合，RDB做主备同步，AOF做数据恢复兜底。

Kafka为什么吞吐量高？答：顺序写磁盘；Page Cache加速；生产者批量发送与压缩；消费者顺序读；分区并行扩展。

Kafka和RocketMQ怎么选？答：Kafka吞吐更高、生态更丰富，适合日志采集和削峰填谷；RocketMQ自带事务消息、延迟消息、消息轨迹，更适合核心交易链路。面试时能讲出这种区别，说明你不是只会用一个。

Redis集群模式下分布式锁还能用吗？答：Redis Cluster下主节点故障会导致锁丢失，严格用RedLock或ZooKeeper实现。但RedLock本身有争议，业界普遍做法是接受极低概率的锁丢失风险，或者用强一致组件（etcd、ZK）兜底。

5.2 常见问题与排查技巧实录

线上问题排查是最能体现经验的部分，下面整理几个我踩过或者帮别人排查过的真实案例。

案例一：热点缓存失效，数据库打挂。现象是秒杀开始后数据库CPU瞬间飙到100%，检查Redis发现热点商品的缓存key在秒杀开始的同一刻过期。原因是设置过期时间时用了固定值，所有key同一秒过期，同时大批请求穿透到数据库。解决：过期时间加随机数，热点key设置永不过期，后台定时刷新。

案例二：Kafka消费者频繁Rebalance，消费吞吐骤降。现象是消费组日志里频繁出现rebalance，消费速率降到原来的十分之一。排查发现消费者处理单条消息耗时太长，超过了max.poll.interval.ms默认的5分钟，消费者会话超时被踢出分组，触发重平衡。解决：调大max.poll.interval.ms和max.poll.records，或者优化单条消费逻辑，让每次poll后能快速处理完再拉取下一批。

案例三：Redis连接池被耗尽。现象是应用频繁报Cannot get Jedis connection。排查发现某个接口在循环里调用Redis查询，每次查询都新建连接，没有使用连接池。解决：统一使用Lettuce连接池，设置合理的maxTotal和maxIdle，同时在代码里避免循环请求Redis，尽量用pipeline批量获取。

案例四：缓存与数据库数据不一致，用户看到旧库存。现象是后台修改库存后，前端偶尔展示的还是老库存。排查发现使用的是“先更新缓存、再更新数据库”的操作顺序，数据库更新失败后缓存已经是新值，库里还是老值。解决：切换到Cache Aside Pattern，先更新库再删缓存，并加上延迟双删兜底。

5.3 冲刺大厂的一些个人经验参考

最后聊几句实在的。根据我这些年面试别人和参加面试的体会，大厂面试官对高并发场景的考察，根本不是考你背了多少八股文，而是看你能不能把技术点落到真实业务里。你说出了“缓存穿透”的概念只能得一分，能说出“布隆过滤器+缓存空值”得两分，能说出“缓存空值设置多长过期时间、布隆过滤器误判率怎么调、穿透流量怎么限流”才能得满分。

我的建议是：把所有知识点都挂到一条业务链路上来记忆和表达，就是我们前面说的那条“浏览商品→查缓存→扣库存→发Kafka消息→异步处理”。面试时不管对方从哪个点切入，你都从这条链路出发，把上下文交代清楚，然后再展开细节，这样给面试官的感觉就是一个真正做过电商高并发项目的人，而不是一个背题机器。

再分享一个小技巧：面试前自己对着录音工具讲一遍“请介绍一个你负责的高并发项目”，讲完再听回放，你会发现大量“嗯嗯啊啊”和逻辑断层。把这些卡壳的地方打磨顺畅，比多刷100道题都管用。高并发没有银弹，但把这些基础组件吃透、把业务链路想清楚，你已经能超过大多数候选人了。