1. 电商场景下的Java技术栈全景解析
最近帮一位准备大厂面试的朋友复盘电商项目，发现很多候选人对"技术栈"的理解停留在框架名称的堆砌。实际上，大厂面试官更关注技术选型与业务场景的契合度。以典型电商系统为例，我们拆解下真实场景中的技术决策逻辑。
电商系统的核心特征是"三高"：高并发、高可用、高一致性。这决定了技术栈的选型方向：
- Spring Boot作为基础框架：其自动装配特性快速搭建微服务，Starter机制完美适配电商模块化需求（如支付Starter、库存Starter）
- Redis的5种使用姿势：缓存、分布式锁、秒杀队列、会话存储、实时统计，不同场景需要选择不同的数据结构和持久化策略
- 分库分表组件选型：ShardingSphere与MyCat的抉择关键在SQL兼容性需求
- 消息中间件的场景化选择：订单事务用RocketMQ、日志处理用Kafka、延迟消息用RabbitMQ
技术栈不是越新越好，某跨境电商曾因盲目上马Service Mesh导致库存计算延迟，最终回退到Spring Cloud
1.1 商品服务的架构演进
商品详情页的架构变迁最能体现技术栈的进化：
- 单体时代：JSP+MySQL，面临的主要是Tomcat线程池打满问题
- 缓存时代：Redis+本地缓存，需解决缓存穿透（布隆过滤器）与数据一致性（双删策略）
- 静态化时代：Nginx+CDN，配合Ajax加载动态内容
- 服务化时代：商品基础数据、价格、库存拆分为独立服务，面临分布式事务挑战
- 智能化时代：基于用户画像的千人千面推荐，引入TensorFlow Serving
// 典型的多级缓存实现 public ProductDetail getProduct(Long id) { // 1. 查本地缓存 ProductDetail detail = localCache.get(id); if(detail != null) return detail; // 2. 查Redis detail = redisTemplate.opsForValue().get("product:"+id); if(detail != null) { localCache.put(id, detail); return detail; } // 3. 查数据库（防穿透） detail = productMapper.selectById(id); if(detail == null) { redisTemplate.opsForValue().set("product:"+id, null, 5, TimeUnit.MINUTES); } else { redisTemplate.opsForValue().set("product:"+id, detail, 30, TimeUnit.MINUTES); } return detail; }1.2 交易系统的技术难点
订单创建流程看似简单，实则暗藏玄机：
- 分布式锁：防止重复提交，关键要设置合理的锁粒度（用户维度而非订单维度）
- 库存扣减：采用Redis Lua脚本保证原子性，注意超卖和少卖两种异常情况
- 分布式事务：TCC模式比Saga更适合资金操作，但开发成本更高
- 降级策略：当风控系统响应超时，是阻断交易还是放行？需要根据业务阶段动态调整
某次大促中，我们发现Redis集群的hot key导致库存扣减延迟，最终通过本地缓存+Redis分片解决
2. 高频面试题深度剖析
2.1 Redis缓存击穿实战方案
面试官常问："你们的缓存击穿解决方案是什么？" 多数人回答"用互斥锁"，但大厂期待更立体的回答：
预防阶段：
- 热点数据预加载：通过历史访问数据预测，提前写入缓存
- 多级缓存架构：本地缓存+分布式缓存，本地缓存设置不同的过期时间
应对阶段：
- 互斥锁的优化：采用Redis的SETNX实现，注意设置合理的锁超时时间
- 缓存空对象：对不存在的key也缓存，防止反复查询数据库
- 熔断机制：当缓存失效请求超过阈值，直接返回默认值
// 改进版的缓存查询 public Product getProductWithLock(Long id) { String lockKey = "lock:product:" + id; try { // 尝试获取锁 while (!redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS)) { Thread.sleep(100); } // 查缓存 Product product = getFromCache(id); if (product != null) return product; // 查数据库 product = dbQuery(id); if (product != null) { updateCache(id, product); } else { // 缓存空对象 redisTemplate.opsForValue().set("product:"+id, null, 5, TimeUnit.MINUTES); } return product; } finally { redisTemplate.delete(lockKey); } }2.2 分布式ID生成方案对比
电商场景下，订单ID的生成方式直接影响系统性能：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| UUID | 简单，无中心化 | 无序，索引效率低 | 日志系统 |
| 数据库自增 | 绝对有序 | 单点故障，性能瓶颈 | 小型系统 |
| Redis INCR | 性能较好 | 持久化问题 | 临时活动 |
| 雪花算法 | 高性能，趋势递增 | 时钟回拨问题 | 主流电商系统 |
| 美团Leaf | 高可用，可监控 | 架构复杂 | 大型分布式系统 |
在日订单量百万级的系统中，我们采用改良版雪花算法：
- 时间戳部分改用业务日期而非机器时间，避免时钟回拨
- 工作进程ID通过ZK动态分配，支持容器化部署
- 序列号部分增加随机前缀，防止被爬虫推测订单量
3. 系统设计题应答策略
3.1 秒杀系统设计要点
当面试官要求设计秒杀系统时，建议按照以下结构回答：
架构分层：
- 前端：静态资源CDN化，按钮灰度+倒计时随机偏移
- 网关：限流（令牌桶）、黑名单（Redis HyperLogLog）
- 服务层：库存预热、内存标记+Redis原子扣减
- 数据层：MQ削峰填谷，最终一致性
关键实现：
// 秒杀核心逻辑 public boolean seckill(Long userId, Long itemId) { // 内存标记过滤无效请求 if(!itemCache.containsKey(itemId)) { return false; } // Redis原子扣减 String stockKey = "seckill:stock:" + itemId; Long remain = redisTemplate.opsForValue().decrement(stockKey); if(remain < 0) { // 回滚库存 redisTemplate.opsForValue().increment(stockKey); return false; } // 异步创建订单 mqTemplate.send("seckill_order", new OrderMessage(userId, itemId)); return true; }容灾方案：
- 降级策略：当Redis不可用时切换本地库存（需要提前分配库存额度）
- 熔断配置：Hystrix线程池隔离，避免雪崩
- 数据核对：定时任务补偿丢失的订单
3.2 分布式事务场景题
"如何保证购物车清空和订单创建的一致性？"这类问题考察TCC模式的掌握：
Try阶段：
- 购物车服务：锁定选中的商品（状态改为"待结算"）
- 订单服务：预生成订单号，冻结优惠券
Confirm阶段：
- 购物车服务：删除锁定的商品
- 订单服务：正式创建订单，扣减优惠券
Cancel阶段：
- 购物车服务：解除商品锁定
- 订单服务：释放优惠券
实际编码中要注意幂等性设计，Confirm/Cancel可能被重复调用
4. 性能优化实战技巧
4.1 JVM调优电商场景实践
电商系统的JVM参数需要特别配置：
- 年轻代大小：根据订单创建频率调整，高峰期需要更大Eden区
- 垃圾收集器：CMS已淘汰，G1更适合大堆内存场景
- 关键参数示例：
-Xms4g -Xmx4g -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=35 -XX:+UseG1GC -XX:MaxMetaspaceSize=512m
典型问题排查流程：
- 通过jstat -gcutil观察GC频率
- 使用jmap -histo定位内存泄漏对象
- 用arthas的trace命令分析接口耗时
4.2 MySQL查询优化案例
商品搜索接口的优化过程：
原始SQL：
SELECT * FROM products WHERE title LIKE '%手机%' ORDER BY sales DESC LIMIT 100;问题：全表扫描+filesort
第一阶段优化：
- 添加联合索引(category_id, sales)
- 改为分品类查询
终极方案：
- 使用Elasticsearch实现搜索
- MySQL只存储基础信息
- 通过canal实现数据同步
5. 面试中的项目陈述技巧
5.1 STAR法则的进阶用法
不要简单复述项目功能，要突出技术决策：
- Situation：日均订单量10万→100万的瓶颈是什么？
- Task：需要将接口响应时间从500ms降到200ms
- Action：引入Redis集群+本地缓存，而非简单地扩容服务器
- Result：不仅提升性能，还节省了30%的服务器成本
5.2 技术深挖应对策略
当面试官追问"为什么选择RabbitMQ而不是Kafka"时：
- 业务场景：需要延迟消息（订单超时关闭）
- 数据量级：日均百万消息，RabbitMQ足够
- 团队因素：已有RabbitMQ运维经验
- 扩展考量：插件机制支持动态扩缩容
最后分享一个真实案例：在解释CAP理论时，有位候选人用电商库存作为例子："在618大促时，我们选择AP而非CP，允许短暂超卖，后续通过补货和补偿券解决，这比直接拒绝用户体验更好"。这种业务结合理论的回答往往能获得加分。
