家具网络营销系统实战，面试必问的避坑指南

报错一堆看不懂 StackTrace？别慌，这是很多刚接手项目的人都会遇到的噩梦。尤其是当面试官在技术面里抛出这个场景，问你怎么排查时，如果你只能回答“重启试试”，基本就凉半截了。这种场景在【家具网络营销】这种涉及高并发库存扣减的业务里，简直是面试必问的高频考点。

今天咱们不聊虚的，直接上一个能跑通的【家具网络营销】核心模块。我会带你从零搭建一个简化版的订单服务，重点解决那个让人头大的 NullPointerException 和数据库死锁问题。读完这篇，你不仅知道代码怎么写，更知道为什么这么写，下次被问到时，你能像老手一样拆解问题。

项目目标与业务场景拆解

先搞清楚我们要干嘛。所谓的【家具网络营销】，核心痛点就两个字：库存。

想象一下，双十一晚上八点，一款限量版真皮沙发只剩 10 件。1000 个用户同时点击“购买”。如果我们的系统处理不好，要么超卖（卖了 11 件），要么少卖（只成功了 5 件），要么整个服务直接崩掉，满屏的 500 错误。

我们的目标不是做一个完整的电商前台，而是聚焦后端最核心的订单创建与库存扣减逻辑。我们要实现以下三个技术指标：

1. 数据一致性：确保库存绝对不超卖，利用数据库乐观锁或分布式锁机制。
2. 异常可追溯：任何报错都必须有清晰的上下文，而不是干巴巴的一行 Error at line 50。
3. 性能达标：在模拟 100 并发下，平均响应时间低于 200ms。

这里有个很现实的坑：很多初级开发写代码，习惯用 try-catch 把所有异常吞掉，然后打一句 log.error("出错了")。这在【家具网络营销】场景下是大忌。因为一旦出错，运营问“为什么用户没买到”，你连日志都查不到具体是哪个 SKU、哪个用户、哪一步失败的。

目录结构与依赖管理

为了保持代码的可读性，我们采用标准的 Maven 分层架构。不要一上来就写 Controller，先把领域模型定好。

src/main/java/com/furniture/marketing
├── controller
│   └── OrderController.java       // 入口层，接收 HTTP 请求
├── service
│   ├── OrderService.java          // 业务逻辑接口
│   └── impl
│       └── OrderServiceImpl.java  // 核心业务实现
├── repository
│   ├── ProductRepository.java     // 商品数据访问
│   └── OrderRepository.java       // 订单数据访问
├── model
│   ├── Product.java               // 商品实体
│   ├── Order.java                 // 订单实体
│   └── exception
│       └── InsufficientStockException.java // 自定义业务异常
└── util└── TraceIdGenerator.java      // 链路追踪工具

在 pom.xml 中，除了常规的 Spring Boot Starter Web 和 Data JPA，我们还需要引入 Lombok 来简化代码，以及 SLF4J 配合 Logback 进行结构化日志记录。

注意：在实际生产环境的【家具网络营销】项目中，通常不会直接用 JPA，而是用 MyBatis-Plus 以获得更精细的 SQL 控制。但为了本文的普适性和快速上手，我们暂时使用 JPA，逻辑是相通的。关键在于理解事务边界和异常传播。

核心代码实现与逐行剖析

这是重头戏。我们要解决的是并发下的库存扣减。很多人喜欢用 Redis 做预扣减，但 Redis 挂了怎么办？数据不一致怎么办？对于核心交易链路，数据库才是最终的一致性保障。

1. 定义领域模型

先看商品实体，这里有个关键字段 version，这是实现乐观锁的核心。

@Entity
@Table(name = "products")
@Data
public class Product {@Id@GeneratedValue(strategy = GenerationType.IDENTITY)private Long id;private String name;private BigDecimal price;private Integer stock;// 乐观锁版本控制，JPA 会自动处理@Versionprivate Integer version;
}

再看订单实体，这里我们特意加了一个 status 字段和 createdAt，用于后续的问题排查。

@Entity
@Table(name = "orders")
@Data
public class Order {@Id@GeneratedValue(strategy = GenerationType.IDENTITY)private Long id;private Long productId;private Integer quantity;private String status; // CREATED, PAID, CANCELLEDprivate LocalDateTime createdAt;
}

2. 自定义业务异常

不要直接用 RuntimeException。在【家具网络营销】这种高价值商品交易中，业务错误和系统错误必须区分开。

