我记得第一次认认真真把 Redis 用起来跟 Redis 本身没什么关系是被一个接口慢查询逼的。表里就几万条数据MySQL 查询也走了索引但接口平均响应时间还是到了 800 多毫秒。后来查了半天发现是每次请求都在重复查同一份几乎不变的配置数据。把这段数据丢进 Redis接口响应直接掉到 20 毫秒以内。那一刻我才意识到很多人面试题里背得滚瓜烂熟的缓存数据库真正解决的是性能场景下的数据访问效率问题。这篇内容写给刚接触 Redis、或者已经敲过 set/get 但还没形成体系的人。我会从它到底解决了什么问题讲起把安装、五种核心数据类型、持久化、缓存问题、主从哨兵、分布式锁这些高频接触点全部串一遍最后给一条适合自学的路径。既然是初识我不会堆特别偏的源码细节但会把真正影响你后续使用和理解的概念讲透。1. Redis 到底是什么先搞清楚它凭什么是快1.1 一个内存和一个磁盘的差距有多大Redis 最核心的标签就是基于内存。内存的随机读取延迟大概是 100 纳秒级而 SSD 磁盘的随机读取延迟是 100 微秒级传统机械硬盘更慢能做到 10 毫秒就算不错。纳秒、微秒、毫秒每一级都差了 1000 倍。也就是说同样的数据放在内存里读比放在磁盘上快几个数量级。这个差距不是靠优化 SQL、加索引能抹平的这是存储介质的物理特性决定的。打个比方磁盘就像一个档案室数据都归档在文件柜里每次要资料都得跑一趟档案室去翻内存就像你的办公桌经常用的文件直接摊在桌面上抬手就能拿到。Redis 做的事情就是把一批高频使用的数据从档案室搬到办公桌上。但快只是结果不是设计目标。Redis 的设计目标是提供一套高效的数据结构操作接口让开发者可以用极简的命令去操作内存中的数据。1.2 Redis 和 MySQL 从来不是二选一初学的时候最容易产生一个误解有了 Redis 是不是可以不用 MySQL 了完全不是。Redis 是数据结构的服务器MySQL 这类关系型数据库是持久化存储和复杂查询的底座。它们的分工是维度RedisMySQL 等关系型数据库存储位置主要内存磁盘仅做持久化磁盘为主数据模型key-value 加多种数据结构二维表、SQL、事务响应速度亚毫秒级毫秒级起步数据容量受内存限制单机一般几十 GB 量级可扩展到 TB 级甚至更大典型定位缓存、计数器、队列、排行榜业务数据的最终存储和复杂查询所以更准确的理解是MySQL 负责数据的家Redis 负责数据的快车道两个配合使用。比如用户信息落库在 MySQL读接口先把 Redis 查一遍没有再从 MySQL 加载并回填到 Redis这就是最常见的旁路缓存策略。1.3 哪些场景天然适合用 Redis我自己的经验是判断一个场景适不适合上 Redis就问一句这数据是不是被高频读、写简单、对一致性要求不那么苛刻满足的话基本都可以考虑。常见的典型应用有热点数据缓存配置、商品详情、用户会话读了以后短时间内变化不大。计数器点赞数、播放量、库存扣减用 INCR/DECR 一条命令完成原子操作。排行榜ZSet 天然按分数排序游戏排行榜、热销榜直接用一个 key 就能维护。分布式场景协调分布式锁、幂等控制、限流计数器后面单独展开。消息通信List 的阻塞弹出可以实现轻量级队列不需要立刻上 Kafka 这类重量级 MQ。临时时效数据验证码、限时优惠设置过期时间即可自动清理。理解了Redis 是因为什么被需要以后再去装环境、敲命令整个学习过程会顺畅很多。很多人学 Redis 学得痛苦就是因为一上来死记命令却不知道每一条命令在真实系统里解决什么问题。2. 把 Redis 跑起来安装、启动图形客户端、连接验证我见过太多人卡在第一步。其实现在安装 Redis 的路径很成熟我分别说三种常见方式你自己按环境选。强调一句学习阶段不要纠结安装最新版6.x 已经非常稳定很多生产系统还在用 6.2拿来入门完全够用。2.1 最省事的开发环境方案Docker 一条命令如果你的电脑上有 Docker这是我认为最干净的启动方式不会在系统里留下各种编译依赖。docker run -d \ --name redis-dev \ -p 6379:6379 \ -v redis-data:/data \ redis:7.2 \ redis-server --appendonly yes拆开解释一下-p 6379:6379把容器里的 6379 端口映射到宿主机这样本地客户端可以直接连。-v redis-data:/data是挂载数据卷。Redis 做持久化时会把 RDB/AOF 文件写到容器内的/data目录挂载出来可以防止容器删除后数据全丢。redis-server --appendonly yes覆盖容器默认启动命令开启 AOF 追加持久化。开发环境这么做能避免你重启容器之后发现 key 全没了而一脸懵。启动后用docker ps看容器状态再用docker logs redis-dev看启动日志出现Ready to accept connections tcp就说明起来了。如果你要用 Docker Compose 管理对应配置大概是这样的services: redis: image: redis:7.2 container_name: redis-dev ports: - 6379:6379 volumes: - redis-data:/data command: [redis-server, --appendonly, yes] volumes: redis-data:开发学习阶段没必要指定特别复杂的配置等理解主从、哨兵之后再对照生产环境去补齐密码、持久化策略和内存上限那部分我会在第 5 节专门讲。2.2 Windows 本机安装注意官方支持和移植版的区别Redis 官方网站其实从来没有提供过 Windows 原生安装包这一点很多人不知道。Windows 上跑的 Redis 基本都是微软存档的移植版或者第三方的二次封装版本。所以在搜索redis windows 下载的时候你会看到各种版本质量参差不齐。我的建议是优先考虑两种方式WSL 或者 Docker Desktop在 Windows 里起一个 Linux 环境跑官方版 Redis行为最接近生产环境学习过程中遇到问题和网上资料对得上。Memurai一个兼容 Redis 协议的 Windows 原生实现日常学习和轻量使用可以接受但版本演进和 Redis 官方有差距。如果你只是想在 Windows 图形界面里点点点很多Redis 安装包其实还会捆绑 Redis Desktop Manager 这类可视化工具下载时注意看来源尽量选知名度高的站点避免装到带广告的打包版。Windows 本机装的本质是练习环境不是生产目标所以不用花太多时间纠结装得对不对能启动、能连接就够了。顺带推荐一下我的习惯学习阶段我更喜欢直接用命令行redis-cli操作图形工具用来看数据和排查问题。命令行会让你对命令本身更敏感否则很容易陷入只会点点点不知道底层发了什么命令的状态。2.3 源码编译安装Linux 服务器上的标准姿势如果你有一台 Linux 服务器或者云主机源码编译安装是最接近官方推荐的方式。整个过程很直白wget https://download.redis.io/releases/redis-6.2.14.tar.gz tar xzf redis-6.2.14.tar.gz cd redis-6.2.14 make make install编译完成后redis-server和redis-cli会安装到/usr/local/bin。然后可以直接启动redis-server --daemonize yes --protected-mode yes --requirepass yourpassword这里提醒两个入门阶段特别容易踩的坑。第一不要裸奔。Redis 默认绑定所有网卡并且没有密码如果你在云服务器上这么跑外网扫描工具扫到 6379 端口几分钟就能被入侵这就是网上一直在说的 Redis 未授权访问漏洞。生产环境必须设置requirepass并且把bind改成内网 IP 或 127.0.0.1同时保持protected-mode yes。第二编译前先确认系统里有gcc。缺少编译器的时候执行make会报错而不是给你什么友好的提示。CentOS 上用yum install -y gccUbuntu/Debian 上用apt install -y build-essential装完再 make 一般就通过了。2.4 可视化客户端怎么选RDM 和 Another Redis Desktop Manager命令行跑通之后你大概率会想找个图形工具看数据。Redis Desktop Manager 是老牌工具最初是免费开源的后来变成了商业软件现在是官方推出的 Redis Insight 接过了官方可视化客户端的位置。另一个选择是开源的 Another Redis Desktop Manager界面更现代社区活跃Windows/macOS/Linux 都能跑。客户端适用场景说明redis-cli日常命令学习、生产排查最可靠任何环境都有Redis Insight官方推荐的可视化工具支持数据浏览、命令行、性能分析Another Redis Desktop Manager轻量开源客户端连接管理方便适合多实例场景可视化工具连接的时候最常遇到的问题就是连不上。顺序排查第一Redis 是不是只绑定了 127.0.0.1如果是外部工具肯定连不上需要改 bind第二密码是否填写正确Redis 的密码在客户端里一般填在Password或Auth字段第三云服务器安全组和防火墙有没有放行 6379 端口这个进云控制台看。2.5 启动后的第一个自检流程我建议装完不要急着背命令先做三个验证确认你的 Redis 真的处于健康可用的状态# 1. 检查服务是否存活 redis-cli -a yourpassword ping # 应该得到 PONG # 2. 写入和读取 redis-cli -a yourpassword set hello redis redis-cli -a yourpassword get hello # 3. 看当前有多少 key redis-cli -a yourpassword dbsize命令里的-a是密码参数如果你没设密码就去掉。顺便提醒-a在命令行里会把密码暴露在终端历史和进程列表里生产环境排查时不建议用一般用REDISCLI_AUTH环境变量或者登录后交互输密码学习环境就无所谓了。3. 五种基本数据类型每个命令背后都是一个真实场景Redis 的五种数据类型几乎是所有面试题和项目里都会出现的基础但单纯背命令列表没什么意义。我按场景 - 命令 - 为什么用这个类型来讲这样你合上文章之后才能真的在项目里判断该用哪种。3.1 String缓存、计数器和一切简单的值String 是最基础、使用率最高的类型value 可以是字符串、数字、甚至是序列化后的对象。它适用的场景通常一句话能说完一个 key 对应一个简单值。缓存场景最典型SET user:profile:10086 {name:张三,level:5} GET user:profile:10086注意这里我是手动写了一个 JSON 字符串。真正在业务代码里这个 JSON 一般是对象序列化后的结果后面第 4 节讲序列化时再展开。String 还有个容易忽略的杀手级能力自增自减是原子的。INCR article:read_count:99 INCRBY article:read_count:99 100 DECR stock:sku_123所谓原子就是多个客户端同时执行 INCR 也不会互相覆盖。你在高并发场景下做计数器、库存扣减、生成自增序号直接用 INCR 就行这比先 GET 出来、程序里加一、再 SET 回去安全得多后者在并发下一定会丢更新。3.2 Hash存一个对象的多个字段比 String 更合理用户信息如果用 String 存整个 JSON改一个字段就得把整个对象取出来、反序列化、改完再序列化、再写回非常浪费。Hash 类型天然适合这种对象结构每个 key 下面可以挂多个 field-value 对。HSET user:10086 name 张三 level 5 HGET user:10086 name HGETALL user:10086 HINCRBY user:10086 level 1你看HINCRBY可以直接对对象里的某一个字段做原子自增这在 String 场景里要写一堆代码才能做对。购物车也特别适合 Hashuser:cart:10086 这个 key 下field 是商品 IDvalue 是加入数量加购、改数量、删商品都只需要操作一个字段。我的判断原则是如果一个 key 下面的数据是多个子字段而且你会单独读写其中某些子字段优先考虑 Hash而不是无脑 JSON 塞进 String。3.3 List队列和时间线List 底层是链表结构两头操作的效率都很高。最常用的两个场景消息队列和时间线列表。生产者把消息推到左边消费者从右边阻塞弹出# 生产者 LPUSH task_queue task:1 task:2 # 消费者 BRPOP task_queue 0BRPOP的 B 是 blocking如果没有数据会阻塞等待而不是立刻返回0 表示永不超时。这个模式可以搭一个最简单的可靠队列任务被消费后就从列表里移除不会重复消费。当然它没有 RabbitMQ 那套 ack、重投机制理解成轻量队列就好。时间线场景更适合用LPUSH往头部插再用LRANGE分页取LPUSH user:timeline:10086 发布了一篇文章 LRANGE user:timeline:10086 0 9List 还经常用来做最新公告、操作日志这类只关心最近 N 条的数据LTRIM key 0 99可以把列表裁剪到最近 100 条避免无限增长。3.4 Set去重、交并集与标签系统Set 是不重复且无序的集合。它最值钱的能力是集合运算。最简单的场景是抽奖把所有参与用户 ID 放进一个 SetSRANDMEMBER随机抽一个SPOP随机抽完并从集合移除。SADD lottery:20240601 user_1 user_2 user_3 SRANDMEMBER lottery:20240601 1更实用的是交友/推荐系统的交集场景。用户 A 关注了 {a,b,c}用户 B 关注了 {b,c,d}两个人的共同关注用一条命令SINTER user:follow:A user:follow:B结果就是 {b,c}。类似地SUNION做并集比如给两个人推荐他们关注过的所有大 VSDIFF做差集比如我关注了你但你没关注我。这种多集合运算要在 MySQL 里实现往往需要 join在 Redis 里就是一个命令的事。3.5 ZSet排行榜和时间序最优雅的解法ZSet 是 Set 的有序版本每个成员关联一个 scoreRedis 按 score 自动排序。排行榜就是为它量身定做的场景。ZADD rank:game:100 100 user_a ZADD rank:game:100 200 user_b ZINCRBY rank:game:100 50 user_a ZREVRANGE rank:game:100 0 9 WITHSCORESZINCRBY可以实时加分ZREVRANGE取出分数最高的前 10 名。要取某个人的排名ZREVRANK要按分数区间筛查ZRANGEBYSCORE。ZSet 还有一个很多人没想到的用法延迟队列。把任务的执行时间戳作为 score用ZRANGEBYSCORE key 0 当前时间戳拉取到期的任务配合定时轮询就能实现N 秒后执行这种轻量定时能力。这里的核心思想是把时间纬度编码成 score数据结构就拥有了排序和范围查询能力。3.6 选择数据类型的通用判断方法我经常跟朋友说不要拿着类型列表去套场景要反过来先画一个数据存取流程然后看它对单个字段顺序去重排序分别是什么要求。只有一个 valueString一个对象字段会被单独改Hash有顺序、只关心头尾List要去重、要做交并差Set要按某个分数排序、实时更新排名ZSet这套判断方法比背命令可靠得多。等你真的用熟悉了再看 Redis 的位图、流等高级结构都会轻松很多。4. 初学阶段必须搞懂的四个机制持久化、过期、淘汰、序列化很多人学 Redis 学到一半会卡住原因很统一前面 set/get 玩得很爽但一旦涉及重启、内存爆掉、Java 代码里存取数据出乱码就开始一脸懵。这四个机制是初学阶段的拦路虎也是面试问得最多的点。4.1 为什么一重启数据就没了RDB 和 AOFRedis 默认对持久化是有配置的但很多人并不清楚数据存在内存里和数据会写进磁盘是两回事。如果关闭了持久化Redis 一旦重启内存清空所有 key 全部消失。Redis 提供了两种持久化方案RDB按时间间隔生成内存数据快照优点是恢复快、文件紧凑缺点是如果刚好在两次快照之间宕机会丢失最后一次快照之后写入的数据。AOF把每一条写命令追加到日志文件恢复时重放命令。AOF 比 RDB 丢数据少但文件更大、恢复更慢。生产环境的常见做法是两者同时开启或者至少开启 AOF并配合appendfsync everysec每秒刷盘一次最多丢一秒数据。开发环境我用 Docker 启动时加--appendonly yes也就是这个原因。我这个建议非常直接学习阶段也从一开始就开启 AOF 持久化。否则你某天敲了一堆数据重启容器发现全没了很容易误以为 Redis 坏了实际上只是持久化没开。4.2 过期清理和内存淘汰Redis 是怎么处理放不下的数据给 key 设置过期时间是缓存场景的基本操作SET verify:code:18800001111 123456 EX 300EX 300表示 300 秒后过期。过期后的 key 是什么时候被删除的Redis 用的是惰性删除加定期删除的组合。惰性删除是指访问到这个 key 时才发现它过期了顺手删掉定期删除是指后台周期性地抽查一批 key 并清理过期的。听起来有点绕但结论很简单过期的 key 不一定会立刻消失但你 GET 它的时候不会拿到过期数据。更关键的是内存淘汰策略。如果你设置了maxmemory当内存达到上限Redis 需要决定踢掉哪些 key。常见的策略有策略行为noeviction不淘汰写入报错默认allkeys-lru从所有 key 中按最近最少使用淘汰volatile-lru从设置了过期时间的 key 中按 LRU 淘汰allkeys-lfu按访问频率淘汰volatile-ttl优先淘汰剩余时间最短的 key如果没有特殊要求我一般建议线上配置maxmemory-policy allkeys-lru意思就是内存快满时优先淘汰最久没用的 key这对缓存类业务最友好。需要明确的是LRU 是近似 LRURedis 不会为每个 key 都维护精确的最近访问时间而是采样后估算但这在生产中已经足够有效。4.3 序列化为什么存进去的是对象取出来是一堆乱码这是使用 Redis 客户端时最典型的困惑。你往 Redis 里存一个 Java 对象打开可视化工具一看value 是一串以\xAC\xED开头的乱码key 也可能变成\xAC\xED\x00\x05t\x00...这种。原因是默认的RedisTemplate用的是 JDK 序列化会把 Java 对象序列化成二进制。Redis 本身不管你存的是字符串、JSON 还是二进制它都当成字节数组存下来。所以乱码其实不是 Redis 的故障是序列化方式的选择问题。解决思路分两种自己手动序列化把对象转成 JSON 字符串再存业界主流用 Jackson、Gson、Fastjson取出来再反序列化。配置统一的 RedisTemplate 序列化器把 key 的序列化器改成 StringRedisSerializervalue 的序列化器改成 GenericJackson2JsonRedisSerializer。用 Spring Boot 时StringRedisTemplate默认就是字符串存取适合纯字符串场景如果你用RedisTemplate操作对象一定要理解序列化器配置。否则你写的缓存Java 服务自己能读但跨语言、跨系统、可视化排查时全是二进制调试成本极高。4.4 缓存穿透、击穿、雪崩三个名字像、原因不同的问题Redis 做缓存后第一个要学会的治理思路就是区分这三个词因为它们经常同时出现在网上但病因和治疗方案完全不同。缓存穿透查一个不存在的 key缓存里没有数据库里也没有每次请求都打到数据库相当于缓存失效。解决思路空值也能缓存一段时间或者用布隆过滤器先把不存在的 key 挡在外面。缓存击穿某个热点 key 突然过期大量并发请求同时打到数据库。解决思路热点数据尽量不过期或者用互斥锁只让一个请求去回源数据库。缓存雪崩大量 key 在同一时刻过期或者 Redis 整体不可用导致数据库被压垮。解决思路给过期时间加一个随机范围避免集中过期做高可用避免单点。我见过不少简历上写解决了缓存雪崩但问具体场景和代码对方很难说清。我的理解是这三个问题对初识 Redis 的人不是要求你现在就设计多复杂的方案但你至少要知道缓存并不是加一层就万事大吉这层的稳定性和数据一致性都会引入新的问题。缓存治理是一个持续的事情后面我会单独写更深的案例。5. 从单机到生产架构主从、哨兵、分布式锁和部署注意一个 Redis 实例学完你会发现它是单线程的、有内存上限的、可能会有单点宕机风险的。生产环境里Redis 很少是一台裸实例跑到底。所以初识阶段也要对主从、哨兵、分布式锁这些进阶概念有个整体印象以后真正部署时才不会慌。5.1 主从复制读写分离和数据备份主从复制是 Redis 高可用和扩展读性能的基础。简单说一个主节点负责写多个从节点复制主节点的数据读请求可以分散到从节点上。配置从节点的方式# 在从节点的 redis.conf 里 replicaof 192.168.1.10 6379 # 如果主节点有密码 masterauth yourpassword配置完后从节点会同步主节点数据。同步分两个阶段第一次是全量同步主节点生成 RDB 快照发给从节点之后是增量同步主节点把后续写命令传播给从节点。主从复制解决的核心问题有两个一是读写分离把读压力分散二是数据备份主节点挂了从节点上还有一份数据。但它不解决故障自动切换的问题主节点真挂了从节点不会自己上位这就需要哨兵。5.2 哨兵模式故障自动切换哨兵Sentinel是一个独立进程专门盯着主从节点。当主节点不可达哨兵会发起故障转移把一个从节点提升为新主节点并通知其他从节点和客户端。网上常见的哨兵模式启动未生成 known-sentinel 文件这类问题大概率和哨兵配置、日志路径相关。我自己的经验是排查顺序应该是先确认哨兵配置文件里的sentinel monitor mymaster 主节点IP 主节点端口 quorum这一段 IP 是否填写正确再确认哨兵进程对配置目录有没有写权限。很多时候不是逻辑问题是配置里的 IP 写成了 127.0.0.1导致哨兵之间没法互相发现。学习阶段搭建哨兵建议至少启动 3 个哨兵实例quorum 设为 2这样更贴近生产也能看到少数服从多数是怎么工作的。但说实话手动搭一遍只是为了理解原理真正的生产环境现在越来越多团队直接交给云厂商的托管 Redis 或者 Kubernetes 里的 Operator 去管理人工搭哨兵的机会并不多了。理解了原理再去看托管方案会非常快。5.3 分布式锁SETNX 只是起点Redis 做分布式锁最朴素的思路是用SETNX意思是如果 key 不存在才设置成功。多个服务抢锁谁 SETNX 成功谁拿到锁用完删 key 释放。SET lock:order:10086 unique_token EX 30 NX这条命令同时做了三件事设置锁、设置过期时间、只在不存在时设置。EX 30是锁的超时时间NX是 not exists。为什么一定要放在一条命令里因为假设你分两步SETNX lock:order:10086 token # 第一步 EXPIRE lock:order:10086 30 # 第二步如果第一步成功、第二步之前服务宕机或网络抖动锁没有过期时间就会变成死锁所有拿锁的请求全部卡死。所以一定要在一个原子操作里完成加锁 过期时间这也是面试里特别喜欢埋的坑。还有两个细节初学阶段最好就养成正确习惯。第一value 要放一个唯一标识比如 UUID释放锁的时候先比对是不是自己的锁再删除避免把别人后来拿到的锁删了。第二过期时间到了但业务还没执行完就需要看门狗机制自动续期这个在 Redisson 里已经有成熟实现。分布式锁的坑很多很细但理解SETNX 过期时间是理解一切的基础。5.4 生产环境部署 Redis 的几个底线配置很多跟着教程学完的同学第一次自己用 Docker Compose 部署 Redis 时只写了端口映射就完事。这里我给一份我常用的最小生产配置模板你可以在理解每个配置的含义之后再调整services: redis: image: redis:7.2 container_name: redis-prod restart: always ports: - 127.0.0.1:6379:6379 volumes: - ./redis-data:/data - ./redis.conf:/usr/local/etc/redis/redis.conf command: [redis-server, /usr/local/etc/redis/redis.conf]对应的redis.conf里至少要包含requirepass your-strong-password bind 127.0.0.1 protected-mode yes appendonly yes maxmemory 2gb maxmemory-policy allkeys-lru几个配置的考虑端口映射写成127.0.0.1:6379:6379意味着只允许本机访问应用服务器和 Redis 在同一台机器时这么干最安全。如果 Redis 和应用不在同一台机器就把 bind 和端口暴露策略结合实际情况设置同时用云安全组限制来源 IP。protected-mode yes加requirepass杜绝未授权访问。maxmemory必须设置否则内存被写爆操作系统 OOM 把 Redis 进程杀掉比淘汰旧数据更难看。这一节的内容对于初识来说可能有点密。我的想法是你不需要立刻全消化但至少要建立这个意识单实例能跑通只是第一步Redis 在真实系统里一定是配合高可用、安全、容量规划一起出现的。6. 一条靠谱的 Redis 学习路径与面试知识点梳理6.1 从命令到框架再到一个完整项目如果你完全从零开始我建议的学习顺序是这样每个阶段都配了明确的出口环境阶段用 Docker 起一个 Redis装载到 Redis 官方以 docs 为主的资料学会redis-cli的基本操作。这个阶段结束时你应该能自己配置密码、开启持久化、用 RDM 或 Another Redis Desktop Manager 看到数据。数据结构阶段把 5 种基本类型全都实际敲一遍重点是给每种类型找一个你曾经在项目里真实遇到过的场景。代码集成阶段用你熟悉的语言写一个最简单的缓存工具类。Java 方向就是理解StringRedisTemplate和RedisTemplate的区别以及序列化器怎么配。进阶机制阶段搞懂 RDB/AOF、过期淘汰、事务、管道 Pipeline、发布订阅。生产架构阶段搭建一主两从三哨兵模拟主节点宕机观察哨兵怎么完成故障切换。实战项目阶段把缓存穿透/击穿/雪崩的治理手段、分布式锁用到你自己的项目里。网上比较经典的实战演示项目里黑马点评这类带完整前后端和 Redis 应用的课程对初学者很友好还有些朋友会跟着视频课手写一个秒杀项目把库存预减、限流、分布式锁全部练一遍效果也非常好。我个人不建议一上来就去读源码。先做到能用、知道为什么这么用再考虑源码细节。否则你看着源码里的跳跃表、字典结构大概率是劝退而不是提升。6.2 面试高频点初识阶段就要有个思维框架Redis 是后端面试的常客但面试官其实不是要你背八股而是看你能不能把一个概念说清楚、能不能对比选型。我把常见的考察点整理成一份自查表考察方向核心问题初学至少要能说出数据结构String/Hash/List/Set/ZSet 区别每个类型对应什么场景为什么要用它持久化RDB 和 AOF 优缺点什么时候会丢数据恢复速度差异过期与淘汰过期 key 怎么删除内存不够怎么办惰性删除定期删除常用淘汰策略缓存问题穿透、击穿、雪崩分别是什么能说出区别和一个简单解决方案分布式锁SETNX 为什么不能拆成两步原子操作、过期时间、唯一标识高可用主从、哨兵、集群的关系主从解决复制、哨兵解决自动切换性能为什么快单线程为什么快内存、IO 多路复用、避免上下文切换把这些能用自己的话讲清楚Redis 面试这一块基本就稳了更重要的是你对 Redis 的真实使用场景会有一个成体系的认知。6.3 学会自我排查监控命令和调试工具初学者最容易忽略的是学习阶段就养成用 Redis 自带的运维命令看问题的习惯。这几个命令我认为很值得记ping确认连接正常。info看内存、连接数、持久化状态、复制信息重点看memory和replication段落。MONITOR实时打印 Redis 收到的每一条命令调试代码里到底发了什么请求特别好用。注意生产环境不要随便开着有性能开销。slowlog get查看慢查询日志命令执行超过slowlog-log-slower-than阈值就会被记录。redis-cli --bigkeys扫描大 key找到占用空间不正常的对象生产排查经常用到。有一次我定位线上缓存问题发现某个 key 的 value 有几十 MB就是靠--bigkeys扫出来的。这种工具类命令不需要背得很全但你要知道自己能通过哪些路径获取 Redis 的运行状态。写到这里Redis 的初识地图基本就画完了。从我自己的体会来说Redis 是一门实践反馈极其直接的技术——你装好、敲命令、写代码立刻能看到性能变化和数据结构带来的便利。但它也是一门越深入越复杂的技术从单机到高可用从缓存到分布式协调每一个方向都能延伸出大量实战细节。如果你现在刚起步我的建议很简单先把今天这篇里的命令亲手敲一遍再找一个你项目里的真实场景把代码改成用 Redis 实现。不要贪多不要急着把集群、分片、源码全部看完先把用起来这件事做扎实。后面你会发现那些曾经觉得深奥的概念当你真的遇到了一次缓存穿透、一次主从切换、一次分布式锁的并发事故之后也就自然而然理解了。