参考资料
怎么用这份清单
本篇收拢这个系列会用到的官方入口和社区资源。遇到配置项拿不准、命令行为和记忆不一致时，按「官方文档 → 命令参考 → 源码/社区」的顺序查，别从二手博客开始。
官方网站与文档
- Redis 官网：项目主页，产品矩阵、下载入口、云服务入口都在这里。看新闻和版本发布节奏从这里进。
- Redis 官方文档：最权威的口径。安装、配置、持久化、复制、集群、安全各有一级目录，本系列的配置项解释基本都能在这里找到原文。
- 命令参考：每条命令的参数、返回值、时间复杂度、可用版本都列得清清楚楚。写完代码对一遍参数，比调试半小时快。
- 下载页：源码包和官方 apt/yum 仓库的入口，装 7.x 优先走这里给的仓库配置。
- Redis 安全文档：ACL、TLS、保护模式、危险命令禁用的官方说明，配安全基线时逐条对照。
- 分布式锁模式：官方对单实例锁、Redlock 的说明和争议回应，用锁之前建议读一遍。
源码与版本
- redis/redis：官方源码仓库，issue 和 PR 里能查到很多文档没写的边界行为。
- Releases：每个版本的变更日志，升级前必看，重点扫 breaking changes 和废弃项。
- 安全公告：CVE 和修复版本，做安全基线时按这里核对。
- Redis 3.0 源码注释：黄健宏的中文源码注释，版本老但数据结构、事件循环、持久化的实现思路仍然适用，读源码可以从这本开始。
- antirez 的博客：Redis 作者的个人博客，很多设计取舍（比如为什么单线程、为什么用跳表）有第一手解释。
客户端
- Jedis：Java 老牌同步客户端，API 直观，哨兵和集群都支持；连接池用
JedisPool/JedisCluster。 - Lettuce：Java 异步/响应式客户端，Spring Boot 2.x 之后的默认选择，基于 Netty，支持哨兵、集群、Resp3。
- redis-py：Python 官方客户端，
redis.Redis、RedisCluster、Sentinel三个入口覆盖常见部署形态。 - redis_exporter：把
INFO转成 Prometheus 指标，第 5 篇用的就是它，参数和指标清单以 README 为准。
工具
- RedisInsight：Redis 官方图形客户端，能看 key、跑命令、看慢日志和内存分析，排查大 key 很顺手。
- Another Redis Desktop Manager：开源跨平台客户端，轻量、启动快，日常看数据够用。
- redis-benchmark：Redis 自带的压测工具，评估实例吞吐和延迟基线时用，注意别在生产高峰跑。
- memtier_benchmark：Redis Labs 出的压测工具，支持更真实的读写比例和 key 分布，比
redis-benchmark更接近业务。
社区与资源清单
- Awesome Redis：社区维护的 Redis 资源大全，客户端、工具、教程、集群方案按类别收齐，找轮子先扫一遍。
- Redis University：官方免费课程，从入门到集群、数据结构都有，带练习环境，适合系统补基础。
- Stack Overflow 的 redis 标签：具体报错和行为疑问的搜索入口，提问前先搜，多数坑已经有人踩过。
- r/redis：社区讨论版，版本升级、运维事故、新特性讨论比中文资料快一步。
书与系统学习
- 《Redis 设计与实现》（黄健宏）：讲数据结构、持久化、复制、集群的实现原理，中文技术书里最扎实的一本，配合源码注释看效果最好。
- 《Redis 深度历险》（钱文品）：偏应用，把缓存、分布式锁、延时队列、限流这些场景串起来讲，适合业务开发快速建立全景。
- 官方文档的「Operate」章节：运维视角的完整手册，复制、哨兵、集群、持久化、内存优化都在这一块，比零散博客系统得多。
查文档的优先级
同一个问题，官方命令参考 > 官方运维文档 > GitHub issue > 社区博客。博客里的命令经常是 5.x 甚至 3.x 的写法，比如 SLAVEOF 现在叫 REPLICAOF、AOF 在 7.0 变成了多部分文件，照抄旧文章很容易踩坑。看到不确定的写法，回到命令参考确认可用版本。
版本与兼容性备忘
系列示例按 Redis 7.x 写，遇到老版本先对一下特性引入时间：
| 特性 | 起始版本 | 说明 |
|---|---|---|
UNLINK 异步删除 | 4.0 | 大 key 删除优先用它 |
LMOVE | 6.2 | 替代 RPOPLPUSH |
GETDEL | 6.2 | 取完即删，做一次性 token 方便 |
SMISMEMBER / ZMSCORE | 6.2 | 批量判断 / 批量查分数 |
| ACL 用户体系 | 6.0 | 替代单一 requirepass 的精细权限控制 |
SET ... KEEPTTL | 6.0 | 重设值时保留原 TTL |
| IO 多线程 | 6.0 | 只影响网络读写，命令执行仍单线程 |
| AOF 多部分文件 | 7.0 | appendonlydir + manifest，重写不再拼大文件 |
| Function（替代部分 Lua 场景） | 7.0 | 脚本随实例持久化，FUNCTION LOAD 管理 |
CLIENT NO-EVICT | 7.0 | 让连接缓冲区不被内存淘汰影响 |
SINTERCARD | 7.0 | 只算交集数量，不返回元素 |
从 6.x 升到 7.x 的检查点
- AOF 目录结构变了：7.0 起使用
appendonlydir，如果监控或备份脚本直接拷appendonly.aof，升级后会找不到文件。 replicaof和slaveof：两者都能用，脚本里建议统一成新名字。- 模块兼容：RedisBloom、RedisJSON 等模块要升到支持 7.x 的版本，否则加载失败、实例起不来。
- 客户端版本：老版本 Jedis/Lettuce 可能不支持 RESP3 或新命令，升级前在测试环境跑一遍。
- 从库的内存行为：
replica-ignore-maxmemory默认是yes，从库不主动淘汰，容量规划要按主库数据量留足余量。 - 升级顺序：先升从库、再升主库，或者用哨兵/集群的故障转移把主库切走再升，别两个节点同时重启。
术语对照
看英文文档时容易混的几个词：
| 英文 | 中文习惯叫法 | 说明 |
|---|---|---|
| master / replica | 主库 / 从库 | 5.0 起官方统一用 replica，SLAVEOF 改名 REPLICAOF |
| sentinel | 哨兵 | 独立的监控进程，不是 Redis 的数据节点 |
| slot | 槽 / 槽位 | Cluster 的 16384 个数据分片单位 |
| eviction | 淘汰 | 内存满时按策略删除 key |
| expiration | 过期 | key 到达 TTL 后被删除，和淘汰是两套机制 |
| fragmentation | 内存碎片 | used_memory_rss 与 used_memory 的差值来源 |
| fork / COW | 子进程 / 写时复制 | RDB、AOF 重写、全量同步都会用到 |
| big key | 大 key | 没有严格阈值，指元素多或体积大的单个 key |
| hot key | 热 key | 访问量集中在少数 key 上，容易打满单核 |
| cache avalanche | 缓存雪崩 | 大量 key 同时失效，请求全部回源 |
| cache penetration | 缓存穿透 | 查不存在的 key，每次都打到数据库 |
| cache breakdown | 缓存击穿 | 单个热点 key 失效，瞬间大量请求回源 |
三条学习路径
只做业务开发，够用就行：
- 读第 1 篇建立数据结构选型直觉。
- 跟第 2 篇装一个本地实例，把第 3 篇的命令敲一遍。
- 重点补分布式锁、缓存三大问题、Lua 限流这三块，其余用到再查。
要负责一套 Redis：
- 前 3 篇快速过，重点看持久化和过期淘汰。
- 第 4 篇按实际规模选主从/哨兵/集群，在测试环境完整搭一遍并演练切换。
- 第 5 篇把监控和告警接起来，第 6 篇的故障场景当成演练脚本。
要做架构选型或面试准备：
- 把单线程模型、持久化取舍、哨兵选主、Cluster 槽位这四块讲清楚。
- 能解释「缓存一致性」「分布式锁的坑」「大 key 的危害」背后的原因。
- 结合官方文档和源码注释，把「为什么这么设计」补上。
常见问题速查
| 现象 | 先看哪里 | 常见结论 |
|---|---|---|
| 写入报 OOM | INFO memory、CONFIG GET maxmemory-policy | 内存满或策略不淘汰 |
| 延迟周期性尖刺 | latest_fork_usec、rdb_last_bgsave_time_sec | fork + COW，或集中过期 |
| 连接被拒 | INFO clients、rejected_connections | 连接池过大或泄漏 |
| 缓存命中率低 | keyspace_hits/misses、TTL 设置 | TTL 太短、key 设计问题 |
| 主从数据不一致 | INFO replication 的 offset | 复制延迟或写入从库 |
| 集群报 CROSSSLOT | 命令涉及的 key | 多 key 不同槽，需 hash tag |
| 哨兵频繁切换 | 哨兵日志、down-after-milliseconds | 判定超时太短或网络抖动 |
排错时的检索顺序
碰到报错，按这个顺序走，通常十分钟内能定位：
- 先看报错原文。
OOM command not allowed、NOREPLICAS、CROSSSLOT、MOVED这些关键字直接搜官方文档或 issue，比描述现象准确。 INFO对应段。内存问题看memory，连接看clients，持久化看persistence，复制看replication，别一上来就重启。SLOWLOG GET。延迟类问题先排除慢命令，再看网络和客户端。- 对照命令参考确认版本。同一个命令在 6.x 和 7.x 的参数、返回值可能不同。
- 最后才考虑升级或改架构。多数故障是配置和使用方式的问题，不是版本 bug。
系列内导航
- 概念和整体架构：
01-核心概念与架构 - 安装与第一次连接：
02-安装与快速上手 - 命令、事务与 Lua：
03-核心使用 - 主从、哨兵、Cluster：
04-部署与高可用 - 指标、慢查询、内存治理：
05-运维与监控 - 故障排查与最佳实践：
06-故障排查与最佳实践 - 命令速查：
appendix/Redis 命令速查