Redis学习路线图:从数据结构到分布式集群的系统化技术指南 1. 先聊清楚Redis 到底值不值得花大把时间学这两年只要打开招聘网站后端相关岗位的 JD 上几乎都会挂着 Redis。问起到手能干什么很多新人第一反应是缓存数据库再往深了问——缓存穿透怎么解决、主从切换丢不丢数据、集群选型为什么不用哨兵——就开始含糊了。这不是个例。我见过不少写了三五年业务代码的开发Redis 停留在set/get层面项目一遇到大流量就抓瞎。标题里的redis学习目录看起来像一张零散的知识点清单实际上背后藏着一个问题Redis 的知识体系到底该怎么搭才能从会用走向用好。这篇文章我按自己的学习路径和踩坑经历把 Redis 从安装、数据结构、持久化、分布式锁到主从哨兵集群、SpringBoot 集成、缓存治理、面试高频题梳理成一条可执行的主线。它不是官方文档的复述而是实打实跑过、验证过、踩过坑之后整理出来的学习地图。适合三种人看刚接触 Redis 想系统入门的工作中经常用但没梳理过全貌的以及准备面试想查漏补缺的。先说一个反直觉的结论学 Redis 最忌讳按文档顺序从头读到尾。官方文档把命令按字母排列把数据结构一个个拆开讲看起来工整但你看完大概率还是不知道项目里该用哪个。正确的打开方式是场景倒推——先从业务问题出发比如用户会话为什么不能全放 MySQL双十一库存为什么不能靠数据库扣减带着问题去学那些命令和原理自然就串起来了。2. 安装、启动、可视化客户端这关卡住了太多初学者2.1 别再纠结 Windows 版了生产环境没人用这个redis 下载和redis windows 下载的热度一直很高这是初学者第一个容易陷进去的坑。Redis 官方并不提供 Windows 版本GitHub 上的 Windows 移植版停留在老版本主要用于本地开发调试生产环境基本都是 Linux。我刚开始学的时候也犯过这个错在 Windows 下装了 3.x 的移植版后面学持久化、学主从复制发现很多配置项对不上浪费了不少时间。正确的姿势是本地开发用 Docker服务器用 Linux。如果你机器上已经装了 Docker一条命令就能跑起来docker run -d --name redis \ -p 6379:6379 \ -v /data/redis:/data \ redis:7.0这里做了三件事后台运行、映射端口、把容器内的数据目录挂载到宿主机。挂载数据目录很关键不挂的话容器一删你辛辛苦苦写的测试数据全没了。Redis 的持久化文件默认存在/data目录RDB 快照和 AOF 日志都在里面挂载出来方便排查问题。2.2 启动命令和配置文件先搞清楚谁优先很多教程让你直接redis-server启动这在学习阶段够用但一到自定义配置就露馅了。Redis 启动时配置的来源有三个优先级从高到低命令行参数、配置文件、默认配置。# 指定配置文件启动 redis-server /etc/redis/redis.conf # 命令行参数覆盖配置文件 redis-server /etc/redis/redis.conf --port 6380 --maxmemory 256mb生产环境我强烈建议养成配置文件 命令行参数组合使用的习惯。把端口、密码、持久化策略、内存上限这些写进配置文件用版本管理工具管起来不要在命令行里临时堆参数——不然哪天上线的节点配置和别人不一样排查到天亮都找不到原因。2.3 可视化客户端怎么选redis desktop manager和another redis desktop manager这两个词搜索量一直居高不下。我的建议是学习阶段用一个顺手的工作阶段慢慢脱离它。Redis Desktop Manager老牌工具界面干净社区版够用但新版闭源后部分功能收费。Another Redis Desktop Manager开源免费功能上很像 RDM 的增强版支持多开、密钥树形展示、命令执行我目前主力用它。Redis CommanderWeb 界面浏览器打开就能用适合临时上服务器看一眼功能相对基础。用可视化客户端的时候有个小建议把它当成巡检工具而不是操作工具。flushall、del这种危险操作尽量在命令行里想清楚了再执行客户端界面上点错一下可能一整片缓存就没了。3. 五种核心数据类型别死记硬背用业务场景把它们焊死在脑子里3.1 String 和 Hash存储结构的选择决定了后续的维护成本String 是最基础的类型key-value 形式适合存序列化后的对象、计数器、验证码这类简单数据。Hash 是 field-value 的嵌套结构适合存一个对象的多个属性。举个例子用户信息缓存# String 方式序列化整个对象 SET user:1001 {name:张三,age:30,level:3} # Hash 方式 HSET user:1001 name 张三 age 30 level 3看起来差不多但差别在更新场景。用户等级变了String 方式要先把整个对象取出来、反序列化、改字段、再序列化写回Hash 方式一条HINCRBY user:1001 level 1就搞定了。数据量小的时候无所谓数据量大了这种细节就是性能和代码简洁度的分水岭。还有几个高频命令值得注意SETEX设置带过期时间的 key适合验证码INCR原子自增适合计数器SETNX是后面分布式锁的基础先记住它不存在才设置的语义。3.2 List 和 Set一个管顺序一个管去重List 底层是双向链表特点是有序、支持两端操作。常见场景是消息队列的简化版——用户发帖后把动态 IDLPUSH进用户的 feed 列表然后LRANGE分页拉取。但要注意Redis List 做的队列是轻量级的不支持消息确认、不支持延迟消息生产环境的消息队列还是交给 RabbitMQ 或 Kafka。List 更适合的场景是最近浏览记录操作日志这类丢几条无所谓的列表。Set 是无序去重集合场景非常明显点赞用户集合、关注关系、抽奖去重。SINTER求交集可以算共同关注SUNIONSTORE可以合并标签。还有一个容易被忽略的用法SPOP随机弹出元素做随机推荐的时候特别好用。3.3 ZSetRedis 里最值钱的数据结构ZSet 在 Set 基础上加了 score分数每个元素按分数排序。它是我认为 Redis 里投入产出比最高的一个知识点。排行榜是它最经典的应用ZADD leaderboard 100 user1 ZADD leaderboard 95 user2 ZADD leaderboard 120 user3 # 获取前三名 ZREVRANGE leaderboard 0 2 WITHSCORES # 获取某人排名 ZRANK leaderboard user2但 ZSet 能做的事远不止排行榜。延时队列可以用 score 存执行时间戳轮询ZRANGEBYSCORE取出到期的任务固定窗口限流可以用 score 存时间戳ZCOUNT统计窗口内请求数文章热度排序可以用 score 存点赞数 评论数 * 权重组合出来的热度值。每多接触一种业务你就会发现 ZSet 又多一种用法。学习这五种类型的时候我建议大家不要按类型去背命令而是按场景 - 数据结构 - 命令的路径去理解。遇到一个业务需求先想想它本质上是查最新去重排序计数还是存对象再对应到具体的类型上去。3.4 多余的数据类型布隆过滤器、HyperLogLog、Geo除了五种基础类型Redis 模块和扩展里还有几个高频选手。布隆过滤器解决缓存穿透问题用一个位数组判断这个 key 一定不存在能挡住大量恶意请求打到数据库。HyperLogLog 用极小内存做去重计数比如统计 UV独立访客量标准误差 0.81% 对大多数业务完全够用。Geo 类型存经纬度附近的人、门店距离排序直接用它。这些不是入门阶段必须掌握的但你要知道它们存在且解决什么问题。面试聊到怎么设计一个海量 UV 统计系统的时候能脱口而出 HyperLogLog这比背十道面试题都好使。4. 进阶必踩的四道坎持久化、内存淘汰、分布式锁、过期策略4.1 RDB 和 AOF数据能存多久取决于你怎么配置Redis 是内存数据库数据默认存在内存里不配置持久化的话重启就啥都没了。持久化有两种方式初学者必须搞懂它们各自的定位RDB快照把内存数据定期落盘成一个二进制文件。优点是恢复快、文件紧凑缺点是可能丢最后一次快照之后的数据。AOF追加日志把每条写操作追加到日志文件里。数据更安全但文件会越来越大恢复速度比 RDB 慢。生产环境通常是两个都开RDB 做冷备和快速恢复AOF 保证数据安全。配置上注意几个参数# 开启 AOF appendonly yes # 同步策略always 每条都同步 / everysec 每秒同步 / no 交给系统 appendfsync everysec # AOF 重写触发条件 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mbappendfsync everysec是默认也是推荐配置兼顾安全和性能。always最安全但性能损耗大no性能最好但可能丢好几秒数据。AOF 日志会越来越大Redis 提供了BGREWRITEAOF进行重写把日志压缩成恢复当前数据的最小命令集。我踩过一个坑把 AOF 关掉只开 RDB然后配置了save 禁用所有 RDB 触发条件等于两种持久化都没生效。后来线上服务重启缓存穿越直接把数据库打挂了。从那以后我养成了个习惯每次改完配置用redis-cli config get save确认一下真正生效的配置项。4.2 内存淘汰策略内存满了以后会发生什么Redis 默认不设内存上限但生产环境必须在配置文件里设maxmemory不然内存耗尽会触发系统 OOM Kill。设了之后当写入导致内存达到上限Redis 按maxmemory-policy决定怎么处理新写入# 不淘汰直接返回错误 maxmemory-policy noeviction # 从设置了过期时间的 key 里淘汰最近最少使用的 maxmemory-policy volatile-lru # 从所有 key 里淘汰最近最少使用的推荐 maxmemory-policy allkeys-lru # 从所有 key 里随机淘汰 maxmemory-policy allkeys-random这里有一个很重要的判断你的缓存是可完全重建还是不可丢失。如果是商品详情、用户资料这种能从数据库重建的用allkeys-lru没毛病如果是分布式锁、验证码这类关键状态被淘汰了会出大问题要确保它们不在淘汰范围内或者干脆换存储方案。4.3 过期删除策略过期 key 是怎么被清掉的过期 key 的清理不是时间一到立刻删除Redis 用的是惰性删除 定期删除的组合。惰性删除是访问这个 key 的时候检查是否过期过期就删定期删除是后台每 100ms 随机抽一批设置了过期时间的 key把过期的删掉。这个机制带来一个现象过期 key 可能占着内存到内存快满的时候才被淘汰掉或者明明已过期但还没来得及删EXISTS查它还会返回 1。做缓存治理的时候别指望设置了过期时间就万事大吉要结合刚才的内存淘汰策略一起看。4.4 分布式锁SETNX 和 Lua 脚本分布式锁是 Redis 面试逃不开的题。最基础的版本是SET key value NX EX 10——NX保证 key 不存在才设置EX设置过期时间防止客户端崩了锁不释放。然后再配一个 Lua 脚本保证判断是不是自己的锁 删除两步操作是原子的if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end为什么必须用 Lua因为GET 判断 DEL 删除两步之间如果线程切换可能出现锁过期了别人拿到了锁然后你把别人的锁删了的经典事故。Lua 脚本把两步合并成一步Redis 执行 Lua 脚本是原子的中间不会被其他命令插入。这套方案能解决大多数业务场景但它不是银弹。锁过期时间设置多长业务执行时间超过锁过期时间怎么办这时候要上看门狗续期机制。跨多实例怎么办要上 Redisson 或者 RedLock。学习顺序应该是先理解单机版问题再理解续期问题最后理解 RedLock 的争议和适用边界——面试官要的就是这个层层深入的过程。5. 从单机到集群主从、哨兵、Cluster 三种架构的关键差异5.1 主从复制读写分离的基础