微服务架构落地：Redis 缓存体系架构（上篇）—— 集群架构、多级缓存、热点 Key 治理，支撑高并发商品与库存业务

大宗商品销采运储系统・六层架构连载（公共中间件层）

前面连载我们完成了微服务核心三大底座：注册中心、配置中心、消息队列的全链路落地拆解。

注册中心解决服务发现，配置中心解决动态参数治理，消息队列解决异步解耦与流量削峰。而 Redis 缓存，是整个销采运储系统的高并发流量护城河。

在大宗商品业务场景中：商品报价实时变动、库存余量高频查询、客户信息频繁读取、榜单数据实时刷新、首页行情流量脉冲暴涨。

如果所有高并发查询全部直连数据库，MySQL 瞬间会被大流量打崩，出现查询超时、CPU 打满、业务卡顿雪崩。

缓存的核心价值一句话定调：

用内存算力换磁盘算力，拦截 90% 以上高并发读流量，保护核心数据库，保障系统高可用、高响应。

本篇为 Redis 架构上篇，聚焦三件事：

1. 集群架构选型；

2. 多级缓存体系；

3. 热点 Key 治理。

结合大宗商品库存、报价、客户信息业务实战落地。

---

一、大宗商品业务为什么必须重度依赖缓存？

我们先梳理销采运储系统中典型高并发读场景，也是缓存核心落地场景：

1. 大宗商品实时报价

行情实时波动、用户频繁刷新、开盘瞬间流量暴增，属于超高 QPS、低变更、高频读场景，完全适配缓存。

2. 实时库存余量

采购、销售、出库、调度频繁查询库存，每次单据操作都要校验库存余量，数据库查询压力极大。

3. 客户基础信息、权限配置

基础数据变动少、读取多，非常适合缓存预热，减少重复查库。

4. 业务榜单、统计快照、对账临时数据

批量统计数据无需实时落库，可缓存快照，大幅减轻统计 SQL 压力。

边界规范：
缓存只负责高速查询、流量拦截，不替代数据库。核心交易、库存扣减最终一致性，依然以 MySQL 为准，缓存仅作加速手段。

---

二、Redis 集群架构选型：为什么不单机、不主从，只选集群？

中小型项目常使用单机、主从+哨兵模式，但大宗商品销采运储系统属于中大型分布式交易系统，存在三大硬性要求：高并发、大容量、高可用、可横向扩容。

我们做三种架构对比：

架构	优点	缺点	项目适配
单机 Redis	简单、部署快	无高可用、无扩容能力、单点故障直接宕机	❌ 生产禁止使用