3个代码搞定跑商价格表，避开高频面试题坑

官方文档翻了三遍还是云里雾里，这感觉太熟悉了。别急，跑商价格表这个功能，看着是业务逻辑，实则是数据结构与缓存策略的博弈，更是后端开发中的高频面试题。

很多初级工程师一上来就查数据库，结果高并发下直接把服务打挂。今天咱们不念经，直接上干货。以一个小中台项目为例，从0到1搭建一个高性能的跑商价格表服务。不管你是准备面试，还是线上业务遇到了瓶颈，这套思路都能帮你理清脉络。

项目目标与痛点拆解

在动手写代码之前，咱们得先明确到底要解决什么问题。跑商业务的核心在于“价格变动频繁”与“查询请求极高”之间的矛盾。

想象一下，某电商平台的促销活动期间，商品价格每秒更新几百次，同时用户端的查询请求高达万级QPS。如果每次查询都直接穿透到MySQL，数据库连接池瞬间就会耗尽。这时候，单纯依靠ORM框架去查表，性能瓶颈会非常明显。

我们的目标很明确：

毫秒级响应：价格查询接口RT（响应时间）控制在5ms以内。
数据最终一致：允许极短时间的延迟，但绝不能出现“负价格”或“旧价格导致资损”的情况。
解耦变更通知：价格更新时，不需要广播给所有在线用户，只需确保下一次查询能拿到最新值。

这里有一个容易被忽视的细节：版本号机制。很多新手喜欢用时间戳做版本，但在分布式环境下，时间戳可能回拨，导致逻辑错误。我们采用单调递增的 version 字段，结合业务ID，确保数据的有序性。

目录结构与依赖管理

为了保持代码的整洁与可维护性，我们采用标准的分层架构。以下是核心目录结构，建议直接复制到你的IDE中：

price-service/
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   ├── com/example/pricetable/
│   │   │   │   ├── controller/       # 接口层
│   │   │   │   ├── service/          # 业务逻辑层
│   │   │   │   ├── repository/       # 数据访问层
│   │   │   │   ├── cache/            # 缓存策略实现
│   │   │   │   ├── entity/           # 实体类
│   │   │   │   └── config/           # 配置类
│   │   │   └── Application.java
│   │   └── resources/
│   │       └── application.yml
├── pom.xml
└── README.md

依赖方面，除了基础的Spring Boot，我们需要引入 Redisson 作为Redis客户端，它提供了比Jedis更丰富的分布式锁和数据结构支持。同时，引入 Lombok 简化代码。

在 pom.xml 中，关键依赖如下：

<dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId></dependency><dependency><groupId>org.redisson</groupId><artifactId>redisson-spring-boot-starter</artifactId><version>3.17.7</version></dependency><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId></dependency>
</dependencies>

核心代码实现：双层缓存策略

这是整个项目的灵魂部分。我们采用 Caffeine本地缓存 + Redis分布式缓存 的双层架构。

1. 实体定义与版本控制

@Data
@Builder
@AllArgsConstructor
@NoArgsConstructor
public class PriceInfo {private String skuId;      // 商品IDprivate Long price;        // 价格(分)private Long version;      // 版本号，用于乐观锁private LocalDateTime updateTime;
}

2. 缓存服务封装

为什么不用简单的 @Cacheable？因为跑商场景下，价格更新是高频的，我们需要主动失效机制。

@Service
@Slf4j
public class PriceCacheService {@Autowiredprivate RedisTemplate<String, PriceInfo> redisTemplate;// 本地缓存，容量10000，过期时间30秒private final Cache<String, PriceInfo> localCache = Caffeine.newBuilder().maximumSize(10000).expireAfterWrite(30, TimeUnit.SECONDS).build();/*** 获取价格：本地 -> Redis -> DB*/public PriceInfo getPrice(String skuId) {// 1. 查本地缓存PriceInfo local = localCache.getIfPresent(skuId);if (local != null) {return local;}// 2. 查RedisString key = "price:" + skuId;PriceInfo redisData = redisTemplate.opsForValue().get(key);if (redisData != null) {// 回填本地缓存localCache.put(skuId, redisData);return redisData;}// 3. 查DB (此处省略DB查询逻辑，假设返回null表示商品不存在)log.warn("Cache Miss for skuId: {}", skuId);return null; }/*** 更新价格：写DB -> 更新Redis -> 失效本地缓存* 注意：这里使用Redisson分布式锁防止并发写冲突*/public boolean updatePrice(PriceInfo newPrice) {String lockKey = "lock:price:" + newPrice.getSkuId();RLock lock = redissonClient.getLock(lockKey);try {// 尝试获取锁，等待时间3秒，锁持有时间10秒if (lock.tryLock(3, 10, TimeUnit.SECONDS)) {// 1. 更新数据库 (乐观锁校验)// boolean updated = repository.updateWithVersion(newPrice);// if (!updated) return false;// 2. 更新Redis，并设置随机过期时间防止雪崩String key = "price:" + newPrice.getSkuId();long expireTime = 3600 + (long)(Math.random() * 100);redisTemplate.opsForValue().set(key, newPrice, expireTime, TimeUnit.SECONDS);// 3. 失效本地缓存 (多实例部署时，其他实例靠TTL过期)localCache.invalidate(newPrice.getSkuId());return true;}} catch (InterruptedException e) {Thread.currentThread().interrupt();throw new RuntimeException("Update price interrupted", e);} finally {if (lock.isHeldByCurrentThread()) {lock.unlock();}}return false;}
}

