Redis 系列 · 第 01 篇——认知入门：Redis 是什么

从高性能缓存到内存数据基础设施

一、导读：Redis 是什么

1.1 一句话认识

Redis（Remote Dictionary Server，远程字典服务）由 Salvatore Sanfilippo（antirez）于 2009 年发布，是一款开源的、基于内存的高性能键值数据库。它以「键---值」模型存储数据，但远不止字符串------支持 String、Hash、List、Set、ZSet 等多种数据结构，兼具缓存、数据库与消息能力。

1.2 从缓存到内存数据基础设施

传统印象里，Redis 常被当作「高性能缓存」。随着版本演进，它的定位早已扩展为内存数据基础设施，官方明确为三大场景：Cache（缓存）、Database（数据库）、Vector Search（向量搜索）。在双十一洪峰、社交点赞、实时排行榜等场景背后，几乎都有 Redis 的身影。

二、为什么 Redis 快

Redis 能支撑每秒数十万级 QPS，并非单一原因，而是存储介质、线程模型、网络模型与底层数据结构共同作用的结果。

2.1 内存存储

Redis 数据常驻内存，读写避开磁盘 IO。内存访问延迟在纳秒级，比固态硬盘（微秒级）快约三个数量级，比机械硬盘（毫秒级）快约六个数量级。这是「快」的根本。

2.2 IO 多路复用

Redis 通过 IO 多路复用，让单个线程同时监听大量客户端连接，仅在有数据就绪时才处理，避免了「每连接一线程」的资源浪费。Linux 下基于 epoll，macOS / BSD 用 kqueue，Solaris 用 evport，底层经 ae 抽象层统一封装，select 仅作备选。

2.3 单线程模型与多线程 IO

Redis 核心命令执行是单线程的，从而消除了上下文切换与锁竞争的开销，代码简单、易维护。自 Redis 6.0 起引入多线程处理网络 IO（把数据包收发分摊到多核），但核心命令执行仍保持单线程。理解这个模型，才能正确看待 Redis 的并发能力与瓶颈。

2.4 针对性的底层数据结构

Redis 对每种数据类型都做了极致的内存级优化，而非直接使用语言内置结构。例如 String 用 SDS 避免 C 字符串反复扩容与长度计算，ZSet 用「跳跃表 + 哈希表」兼顾范围查询与按成员快速查找分值。

三、核心能力

3.1 丰富的数据结构

Redis 提供了远超普通键值库的数据结构，适配不同业务形态。每种数据类型的底层实现还会按元素数量与大小自动切换编码，小数据用紧凑结构省内存，大数据切换为通用结构。

|------------|--------------------|---|---|
| 类型 | 底层主要实现 | 典型场景 ||
| String | SDS / int / embstr | 缓存对象、计数器、分布式锁（SETNX） ||
| Hash | 紧凑表 / 哈希表 | 对象与字段存储、用户信息、购物车 ||
| List | QuickList | 消息队列、时间线顺序存储 ||
| Set | 整数集合 / 哈希表 | 去重、共同好友、抽奖 ||
| ZSet | 跳跃表 + 哈希表 | 排行榜、按时间戳的定时任务、优先级队列 ||
| Stream | 紧凑列表等 | 高可靠消息队列、日志采集 ||
| SET user:1001 "Tommy" # String |||
| RPUSH msg:queue "hello" # List |||
| SADD tags:1001 "运维" "DBA" # Set |||
| ZADD rank:2026 98 "Tommy" # ZSet，98 为分值 |||

3.2 持久化：RDB 与 AOF

内存存储带来速度，也带来丢数据的风险。Redis 提供两种持久化：

RDB：定时生成内存快照，恢复快，但可能丢失两次快照之间的数据。
AOF：追加记录写命令，数据更可靠，可配合 rewrite 压缩日志。

生产环境常两者配合使用，权衡恢复速度与数据可靠性（细节在系列后续篇展开）。

3.3 高可用三部曲：复制、哨兵、集群

|------------------|----------------|----------------------|---------------|
| 方案 | 数据分布 | 故障处理 | 适用场景 |
| Replication 主从复制 | 单主多从，全量 / 增量复制 | 需人工切换 | 数据备份、读写分离、小流量 |
| Sentinel 哨兵 | 单主多从 | 哨兵仲裁自动选主（约 10~30 秒） | 中小流量生产高可用 |
| Cluster 集群 | 多主多从，16384 槽分片 | 从节点自动晋升 + 数据迁移 | 海量数据、高并发水平扩展 |

三层职责不同：复制解决「数据有副本」，哨兵解决「自动切换」，集群在分片扩展的基础上叠加高可用。细节在架构篇展开。

3.4 高级特性

过期与淘汰：支持 TTL 过期删除与多种内存淘汰策略。
事务与 Lua：MULTI / EXEC 简单事务，Lua 脚本保证复杂操作原子性。
发布订阅与 Stream：实现消息解耦。
分布式锁：基于 SETNX 的可靠分布式互斥。

四、适用场景与边界

4.1 典型适用场景

|------------|------------------|---------------------|
| 场景 | 使用的结构与命令 | 说明 |
| 缓存 | String / 读写分离 | 热点数据前置，缓解数据库压力 |
| 会话管理 | String / Hash | Session 共享、Token 存储 |
| 实时计数 | INCR / DECR | 点赞、访问量、库存扣减 |
| 排行榜 | ZSet | 按分值排序的实时榜单 |
| 分布式锁 | SETNX + Lua | 高并发互斥、限流 |
| 消息队列 | List / Stream | 轻量异步解耦、日志采集 |

4.2 不适用场景

强一致核心账务：Redis 默认主从异步复制，故障切换可能短暂丢失数据，核心交易仍需关系型强一致保障。
复杂查询与多表关联：Redis 无 SQL，复杂条件查询与关联能力弱，不适合作为唯一数据源做报表分析。
海量冷数据存储：数据驻留内存，存储成本高，不适宜存量大、访问低频的冷数据。

4.3 定位：性能放大器

Redis 适合把业务中最热的数据推到离 CPU 更近的位置，作为「性能放大器」与关系型数据库协作，而不是取代关系型。把账务、强关联数据盲目塞进 Redis，往往得不偿失。

五、版本、许可与生态

5.1 版本演进与许可变迁

Redis 授权协议几经变化：最初采用 BSD 许可；2024 年 3 月转为 SSPL，这一改动引发社区担忧，衍生出 Valkey 等开源分支。2025 年 5 月，Redis 8 引入 OSI 认证的 AGPLv3 作为额外许可选项，重新回归真正开源，同时把此前 Redis Stack 的 JSON、时序、概率数据类型、查询引擎等能力并入核心，并新增向量集（Vector Set）数据类型，覆盖 AI 向量检索场景。

5.2 生态与替代

Redis 周边生态成熟：官方 Redis Insight 可视化工具、多语言客户端、Redis Enterprise / Cloud 企业版等。若对授权仍有顾虑，可评估开源分支 Valkey（Linux 基金会托管）与 KeyDB 等兼容替代。

六、Redis 系列篇目预告

本系列后续按统一结构展开，从本讲认知入门出发，逐层深入：

架构拆解：主从复制、哨兵、Cluster 三套架构的部署与原理。
核心原理：底层数据结构、持久化、过期淘汰、事务与 Lua。
部署实操：内网真机部署 + 高可用集群，含一键脚本。
选型对比：Redis 与 Memcached、Valkey、KeyDB 等横评。
避坑汇总：缓存穿透 / 击穿 / 雪崩、大 key、热 key 等经典问题。
调优实战：内存优化、性能压测与监控。

面试收官：高频面试题与全景总结。