public class InsufficientStockException extends RuntimeException {public InsufficientStockException(Long productId, Integer required, Integer available) {// 构造清晰的错误信息，包含关键业务上下文super(String.format("商品ID: %d 库存不足, 需要: %d, 可用: %d", productId, required, available));}
}

3. 核心服务层实现

这里是代码的核心。请注意看事务注解 @Transactional 的使用，以及异常的处理逻辑。

@Service
public class OrderServiceImpl implements OrderService {@Autowiredprivate ProductRepository productRepository;@Autowiredprivate OrderRepository orderRepository;@Autowiredprivate Logger logger; // 使用 SLF4J Logger@Override@Transactionalpublic Order createOrder(Long productId, Integer quantity) {// 1. 生成 TraceId，用于全链路追踪String traceId = TraceIdGenerator.generate();logger.info("开始创建订单, TraceId: {}, 商品: {}, 数量: {}", traceId, productId, quantity);try {// 2. 查询商品，加锁防止脏读// 注意：这里使用 findById 是普通查询，但在并发高场景下// 建议结合 @Lock(LockModeType.PESSIMISTIC_WRITE) 或在 Service 层加分布式锁Product product = productRepository.findById(productId).orElseThrow(() -> new RuntimeException("商品不存在: " + productId));// 3. 校验库存if (product.getStock() < quantity) {// 抛出业务异常，而不是直接返回错误码// 这样可以在全局异常处理器中统一捕获并返回友好提示throw new InsufficientStockException(product.getId(), quantity, product.getStock());}// 4. 扣减库存// 乐观锁机制：如果并发更新导致 version 不匹配，JPA 会抛出 OptimisticLockExceptionproduct.setStock(product.getStock() - quantity);productRepository.save(product);// 5. 创建订单Order order = new Order();order.setProductId(productId);order.setQuantity(quantity);order.setStatus("CREATED");order.setCreatedAt(LocalDateTime.now());Order savedOrder = orderRepository.save(order);logger.info("订单创建成功, TraceId: {}, 订单ID: {}", traceId, savedOrder.getId());return savedOrder;} catch (InsufficientStockException e) {// 业务异常：记录 warn 级别日志，不打印完整堆栈，避免日志爆炸logger.warn("库存不足, TraceId: {}, 详情: {}", traceId, e.getMessage());throw e;} catch (Exception e) {// 系统异常：记录 error 级别日志，打印完整堆栈// 这里必须带上 TraceId，方便在 ELK 日志系统中搜索logger.error("订单创建失败, TraceId: {}, 商品: {}, 数量: {}", traceId, productId, quantity, e);// 重新抛出，让事务回滚throw new RuntimeException("系统内部错误", e);}}
}

关键点解析：

1. 日志上下文：每一行日志都带上了 traceId。当你在生产环境看到报错时，可以通过这个 ID 串联起 Controller、Service、Repository 的所有日志，快速定位问题。
2. 异常分级：InsufficientStockException 是预期内的业务失败，用 warn；OptimisticLockException 或 SQLException 是系统问题，用 error 并打印堆栈。很多新人把所有异常都打成 error 带堆栈，导致日志文件迅速膨胀，查找关键信息像大海捞针。
3. 事务回滚：在 catch 块中重新抛出 RuntimeException，Spring 的事务管理器才会自动触发回滚。如果你在这里吞掉异常，库存扣减了但订单没生成，数据就脏了。

4. 全局异常处理器

为了让前端拿到友好的错误信息，而不是裸露的 StackTrace，我们需要一个 @ControllerAdvice。

@RestControllerAdvice
public class GlobalExceptionHandler {private final Logger logger = LoggerFactory.getLogger(GlobalExceptionHandler.class);@ExceptionHandler(InsufficientStockException.class)@ResponseStatus(HttpStatus.BAD_REQUEST)public Map<String, String> handleInsufficientStock(InsufficientStockException e) {logger.info("捕获库存不足异常: {}", e.getMessage());Map<String, String> error = new HashMap<>();error.put("code", "STOCK_SHORTAGE");error.put("message", "手慢了，该家具已被抢光");return error;}@ExceptionHandler(Exception.class)@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)public Map<String, String> handleGeneric(Exception e) {// 注意：这里不要在响应体中返回 e.getMessage() 或堆栈信息，防止敏感信息泄露logger.error("未处理的全局异常", e);Map<String, String> error = new HashMap<>();error.put("code", "INTERNAL_ERROR");error.put("message", "服务器开小差了，请稍后重试");return error;}
}

运行与测试：复现那个“看不懂的报错”

光说不练假把式。我们来模拟一下那个让新手头疼的并发场景。

1. 初始化数据

在 data.sql 中插入一条测试数据：

INSERT INTO products (name, price, stock, version) VALUES ('意大利进口真皮沙发', 9999.00, 10, 0);

2. 编写并发测试

使用 JUnit 5 和 ExecutorService 模拟 20 个线程同时购买。

@Test
void testConcurrentOrderCreation() throws InterruptedException {int threadCount = 20;int quantityPerOrder = 1;ExecutorService executor = Executors.newFixedThreadPool(threadCount);CountDownLatch latch = new CountDownLatch(threadCount);AtomicInteger successCount = new AtomicInteger(0);AtomicInteger failCount = new AtomicInteger(0);for (int i = 0; i < threadCount; i++) {executor.submit(() -> {try {orderService.createOrder(1L, quantityPerOrder);successCount.incrementAndGet();} catch (Exception e) {failCount.incrementAndGet();// 这里不打印堆栈，只记录失败，避免干扰} finally {latch.countDown();}});}latch.await();executor.shutdown();// 断言：库存只有10，所以最多成功10次assertEquals(10, successCount.get(), "成功订单数应为10");assertEquals(10, failCount.get(), "失败订单数应为10");// 校验数据库最终状态Product product = productRepository.findById(1L).get();assertEquals(0, product.getStock(), "最终库存应为0");
}

3. 观察日志与报错

运行测试后，打开控制台日志。你会发现：

1. 有 10 条 INFO 日志显示“订单创建成功”。
2. 有 10 条 WARN 日志显示“库存不足”。
3. 没有 一条 ERROR 日志伴随巨大的 StackTrace。

这就是我们要的效果。如果在生产环境，这种 WARN 日志是可以接受的，因为这是正常的业务竞争失败。但如果出现了 OptimisticLockException（乐观锁冲突失败），我们需要重试机制。在【家具网络营销】中，通常会在 Service 层加一个重试逻辑，或者直接使用 Redis + Lua 脚本做预扣减，最后异步落库。

避坑指南：如果你发现测试中出现了 Deadlock（死锁），检查一下你的事务范围是否过大。确保 save 操作尽快完成，不要在一个大事务里做复杂的计算或远程调用。

优化扩展与进阶技巧

基础版跑通了，但离生产级的【家具网络营销】还差得远。以下是几个必须考虑的优化点：

1. 引入缓存层

直接查数据库在 QPS 达到 1000+ 时会撑不住。

• 方案：使用 Redis 存储商品基本信息（非库存）。
• 注意：库存必须在数据库中扣减，Redis 仅用于读加速。更新数据库后，删除或更新 Redis 缓存，采用“Cache Aside”模式。

2. 异步化非核心逻辑

订单创建成功后，通常需要发送短信通知、记录积分、推送给物流系统。

• 错误做法：在 createOrder 事务里同步调用这些服务。
• 正确做法：提交事务后，发送消息到 Kafka/RabbitMQ。
• 代码改动：

  @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
  public void onOrderCreated(Order order) {// 发送 MQ 消息rabbitTemplate.convertAndSend("order.created", order.getId());
  }
  

3. 数据库索引优化

在 orders 表的 productId 和 createdAt 上建立联合索引，方便后续查询“某商品最近一小时的订单量”。

CREATE INDEX idx_product_created ON orders (product_id, created_at);

4. 监控与告警

接入 Prometheus + Grafana。

• 监控指标：订单创建成功率、平均响应时间、JVM 堆内存使用率。
• 告警规则：当 5 分钟内 InsufficientStockException 比例超过 50%，触发钉钉/飞书告警，提示运营可能面临爆单或库存配置错误。

小结与互动

回顾一下，我们从一个简单的【家具网络营销】订单模块出发，解决了并发下的库存一致性问题，并重点讲解了如何通过结构化日志和异常分级来处理那个让人头疼的 StackTrace。

核心要点再强调一遍：

1. 不要吞异常：业务异常要清晰，系统异常要留痕。
2. TraceId 是神器：全链路追踪是排查分布式系统问题的救命稻草。
3. 乐观锁是基础：在高并发库存场景下，@Version 是最简单有效的防超卖手段。
4. 日志要分级：INFO 记录流程，WARN 记录业务拒绝，ERROR 记录系统故障。

这套逻辑不仅适用于家具电商，也适用于机票、酒店、秒杀等任何涉及库存扣减的场景。

这个知识点你面试被问过吗？留言说说：你在实际项目中遇到过最难排查的并发 Bug 是什么？是怎么定位的？欢迎在评论区分享你的踩坑经验，我们一起交流避坑技巧。