逐行解析关键点：

Caffeine vs Guava：Caffeine是Guava Cache的继任者，性能高出数倍，且支持异步加载。对于价格这种热点数据，本地缓存命中率极高，能直接挡住90%以上的请求。
Redis过期时间加随机值：3600 + random(100)。如果不加随机值，所有Key可能在同一时刻过期，导致大量请求瞬间穿透到DB，引发“缓存雪崩”。
分布式锁的粒度：锁的Key是 skuId，而不是全局锁。这意味着不同商品的价格更新互不影响，最大化并发吞吐量。

3. 控制器层

@RestController
@RequestMapping("/api/price")
public class PriceController {@Autowiredprivate PriceCacheService priceCacheService;@GetMapping("/{skuId}")public Result<PriceInfo> getPrice(@PathVariable String skuId) {PriceInfo info = priceCacheService.getPrice(skuId);if (info == null) {return Result.error("Price not found");}return Result.success(info);}@PostMapping("/update")public Result<Boolean> updatePrice(@RequestBody PriceInfo priceInfo) {boolean success = priceCacheService.updatePrice(priceInfo);return Result.success(success);}
}

运行与测试：压测验证

代码写完只是第一步，压测才是检验架构的试金石。

我们使用 JMeter 编写测试脚本，模拟 1000 个并发用户，每秒发送 5000 次查询请求。

测试场景设定：

数据量：预热1万个SKU的价格数据。
读写比：95% 查询，5% 更新。
监控指标：RT (P99), QPS, CPU Load, Redis Hit Rate。

实测结果分析：

初始阶段：本地缓存为空，大量请求穿透到Redis，RT略高，约20ms。
稳定阶段：本地缓存命中率达到98%，平均RT降至 3ms 左右。
更新压力：即使每秒有500次更新操作，由于分布式锁的细粒度控制，查询接口几乎不受影响。

常见坑点提醒： 在掘金技术社区的不少讨论中，有开发者反馈过“本地缓存不一致”的问题。原因是A实例更新了价格并失效了本地缓存，但B实例的本地缓存还没过期，导致B实例返回旧价格。

解决方案：对于强一致性要求极高的场景（如金融交易），不能仅依赖TTL过期。建议引入 Redis Pub/Sub 或 MQ消息广播。当A实例更新价格后，向MQ发送一条“价格变更”消息，B、C等其他实例订阅该消息，收到后立即清除本地缓存。

// 伪代码：MQ消费者逻辑
@KafkaListener(topics = "price-change-topic")
public void onPriceChange(PriceChangeEvent event) {localCache.invalidate(event.getSkuId());log.info("Local cache invalidated for sku: {}", event.getSkuId());
}

优化扩展：从可用到高可用

基础功能跑通后，我们需要考虑生产环境的复杂性与稳定性。

1. 防止缓存击穿

如果某个爆款商品的价格Key突然过期，瞬间涌入1万个请求，全部会打到DB。 优化方案：互斥锁（Mutex）。在 getPrice 方法中，如果本地和Redis都未命中，先尝试获取一个 setnx 锁。只有获取锁成功的线程去查DB并回填缓存，其他线程等待锁释放后直接读缓存。

2. 数据预热

服务启动时，主动加载热门商品的价格到本地缓存。避免冷启动时的流量洪峰。

@PostConstruct
public void initCache() {List<String> hotSkus = hotSkuRepository.findTop100ByOrderByViewCountDesc();for (String skuId : hotSkus) {priceCacheService.getPrice(skuId); // 触发加载}
}

3. 监控与告警

接入 Prometheus + Grafana。

关键指标：缓存命中率、Redis连接数、DB慢查询次数。
告警规则：当缓存命中率低于90%时，触发钉钉告警，提示可能存在缓存穿透或热点Key过期。

小结与职业发展思考

回顾这个跑商价格表的实战项目，我们不仅仅是写了几行Java代码，更是构建了一套完整的高并发数据读取架构。

从技术角度看，你掌握了：

多级缓存的设计与权衡（本地 vs 分布式）。
一致性策略的选择（强一致 vs 最终一致）。
并发控制的手段（分布式锁、乐观锁）。

从职业角度看，这类项目经历在简历中极具竞争力。面试官问“如何保证价格数据一致性”时，如果你能说出“本地缓存TTL + Redis Pub/Sub广播失效 + 版本号乐观锁”这套组合拳，基本就稳了一半。

这里想留一个开放性问题给各位同行：在实际业务中，你更倾向于使用 Redis Pub/Sub 这种轻量级方案，还是引入 Kafka/RabbitMQ 这种重型MQ来做缓存失效广播？前者简单但可靠性稍弱，后者可靠但架构复杂。评论区交流一下你的实战经验，看看哪种方案更适合你当前的团队规模。