MSERPPY 系统中 Redis 的适用场景与设计原则
在仓库管理与ERP业务中，Redis 主要作为 高速缓存与快速读取层 使用，但 不承担最终数据一致性责任。Redis 的使用要遵循“读多写少缓存、写多读少不缓存”的原则。
以下为系统中 Redis 的设计思路与适用场景总结。
1. Redis 的定位
Redis 是基于内存的 Key-Value 数据存储，主要用于：
- 快速读取热点数据
- 减少数据库（尤其是 MySQL）并发压力
- 缓解高频查询（如 PDA 扫码）导致的 I/O 阻塞
它不是：
- 不是主数据库
- 不是永久存储
- 不承担事务一致性
数据最终可信性仍以数据库为准。
2. 什么时候适合使用 Redis？
适用于 数据量较小、变化不频繁、全局共享读取频率高 的场景。
典型例子：
| 业务类型 | 示例 | 适用原因 |
|---|---|---|
| 系统字典数据 | 计量单位、币种、税率、系统参数 | 小表、读多写少 |
| 客户档案展示字段 | 客户名称 / 简称 | 展示频繁，不用于条件过滤 |
| 产品类别树 | 分类节点结构 | 结构只读且跨模块查询频繁 |
| 盘点场景加载可用序列号 | 临时盘点缓存 | 可批量预加载，读取频繁 |
Redis 适用于：
读取快 + 数据稳定 + 不涉及模糊查的内容。
3. 什么时候不适合使用 Redis？
不适合用于 需要模糊查询或经常变化 的字段，例如：
| 字段类型 | 示例 | 不适用原因 |
|---|---|---|
| 用于模糊搜索的字段 | 产品编码、产品名称、规格 | Redis 无法高效支持 LIKE %xxx% |
| 动态计算字段 | 规格根据规则实时组合 | 缓存难同步，会造成错误展示 |
| 需要严格一致性的业务查询 | 出库库存扣减校验 | Redis 有延迟 → 容易造成负库存错误 |
尤其是 PDA、做账、库存变动场景：
库存判断必须直接查数据库，而不能依赖 Redis。
因为 Redis 存的只有“读缓存”，而库存属于 实时状态。
4. 盘点扫描场景中的 Redis 使用策略
盘点扫描时可能需要快速校验序列号是否存在库存中，而序列号量可能巨大。
设计思路：
- 盘点开始 → 批量加载库存中所有可盘序列号到 Redis
- PDA 扫码时 先查 Redis → 返回结果立即
- 盘点结束 → Redis 缓存可清空，不执行实时同步
这样：
| 指标 | 不用 Redis | 使用 Redis |
|---|---|---|
| 扫码响应速度 | 受 DB I/O 影响 | 毫秒级 |
| 并发能力 | 容易被多台 PDA 扫描压垮 | 高并发稳定 |
| 数据一致性 | 以数据库为准 | Redis 只作为临时查询，不改库存 |
→ 该场景非常适合 Redis。
5. Redis 数据一致性问题
Redis 的本质是缓存，有可能存在“缓存未同步数据库”的情况。
但我们确定：
Redis 只用于展示类/辅助判断类数据，不用于业务最终判断。
也就是说：
- 入库 / 出库 / 扣减 / 成本核算 / 库存结转 → 必须查数据库
- Redis 不用于决定库存正确性，只用于 辅助访问性能
6. 断电或重启时的影响
Redis 可配置持久化：
| 模式 | 特点 | 风险 |
|---|---|---|
| RDB | 定时快照 | 崩溃可能丢少量缓存数据（可接受） |
| AOF | 持续日志 | 几乎不丢数据（但本系统不依赖持久性） |
对于本系统：
Redis 丢数据不会影响业务，因为所有权威数据在数据库中。
7. 本系统推荐的 Redis 使用清单
| 表 / 数据 | 是否放 Redis | 理由 |
|---|---|---|
| 客户名称 / 简称 | ✅ 放 | 展示频繁，不用于查询条件 |
| 系统参数（单位、税率、币种等） | ✅ 放 | 小、稳定、全局共享 |
| 产品类别树 | ✅ 放 | 读取频繁、改动少 |
| PDA盘点可用序列号 | ✅ 放（阶段性） | 临时扫描索引，显著提升性能 |
| 产品编码 / 名称 / 规格 | ❌ 不放 | 涉及模糊查、需与 SQL 索引配合 |
| 库存数量、可用量 | ❌ 不放 | 必须保持数据库实时一致性 |
总结
Redis 在本系统中的核心角色是：
高频读取加速层，而不是数据源。
适用于：
- 读多写少
- 跨模块通用
- 不参与模糊查询
- 不影响库存正确性的场景
不适用于：
- 模糊搜索字段
- 动态计算字段
- 实时一致性要求的库存逻辑