2. Redis简介：Redis发展历史、Redis核心特性、Redis与其他缓存（Memcached）对比、Redis应用场景
2.1 Redis发展历史
Redis（Remote Dictionary Server）由意大利开发者 Salvatore Sanfilippo（网名 antirez）于 2009 年创建。最初是为了解决其创业项目 LLOOGG 的实时统计性能瓶颈而诞生的一个轻量级键值存储层。从诞生至今，Redis 经历了几个关键里程碑：
- 2009 年 —— Redis 首次公开发布，基于 ANSI C 编写，提供简单的字符串操作和持久化能力。
- 2010 年 —— VMware 开始赞助 Redis 开发，引入列表、集合、有序集合等丰富数据结构。
- 2013 年 —— Redis 2.6/2.8 版本发布，加入 Lua 脚本、过期键优化、主从复制改进，社区活跃度大幅提升。
- 2015 年 —— Redis 3.0 正式发布，引入 Redis Cluster 原生分布式方案，打破单机内存限制。
- 2018 年 —— Redis 5.0 发布，新增 Stream 数据类型，成为消息队列场景的有力竞争者。
- 2020 年 —— Redis 6.0 引入多线程 I/O、ACL 权限控制、RESP3 协议，性能与安全性显著增强。
- 2022 年至今 —— Redis 7.x 持续优化，支持函数库、Sharded Pub/Sub、更细粒度的内存管理，生态日趋成熟。
发展启示： Redis 从“缓存工具”进化为“实时数据基础设施”，其核心驱动力是对数据结构和分布式能力的持续深耕，而非单纯追求吞吐量。
2.2 Redis核心特性
Redis 之所以在缓存和实时数据领域占据主导地位，源于以下六大核心特性：
| 特性 | 说明 | 典型价值 |
|---|---|---|
| 纯内存存储 + 持久化 | 数据主要驻留内存，同时支持 RDB 快照和 AOF 日志两种持久化方式 | 微秒级读写延迟，兼顾数据恢复 |
| 丰富的数据结构 | String、Hash、List、Set、Sorted Set、Bitmap、HyperLogLog、Geospatial、Stream | 一套系统覆盖缓存、计数、排行榜、消息队列等场景 |
| 单线程 + 多线程 I/O | 核心命令执行仍为单线程，避免锁竞争；网络 I/O 使用多线程提升吞吐 | 原子性操作天然支持，无死锁风险 |
| 高可用与分布式 | 主从复制 + Sentinel 哨兵模式 + Redis Cluster 分片 | 自动故障转移，水平扩展至数百节点 |
| Lua 脚本与事务 | 服务端执行 Lua 脚本，支持 MULTI/EXEC 事务块 | 复杂逻辑原子执行，减少网络往返 |
| 发布/订阅与 Stream | Pub/Sub 实时消息推送；Stream 支持消费者组、消息持久化 | 轻量级消息总线与可靠消息队列 |
架构视角： Redis 的单线程事件循环模型是其低延迟的基石——避免了上下文切换和锁开销，但这也意味着单个慢查询（如 KEYS *）会阻塞整个实例，生产环境必须使用 SCAN 替代。
2.3 Redis 与 Memcached 对比
Memcached 是 Redis 之前最流行的分布式缓存系统，两者在架构理念上存在本质差异。下表从多个维度进行对比：
| 对比维度 | Redis | Memcached |
|---|---|---|
| 数据结构 | String、Hash、List、Set、Sorted Set、Stream 等 9 种 | 仅支持 String（键值对） |
| 持久化 | 支持 RDB 快照 + AOF 日志，可完全恢复 | 不支持持久化，重启后数据全部丢失 |
| 内存管理 | 根据数据结构动态分配，支持内存淘汰策略（LRU/LFU/TTL） | 预分配 Slab 内存池，存在内存碎片问题 |
| 集群模式 | 原生 Cluster 分片 + 主从复制 + Sentinel 高可用 | 无原生集群，依赖客户端一致性哈希 |
| 多线程 | 核心单线程 + 多线程 I/O（6.0+） | 多线程处理（默认 4 线程），每个线程独立处理连接 |
| 典型延迟 | 微秒级（P99 < 1ms） | 毫秒级（P99 1-3ms） |
| 功能扩展 | Lua 脚本、事务、Pub/Sub、Stream、RedisSearch 模块 | 无脚本能力，功能固定 |
| 适用场景 | 缓存 + 数据库 + 消息队列 + 实时分析 | 纯缓存（简单 key-value 查询） |
选型建议： 如果业务只需要“存一个字符串、读一个字符串、过期自动删除”，且对持久化无要求，Memcached 的多线程模型在极高并发下仍有优势。但一旦涉及列表、计数器、排行榜、分布式锁等场景，Redis 是唯一合理选择。
2.4 Redis 应用场景
基于上述特性，Redis 在以下场景中已成为事实标准：
- 缓存加速 —— 数据库查询结果缓存、页面片段缓存、API 响应缓存。典型命中率 90%+，可将读延迟从 10ms 降至 <1ms。
- 分布式锁 —— 基于 SETNX + 过期时间实现互斥锁，配合 Redlock 算法保证多节点一致性。
- 计数器与限流 —— 使用 INCR/DECR 实现点赞数、访问统计；结合滑动窗口算法做接口限流。
- 排行榜与排序 —— Sorted Set 的 score 排序天然适合实时排行榜、积分排名、延时队列。
- 消息队列 —— List 的 LPUSH/BRPOP 实现简单队列；Stream 支持消费者组、消息确认、持久化，适合可靠消息场景。
- 实时会话管理 —— 使用 Hash 存储用户 Session，配合 TTL 自动过期，替代传统数据库会话存储。
- 地理位置服务 —— Geo 数据类型支持附近的人、门店距离计算、地理围栏。
- 位图与布隆过滤器 —— Bitmap 用于签到统计、用户活跃度；RedisBloom 模块实现布隆过滤器，防止缓存穿透。
实战案例： 某电商平台使用 Redis 缓存商品详情页，QPS 从 2000 提升至 50000；同时使用 Sorted Set 维护秒杀商品的实时库存排名，使用 Stream 异步处理订单创建，整体架构延迟降低 80%。
下表总结了各场景对应的 Redis 数据类型与核心命令：
| 应用场景 | 推荐数据类型 | 核心命令示例 |
|---|---|---|
| 缓存加速 | String / Hash | GET/SET、HGETALL/HSET |
| 分布式锁 | String | SETNX、SET key value NX PX 30000 |
| 计数器 | String | INCR、DECR、INCRBY |
| 排行榜 | Sorted Set | ZADD、ZRANGE、ZREVRANGE |
| 消息队列 | List / Stream | LPUSH/BRPOP、XADD/XREADGROUP |
| 会话管理 | Hash + TTL | HSET、EXPIRE、HGETALL |
| 地理位置 | Geo | GEOADD、GEORADIUS |
| 布隆过滤器 | Bloom (模块) | BF.ADD、BF.EXISTS |
场景选择原则： 优先使用 Redis 原生数据结构解决问题，避免在应用层模拟复杂逻辑。例如用 Sorted Set 做延时队列比用 List + 轮询更优雅，用 Stream 做消息队列比用 Pub/Sub 更可靠。