Redis 为何常被用作缓存而非主数据库？

Question

Redis 为何常被用作缓存而非主数据库？这是一个高频技术选型问题。根本原因在于其设计哲学与核心能力的权衡：Redis 是内存优先、单线程（6.x 后支持多IO线程但逻辑仍串行）、强调极致读写性能（微秒级响应）和简单数据结构的存储系统；它虽支持持久化（RDB/AOF），但存在数据丢失风险（如崩溃时未刷盘）、缺乏完备的事务隔离（仅提供弱一致性 MULTI/EXEC）、不支持复杂查询（无 JOIN、索引有限）、无原生水平扩展能力（Cluster 模式运维复杂），且内存成本高、容量受限。而主数据库需保障 ACID、强一致性、海量数据持久化、复杂分析能力及高可用容灾体系——这些恰是 PostgreSQL、MySQL 或分布式数据库的专长。因此，Redis 的最佳实践定位是「缓存层」或「状态中间件」（如 Session、排行榜、限流计数），而非承载核心业务数据的唯一真相源。混淆角色易引发数据不一致、扩容瓶颈与运维风险。

Answer 1

```html

一、表象层：为什么开发第一眼就选 Redis 做“数据库”？

新手常因 Redis 的 SET user:1001 "{...}" 和 GET 接口酷似 SQL 的 INSERT/SELECT，误判其可替代 MySQL。它响应快（<100μs）、API 简洁、支持 JSON 字符串序列化，甚至能用 RedisJSON 模块模拟文档操作——但这只是「接口友好性」的幻觉。真实生产中，一旦出现主从切换丢数据、AOF rewrite 期间 OOM、或 Lua 脚本超时阻塞，裸用 Redis 存核心订单就会触发 P0 故障。

二、架构层：内存优先设计决定能力边界

Redis 95% 以上热数据驻留内存，采用 单线程事件循环（main thread） 处理命令（6.0+ 引入多 IO 线程仅加速网络读写，命令执行仍串行）。这带来极致确定性延迟，但也导致：

• 无法并行执行复杂事务（如转账需查余额→扣减→更新日志→发消息，MULTI/EXEC 仅保证原子性，不提供隔离级别）
• 大 key 扫描（KEYS *）直接阻塞所有请求
• 内存碎片率（mem_fragmentation_ratio）>1.5 时，即使空闲内存充足也会 OOM

三、数据层：持久化 ≠ 数据库级可靠性

机制	RDB	AOF	混合持久化（RDB+AOF）
崩溃丢失窗口	最后一次 bgsave 之后全部	默认秒级 fsync，最多丢 1s 数据	仍依赖最后 RDB 快照 + AOF 增量
恢复速度	极快（二进制加载）	慢（重放命令流）	中等
一致性保障	无事务语义	命令级追加，但无回滚	仍无法解决网络分区下的脑裂写入

四、语义层：缺失关系型数据库的基石能力

以下为典型主库能力与 Redis 的对比：

✅ PostgreSQL 支持：  
   • 可串行化（SERIALIZABLE）隔离级别  
   • 多表 JOIN + B-tree/GIN 全文索引  
   • CHECK 约束 + 触发器 + 分区表  
   • 逻辑复制 + 时间点恢复（PITR）  

❌ Redis 仅支持：  
   • 单 key 原子操作（INCR, HINCRBY）  
   • Sorted Set 范围查询（ZRANGEBYSCORE），但无 WHERE 条件下推  
   • 模糊匹配依赖 SCAN + 客户端过滤（性能灾难）  

五、扩展层：Cluster 不是“分布式数据库”的代名词

Redis Cluster 通过哈希槽（16384 slots）分片，但存在硬伤：

• 不支持跨 slot 事务（MULTI 命令在多个 key 上会报错）
• 运维复杂度高：故障转移需人工校验 failover 状态、Gossip 协议收敛慢（默认 1s）、批量迁移耗时长
• 客户端必须支持 smart client（如 JedisCluster），否则直连节点将路由失败

六、成本层：内存经济性 vs 业务可持续性

以存储 1TB 用户画像为例：

• Redis 内存成本 ≈ 1TB × 1.5（预留碎片+副本）× ¥12/GB/月 = ¥18,000/月
• MySQL（SSD）+ 压缩表 ≈ 1TB × ¥0.8/GB/月 = ¥800/月
• 且 Redis 无法做冷热分离（无自动分层），而 PostgreSQL 可通过 pg_partman + TimescaleDB 实现时序归档

七、实践层：何时该坚持“缓存即缓存”原则？

graph TD A[用户下单] --> B{是否命中缓存？} B -->|Yes| C[返回 Redis 中的库存/价格] B -->|No| D[查 MySQL 主库] D --> E[写入 Redis 缓存
设置合理 TTL + 逻辑过期] E --> F[异步双删：
先删缓存 → 更新 DB → 延迟再删] F --> G[防缓存击穿：
Mutex Key + SETNX]

八、反模式警示：那些把 Redis 当主库踩过的坑

某金融平台曾将交易流水全量存于 Redis Hash，结果遭遇：

• 集群扩容时 rehash 导致 3 分钟全链路超时（因未启用 cluster-node-timeout 自适应）
• AOF rewrite 触发 fork() 失败（物理内存不足），进程被 OOM Killer 终止
• 未设 maxmemory-policy，内存溢出后随机驱逐 key，造成用户余额显示异常
• 审计需求要求按时间范围查询流水，被迫用 ZSET 存时间戳，但无法满足“同一用户多笔同秒交易”的精确排序

九、演进层：Redis 的正确定位与协同架构

现代高并发系统中，Redis 的黄金角色是：

1. 状态中间件：Session 存储、分布式锁（Redlock 已淘汰，推荐 set nx px + UUID）、限流令牌桶（Redis + Lua 原子计数）
2. 计算加速层：实时排行榜（ZSET）、地理位置围栏（GEOHASH）、布隆过滤器（RedisBloom）
3. 事件暂存通道：结合 Redis Streams 替代轻量级 Kafka（注意：无副本 ISR 机制，仅适用于非关键事件）

十、决策层：技术选型检查清单（含代码验证）

在立项评审时，请运行以下脚本验证是否误用 Redis：

# 检查是否存在大 key（>1MB）
redis-cli --bigkeys -i 0.01

# 检查 AOF 是否开启且配置安全
redis-cli CONFIG GET appendonly  # 应为 yes
redis-cli CONFIG GET appendfsync # 推荐 everysec 或 always（权衡性能）

# 检查内存碎片率
redis-cli INFO memory | grep mem_fragmentation_ratio
# >1.5 需重启或启用 activedefrag yes

```