核心用法
Redis作为内存数据结构存储,主要应用于三大场景:缓存加速(cache-aside/write-through模式)、实时数据处理(Sorted Sets做限流、HyperLogLog去重计数)、消息队列(Streams替代Pub/Sub实现可靠投递)。关键操作包括:用SET key EX强制过期时间避免内存泄漏;利用Hash结构存储对象节省内存;通过Lua脚本或SETNX实现原子锁操作。
显著优点
- 极致性能:纯内存操作,单线程无锁设计,QPS可达10万+
- 数据结构丰富:String/Hash/List/Set/ZSet/Streams/HyperLogLog等,适配多样化场景
- 原子操作内置:
INCR、SETNX、Lua脚本等避免竞态条件 - 持久化灵活:RDB快速恢复+AOF低数据丢失,或纯内存模式
- 集群扩展:Hash Slot分片,支持水平扩容至1000+节点
潜在缺点与局限
- 内存成本高昂:所有数据驻留RAM,大value(如100MB)会急剧膨胀成本
- 单线程阻塞风险:
KEYS *、FLUSHALL等操作会冻结整个实例 - Pub/Sub不可靠:消息不持久化,断线即丢失,不适合关键业务
- 集群限制:跨Slot多键操作被禁止,需用Hash Tag hack或客户端处理
MOVED重定向 - 惰性过期陷阱:过期键在未被访问前仍占用内存,大库
SCAN可能返回"幽灵"key
适合人群
- 后端开发工程师(缓存/会话/限流设计)
- 分布式系统架构师(高可用集群、数据一致性方案)
- DevOps/SRE(内存监控、持久化策略调优)
- 数据工程师(实时统计、流处理管道)
常规风险
| 风险等级 | 场景 | 后果 |
|---------|------|------|
| **致命** | 生产环境未配置`maxmemory` | 内存耗尽触发OOM,宿主机崩溃 |
| **致命** | 无持久化却当作主库使用 | 重启后全量数据丢失 |
| **高危** | 缓存key无TTL | 内存持续增长直至拒绝服务 |
| **中危** | `GET→SET`非原子竞争 | 并发覆盖导致数据不一致 |
| **中危** | 大key未拆分 | 阻塞主线程,慢查询拖垮集群 |
| **低危** | 客户端非集群感知型 | `MOVED`错误未处理,操作失败 |
建议生产环境必须:设置maxmemory+allkeys-lru、启用AOF+everysec、部署Sentinel或Cluster模式、监控used_memory和evicted_keys指标。