在库存管理系统中，为什么选择Redis作为缓存，而不是直接依赖数据库，分析缓存策略（如读写分离、缓存穿透、缓存雪崩的应对），以及实际效果（如查询响应时间、系统压力）。请说明缓存设计的关键点及优化措施。
答案
1) 【一句话结论】在库存管理系统中，选择Redis作为缓存的核心原因是利用其内存级存储的高性能特性，通过合理的缓存策略（如读写分离、穿透/雪崩防护）降低数据库压力，最终实现查询响应时间优化与系统压力缓解。
2) 【原理/概念讲解】老师口吻：数据库（如MySQL）是“持久化仓库”，数据存放在磁盘，查询时需从磁盘读取，I/O开销大，适合核心业务数据；而Redis是“内存小卖部”，数据存于内存，读写速度极快（毫秒级），适合高频查询场景。比如库存查询这类热点数据，通过Redis缓存，能像“小卖部”一样快速响应，减少“去仓库”的延迟。
3) 【对比与适用场景】
| 特性/场景 | 数据库（如MySQL） | Redis |
|---|---|---|
| 定义 | 持久化存储，支持复杂事务、ACID | 内存数据库，支持数据结构、高并发读写 |
| 读写性能 | 写：稳定，读：依赖索引，I/O开销大 | 读：毫秒级，写：微秒级（内存操作） |
| 数据持久化 | 支持（事务、日志） | 支持（RDB/AOF，但默认不持久化，适合缓存） |
| 适用场景 | 业务核心数据，需要持久化、事务 | 高频查询、热点数据缓存，临时数据 |
| 注意点 | 并发下锁竞争，事务开销 | 内存容量限制，持久化配置影响性能 |
4) 【示例】假设库存系统，商品ID为1的商品库存查询流程：
- 客户端请求查询商品ID=1的库存。
- 后端服务先查询Redis（key: "stock:1"），若存在则返回缓存数据。
- 若Redis中无数据，则查询数据库（SELECT stock FROM inventory WHERE id=1）。
- 从数据库获取结果后，更新Redis（SET "stock:1" 100 EXPIRE 3600）。
- 返回结果给客户端。
伪代码（后端逻辑）：
def get_stock(product_id):
stock = redis.get(f"stock:{product_id}")
if stock:
return int(stock)
stock = db.query(f"SELECT stock FROM inventory WHERE id = {product_id}")
if stock:
redis.set(f"stock:{product_id}", stock.stock, ex=3600)
return stock.stock
return 0
5) 【面试口播版答案】
面试官您好，关于为什么在库存系统中选择Redis作为缓存，核心是利用Redis内存级存储的高性能特性，降低数据库查询压力。首先，数据库（如MySQL）是持久化存储，查询时需要从磁盘读取数据，I/O开销大，而Redis是内存数据库，读写速度极快（毫秒级），适合高频查询场景。比如库存查询这类热点数据，通过Redis缓存，能大幅提升响应时间。然后缓存策略方面，针对高并发场景，我们做了三方面优化：一是缓存穿透，通过布隆过滤器或空值缓存（比如查询不存在的商品时，缓存null并设置过期时间）避免大量无效请求；二是缓存雪崩，给缓存数据设置随机过期时间（比如±10%的随机值），避免大量缓存同时过期；三是缓存击穿，对热点数据（如热销商品）设置永不过期或长过期时间，防止并发查询时穿透。实际效果上，我们测试发现，缓存引入后，库存查询响应时间从原来的200ms降低到10ms以内，系统压力降低约60%，数据库QPS从500降到200左右。关键点包括：1. 热点数据优先缓存；2. 合理的过期策略；3. 缓存穿透/雪崩防护。优化措施则是根据业务场景调整缓存大小、过期时间，并监控缓存命中率。
6) 【追问清单】
- 缓存穿透如何具体实现？回答要点：使用布隆过滤器提前过滤不存在的key，或缓存空值并设置过期时间。
- 缓存雪崩怎么解决？回答要点：给缓存数据设置随机过期时间（Jitter），避免集中过期。
- 如果缓存和数据库数据不一致怎么办？回答要点：采用数据库更新后异步更新缓存（如消息队列），或缓存数据设置过期时间（TTL），保证数据最终一致性。
- Redis的淘汰策略有哪些？回答要点：LRU（最近最少使用）、LFU（最不经常使用）、最小值淘汰等，根据业务选择。
- 如果系统并发量很大，Redis单节点扛不住怎么办？回答要点：使用Redis集群（Sentinel/Cluster）或分布式缓存（如Redis Cluster）。
7) 【常见坑/雷区】
- 忽略缓存穿透问题，导致大量无效请求冲击数据库。
- 缓存数据未设置过期时间，导致数据不一致（如库存更新后缓存未更新）。
- 未考虑并发场景下的缓存更新问题（如多线程同时更新缓存，导致数据不一致）。
- 过度依赖缓存，导致缓存击穿（热点数据缓存失效时，大量请求穿透到数据库）。
- 未监控缓存命中率，无法评估缓存效果，无法优化。