文章标题：大厂Java面试实录：Spring Cloud微服务架构下的高并发电商场景实战
文章内容：
面试现场：会议室里，面试官看着小王的简历，点了点头。
第一轮：微服务架构设计
面试官：小王，看你简历里有个电商项目，如果让你用Spring Cloud做微服务拆分，你会怎么设计？
小王：我会按领域拆分，比如用户、商品、订单、支付服务。用Nacos做注册配置中心，Spring Cloud Gateway做网关，OpenFeign做服务调用。
面试官：服务发现和负载均衡怎么实现？
小王：服务启动注册到Nacos，OpenFeign整合Ribbon做客户端负载均衡。流量大时，我会用Resilience4j做熔断降级。
面试官：不错，有实践经验。那假设促销时QPS暴涨，你怎么快速扩容？
小王：我会用K8s部署，配合HPA根据CPU阈值自动扩容Pod。数据库层用读写分离，Redis缓存热点商品数据。
面试官：思路很清晰。
第二轮：高并发场景应对
面试官：如果缓存雪崩了，你怎么处理？
小王：预防为主，Redis集群+哨兵，过期时间加随机值。还可以用Caffeine做本地二级缓存。
面试官：下单后库存扣减，怎么保证最终一致性？
小王：用RocketMQ的事务消息。先发半消息，本地事务（扣库存）成功后再提交消息，消费者监听消息更新缓存。
面试官：如果用户付款后订单状态没同步怎么办？
小王：我会用定时任务+状态补偿机制，或者基于RocketMQ的延迟消息做重试。
面试官：考虑得比较全面。
第三轮：数据库与优化
面试官：订单表数据量很大，查询慢，你怎么优化？
小王：先加索引，比如用户ID和创建时间。如果还慢，考虑分库分表，用ShardingSphere按用户ID哈希分片。
面试官：分表后，怎么做跨分页查询？
小王：可以冗余数据到ES，用ES做聚合查询。或者用ShardingSphere的广播表存冗余信息。
面试官：最后，你怎么保证分布式事务的一致性？
小王：强一致性用Seata AT模式，弱一致性用消息队列+本地消息表。实际电商常用后者，保证最终一致性。
面试官：今天的面试就到这，你回去等通知吧。
问题详解（针对关键问题展开，供初学者参考）：
-
缓存雪崩解决方案
场景：促销瞬间大量缓存同时失效，请求直打数据库导致宕机。
技术点：
- Redis集群+哨兵实现高可用。
- 缓存过期时间加随机值（如30分钟+随机5分钟），避免同时失效。
- 本地缓存（Caffeine）作为二级缓存，减少Redis压力。
- 热点数据永不过期，后台异步更新。
-
订单库存最终一致性
场景：用户下单扣库存，需保证缓存、数据库、订单状态一致。
技术点：
- 采用RocketMQ事务消息：生产者先发半消息，执行本地事务（扣MySQL库存），成功则提交消息。
- 消费者监听消息，更新Redis库存缓存。
- 失败时通过RocketMQ回查机制重试，保证最终一致。
-
分库分表与查询优化
场景：订单表超千万，按用户ID查询仍慢。
技术点：
- 用ShardingSphere分表：按用户ID哈希分16个表，分片键需避免热点。
- 跨分页查询优化：将订单数据同步到Elasticsearch（通过Canal监听binlog），复杂查询走ES。
- 冗余维度表：如商品信息作为广播表，避免跨库关联。
文章标签：Java,Spring Cloud,微服务,高并发,Redis,Kafka,分库分表,面试题,电商场景
文章简述：本文模拟互联网大厂Java面试，围绕电商高并发场景，从微服务架构设计、缓存雪崩应对，到分库分表优化，层层深入。附详细技术解析，帮助初学者掌握实战核心。
