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
groupIdorg.springframework.boot/groupId
artifactIdspring-boot-starter-web/artifactId
/dependency
dependency
groupIdorg.springframework.boot/groupId
artifactIdspring-boot-starter-data-redis/artifactId
/dependency
dependency
groupIdorg.redisson/groupId
artifactIdredisson-spring-boot-starter/artifactId
version3.17.7/version
/dependency
dependency
groupIdorg.projectlombok/groupId
artifactIdlombok/artifactId
/dependency
/dependencies
核心代码实现：双层缓存策略
这是整个项目的灵魂部分。我们采用 Caffeine本地缓存 + Redis分布式缓存 的双层架构。
1. 实体定义与版本控制
@Data
@Builder
@AllArgsConstructor
@NoArgsConstructor
public class PriceInfo {
private String skuId; // 商品ID
private Long price; // 价格(分)
private Long version; // 版本号，用于乐观锁
private LocalDateTime updateTime;
}
2. 缓存服务封装
为什么不用简单的 @Cacheable？因为跑商场景下，价格更新是高频的，我们需要主动失效机制。
@Service
@Slf4j
public class PriceCacheService {
@Autowired
private RedisTemplateString, PriceInfo redisTemplate;
// 本地缓存，容量10000，过期时间30秒
private final CacheString, 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. 查Redis
String 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 {
@Autowired
private PriceCacheService priceCacheService;
@GetMapping(/{skuId})
public ResultPriceInfo 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 ResultBoolean 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() {
ListString 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来做缓存失效广播？前者简单但可靠性稍弱，后者可靠但架构复杂。评论区交流一下你的实战经验，看看哪种方案更适合你当前的团队规模。 
长河君 · 2026/9/22 20:18:50 · 阅读 1.2k 3个代码搞定跑商价格表，避开高频面试题坑
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
groupIdorg.springframework.boot/groupId
artifactIdspring-boot-starter-web/artifactId
/dependency
dependency
groupIdorg.springframework.boot/groupId
artifactIdspring-boot-starter-data-redis/artifactId
/dependency
dependency
groupIdorg.redisson/groupId
artifactIdredisson-spring-boot-starter/artifactId
version3.17.7/version
/dependency
dependency
groupIdorg.projectlombok/groupId
artifactIdlombok/artifactId
/dependency
/dependencies
核心代码实现：双层缓存策略
这是整个项目的灵魂部分。我们采用 Caffeine本地缓存 + Redis分布式缓存 的双层架构。
1. 实体定义与版本控制
@Data
@Builder
@AllArgsConstructor
@NoArgsConstructor
public class PriceInfo {
private String skuId; // 商品ID
private Long price; // 价格(分)
private Long version; // 版本号，用于乐观锁
private LocalDateTime updateTime;
}
2. 缓存服务封装
为什么不用简单的 @Cacheable？因为跑商场景下，价格更新是高频的，我们需要主动失效机制。
@Service
@Slf4j
public class PriceCacheService {
@Autowired
private RedisTemplateString, PriceInfo redisTemplate;
// 本地缓存，容量10000，过期时间30秒
private final CacheString, 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. 查Redis
String 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 {
@Autowired
private PriceCacheService priceCacheService;
@GetMapping(/{skuId})
public ResultPriceInfo 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 ResultBoolean 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() {
ListString 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来做缓存失效广播？前者简单但可靠性稍弱，后者可靠但架构复杂。评论区交流一下你的实战经验，看看哪种方案更适合你当前的团队规模。