1. 缓存到底是什么：先搞清楚Redis为什么值得学
1.1 一个让数据库"喘口气"的中间层
很多刚开始接触后端开发的朋友都会遇到同一个困惑：明明数据库已经能存数据了，为什么还要在它前面再塞一个Redis？直接查MySQL不行吗？这个问题当年我也纠结了很久，直到第一次在线上看到MySQL的CPU被打到100%，才真正明白缓存存在的意义。
你想想看，一个电商系统的商品详情页，同一件商品在一秒内可能被几万人同时打开。如果每个人都去数据库里查一遍，数据库得重复干几万次同样的活。这些查询结果一模一样，纯属浪费资源。缓存做的事情很简单：把热点数据放到一个更快的地方，下次查的时候先来这里找，找到了就直接返回，数据库连请求都收不到，自然就轻松了。
Redis就是一种基于内存的键值对存储系统，它把数据放在内存里而不是磁盘上。内存的读写速度比磁盘快几个数量级，所以Redis读写的延迟通常在亚毫秒级别。这也是为什么几乎所有高并发项目里都能看到它的身影——要么当业务缓存，要么当分布式锁、排行榜、消息队列的底层载体。
但要注意，引入Redis不是为了炫技，而是为了解决"大量请求重复访问同一份数据"这个具体问题。如果业务本身读写量很小，数据库完全扛得住，硬上缓存只会增加维护成本。判断标准其实很朴素：先问一句"这个数据被读的次数，远大于被写的次数吗"？如果是，缓存就是合适的；如果不是，先别急着上。
1.2 内存、单线程与IO多路复用：Redis快在哪里
Redis快，第一靠内存，第二靠设计。你可能会觉得，内存数据库那么多，为什么Redis成了事实标准？这里值得聊一聊它的底层逻辑。
数据存在内存里，省去了磁盘寻址和机械运动的时间，这当然是基础。但更关键的是Redis采用了单线程模型——主线程一次只处理一个命令，不需要在多个线程之间切换上下文。很多人一听"单线程"就以为是性能瓶颈，恰恰相反，Redis的核心瓶颈从来不是CPU，而是网络IO和内存大小。单线程避免了多线程并发访问共享数据的锁竞争，反而让它在绝大多数场景下跑得更稳。
再配合IO多路复用机制，Redis可以在一个线程里同时监听成千上万个网络连接。用生活里的例子打比方：传统的阻塞式IO就像银行只在每个窗口配一个柜员，来一个客户就锁住一个窗口；而IO多路复用像一个大堂经理，他能同时留意所有排队的客户，谁喊"我要办业务"他就过去处理谁。Redis就是这个高效的大堂经理。
解决了单线程模型的困惑，你就能理解Redis很多设计上的"怪癖"：它执行的命令都是原子的，不需要额外加锁；它也严格禁止耗时操作（比如在Redis里遍历几十万Key的KEYS命令），因为一旦有命令耗时太长，后面的所有命令都要排队等着，整个服务就像卡住一样。
1.3 哪些场景适合用Redis，哪些别硬上
学习Redis不能只学命令，更得学会判断"什么场景该用、什么场景不该用"。这里我结合自己踩过的坑，把典型场景分个类。
适合用Redis的场景，核心都指向"读多写少+共享"：
- 热点数据缓存：登录会话、用户资料、商品详情、配置信息。
- 计数器：点赞数、浏览量、库存扣减，利用INCR命令的原子性。
- 排行榜：用ZSet按分数排序，输出Top N。
- 分布式锁：多台机器抢同一份资源时，借助Redis实现互斥。
- 简单队列：List的LPUSH+BRPOP组合做异步解耦。
不太适合的场景也有不少。比如复杂的关系查询、多表关联聚合，这些交给关系型数据库更合适；再比如数据量几十GB以上、又要求全部放进内存的，成本会非常难看，这时候可能得考虑冷热分离或者换存储方案。还有强事务、需要回滚的金融级业务，Redis的机制决定它不是干这个的，硬要用会把自己坑得很惨。
一句话总结：Redis是"缓存和协同工具"，不是"数据库的替代品"。带着这个认知去学，后面所有的命令和实操才会有方向感。
2. 环境搭建不劝退：最常见的安装方式和启动排错
2.1 Windows、macOS、Linux的安装路线
很多新手学Redis第一关就卡在安装上，因为Redis官方其实并不支持Windows。Windows上的版本大多是开源社区移植的，或者微软之前维护的旧分支。如果你只是本地学习，在Windows上可以用以下两种方式之一：
一种方式是从Redis的GitHub仓库里找Windows移植版，下载zip包直接解压，双击redis-server.exe就能启动，默认端口6379，再开一个cmd窗口运行redis-cli.exe就能连上。另一种方式是用包管理工具，比如winget install Redis或者用WSL跑Linux环境。
如果在macOS上，安装就顺畅得多，直接一行命令的事：
brew install redis brew services start redisLinux服务器上最常见的是源码编译安装：先去官网下载稳定版tar包，然后依次执行make、make install。如果你用的是Ubuntu或者CentOS，也可以直接用系统自带包管理器装，比如apt install redis-server或者yum install redis。用包管理器装的好处是自动注册成系统服务，省去手工维护进程的麻烦。
装完后先别急着写代码，做两件事：第一，跑一下redis-cli ping，看到返回PONG说明服务正常；第二，了解一下Redis默认是无密码的，如果端口暴露到公网，分分钟会被扫到并被写入恶意数据，后面我会专门讲怎么配密码和保护模式。
2.2 Docker部署与redis.conf里值得动刀的配置
如果你要部署到测试环境或生产环境，我个人强烈推荐用Docker。它的好处是同一条命令在任何机器上跑出来的环境一模一样，团队成员不用为"我机器上怎么起不来"扯皮。
先看最基础的启动方式：
docker run -d --name redis \ -p 6379:6379 \ -v /opt/redis/data:/data \ -v /opt/redis/redis.conf:/etc/redis/redis.conf \ redis:7.2 redis-server /etc/redis/redis.conf这里把数据目录和配置文件都挂载到了宿主机，避免容器一删数据全没。至于为什么要单独挂配置文件，因为官方镜像默认配置太保守，比如没有设置密码、没有限制内存上限，直接裸奔风险很高。
配置文件中我最建议你动手改的几个参数，列在下面：
bind 0.0.0.0 # 允许外部访问，生产环境建议改成内网IP protected-mode yes # 开启保护模式，禁止无密码远程操作 requirepass 你的密码 # 设置访问密码 maxmemory 2gb # 限制最大内存，防止Redis把服务器内存吃光 maxmemory-policy allkeys-lru # 内存满了之后按LRU策略淘汰旧数据 appendonly yes # 开启AOF持久化，防止重启丢数据maxmemory和maxmemory-policy这两项特别重要。没有内存上限的Redis，一旦缓存Key持续增长，最终会把机器内存耗尽，可能连运维都登不进机器。设置了淘汰策略之后，内存满了它会自动清理不常用的Key，系统才有自我保护能力。
2.3 连上Redis：可视化管理工具与连接配置
命令行用久了，还是想有个可视化界面看看当前有哪些Key、哪些Key占内存大。常用的工具我推荐两款：Redis Desktop Manager（RDM）和Another Redis Desktop Manager——后者是开源社区的轻量替代品，界面清爽，连接体验和收费版RDM差不太多。
连接之前，确保你的Redis已经设置了密码或者允许当前IP访问。如果连接不上，优先检查几个地方：
- 服务器防火墙是否放行了6379端口；
- Redis的
bind配置是否允许对应IP访问； - 如果开了Docker端口映射，确认宿主机的端口真的映射到了容器里。
有一种情况特别容易踩坑：Redis部署在云服务器上，安全组只放行了80端口，Redis端口没放行，结果程序能通、本地工具死活连不上。排查的时候不要只盯程序报错，先把网络链路理清楚：客户端 -> 服务器安全组 -> 宿主机端口 -> Docker容器端口 -> redis.conf的bind配置，链路里任何一环有问题都不通。
3. 五种核心数据类型的设计意图：从命令到业务场景
3.1 String：最朴素的KV，却是计数器的主力
Redis最基础的数据类型就是String，一个Key对应一个Value，Value最大能存512MB。它看起来简单，但使用频率最高，因为缓存、会话、验证码这些场景本质上都是"存一段字符串再取出来"。
除了基础的SET和GET，String类型里有几个命令值得单独留意：
SET key value EX 300 # 设置5分钟过期时间 SETNX lock 1 EX 10 # 只有Key不存在时才能设置成功 INCR page_view # 自增1，原子操作 MSET a 1 b 2 c 3 # 一次性批量设置SETNX这个名字很关键，它是后面做分布式锁的起点。INCR的原子性也要理解透彻：它执行过程中不会被其他命令打断，所以多个客户端并发执行INCR，最终结果也不会错乱。很多面试官就爱问"如何用Redis实现计数器"，其实答案就是这一条命令。
实操时我建议给Key设计一套清晰的命名规则，比如模块:业务:唯一标识。像user:info:12345、product:detail:67890，这样一眼就能看出Key属于哪个业务，排查问题时能省下大量时间。
3.2 Hash与List：对象存储和消息队列的原型
Hash类型适合存对象，它的结构像一个字段集合：一个Key下面可以有很多field，每个field都有自己的value。比如存用户信息，不需要把整个对象序列化成一大串JSON，而是把name、age、email分别作为field存进去。这样想更新某个字段时，只需要HMSET改那一个field，不用整条数据重写。
List类型则是一个双向链表，可以从左或右推入、弹出元素。它有两个非常经典的应用场景：
- 作为简单的消息队列：生产者用
LPUSH把消息推入队列，消费者用BRPOP阻塞弹出。BRPOP在没有消息时会一直等待，而不是轮询空转，比RPOP更省CPU。 - 作为时间线或最新列表：比如用户发布动态后，用
LPUSH把动态ID塞进列表，再配合LTRIM只保留最近100条，实现一个轻量级的"最近动态"列表。
很多新手容易把List当数组用，用下标频繁LINDEX随机访问。这其实违背了它的设计初衷，List的随机访问性能不高，它是为"头部尾部操作"设计的。如果你需要按下标高频随机读取，应该考虑别的结构。
3.3 Set与ZSet：去重、抽奖、排行榜一条龙
Set是无序去重集合，常用于标签、好友关系、点赞去重这类"判断元素是否存在"或"两个集合之间求交集"的场景。举例来说，A用户点赞过文章ID=100，可以把like:100存成一个Set，每次点赞前用SISMEMBER检查是否已经点过，比查数据库高效得多。
ZSet是Set的有序版本，每个元素关联一个分数，Redis按分数从低到高自动排序。它的用途非常出彩：
ZADD rank:2024 100 用户A ZADD rank:2024 98 用户B ZREVRANGE rank:2024 0 9 WITHSCORES # 取分数最高的前10名 ZSCORE rank:2024 用户A # 查看某个用户的分数排行榜、积分排名、延时队列都能用它实现。比如直播打赏榜，每次有人刷礼物就ZINCRBY给对应主播加分，然后ZREVRANGE取出前几名展示，整个过程都是内存操作，扛住高并发比数据库排序稳得多。
ZSet底层用了跳表（skip list）和哈希表两种结构，所以它既能按分数范围查找，也能通过元素直接定位分数。这个"有序"能力是List给不了的，选型时要想清楚：你到底是要"按插入顺序排列"，还是要"按规则动态排序"。
3.4 过期策略与内存淘汰：缓存不能只进不出
缓存和普通存储最大的区别是"数据会过期"。Redis允许给每个Key设置过期时间，到期后自动删除。设置过期时间可以显式用EXPIRE，也可以在SET时带EX参数。
Redis删除过期Key采用了两套机制配合：一种叫惰性删除，即访问到某个Key时才发现它过期了，顺手删除；另一种叫定期删除，后台每隔一段时间抽查一批过期Key并清理。惰性删除保证了"不到期就不占额外操作"，定期删除则防止那些一直没被访问的过期Key占着内存。
你可能会问：那如果过期Key还没来得及删，内存又满了怎么办？这就轮到maxmemory-policy出场了。常见的淘汰策略有：
| 策略 | 含义 | 适用场景 |
|---|---|---|
| allkeys-lru | 在所有Key中淘汰最久没被访问的 | 大部分缓存场景，最常用 |
| volatile-lru | 只在设置了过期时间的Key中淘汰LRU | 希望没有过期时间的Key永不被删 |
| allkeys-random | 随机淘汰任意Key | 访问分布非常均匀的场景 |
| noeviction | 内存满后拒绝写入，返回错误 | 不允许删数据的业务 |
我个人的习惯是全库缓存场景用allkeys-lru，既简单又有效；如果有少量"绝对不能丢"的Key且没设过期时间，才考虑volatile-lru。记住一个原则：淘汰策略宁可激进也不能让Redis写不进去，因为写入失败在生产环境往往会造成更严重的连锁故障。
4. 在Java项目里跑通Redis：Spring Boot集成与序列化排坑
4.1 从客户端到Spring Data Redis的调用链路
本地Redis跑通之后，下一步就是让它和业务代码对接。Java生态里主流的选择是Spring Boot整合Spring Data Redis，它封装了底层客户端，让你用几个注解或者一个RedisTemplate就能操作缓存。
底层连接Redis的客户端有两个主流实现：Jedis和Lettuce。Spring Boot 2.x默认用Lettuce，它是基于Netty的异步客户端，连接复用能力更强，适合高并发环境。Jedis则更直白，每次操作都走独立的socket连接，老项目里比较常见。
引入依赖很简单，在pom.xml里加上spring-boot-starter-data-redis就够了。然后在application.yml里配置连接信息：
spring: data: redis: host: 127.0.0.1 port: 6379 password: 你的密码 lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0有几个连接池参数要解释一下：max-active是最大活跃连接数，理论上并发上限有关；min-idle保持的最小空闲连接数，太小了可能出现突发流量时频繁建连；max-wait建议显式配置一个值，默认-1表示无限等待，在高并发下有可能把线程全堵在等待连接上。
4.2 RedisTemplate序列化：最常见的乱码噩梦
我第一次用Spring Boot操作Redis时，往缓存里写了个对象，一查Redis里存的是一堆\xAC\xED\x00...开头的乱码，吓得以为是数据坏了。后来才明白，这根本不是乱码，而是Java默认的JDK序列化结果，人类当然看不懂。
RedisTemplate默认使用JdkSerializationRedisSerializer做序列化，它会把Java对象变成二进制字节流。这样做的问题有三个：存储空间大（序列化后很臃肿）、效率低、可读性差——你在Redis客户端里完全没法直观看到存了什么。
解决方法是手动指定序列化器。最常用的组合是：Key用StringRedisSerializer，Value用Jackson2JsonRedisSerializer，这样Key是人类可读的字符串，Value是JSON格式，调试起来一目了然。配置代码如下：
@Bean public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) { RedisTemplate<String, Object> template = new RedisTemplate<>(); template.setConnectionFactory(factory); StringRedisSerializer stringSerializer = new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jsonSerializer = new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; }这段配置我很建议直接抄进项目里。还有一个更偏门的坑：如果用JSON序列化Value，对象里必须有无参构造方法，否则反序列化时会直接报错。很多人踩了之后才发现，加上无参构造就好了。
4.3 缓存注解用起来很爽，坑也藏得很深
Spring Data Redis提供了三层封装：底层是RedisTemplate，上面是CacheManager，再往上是@Cacheable、@CacheEvict、@CachePut之类的注解。注解用起来确实方便，一个注解就能缓存方法的返回值。
@Cacheable(value = "user", key = "#userId") public User getUserById(Long userId) { return userMapper.selectById(userId); }但注解用多了，一定要留意几个问题。
第一个坑是缓存穿透和空值问题。如果getUserById查到null，注解默认不会缓存这个null，结果每次请求都要查数据库。解决办法是让方法返回一个"空对象"占位或者直接抛异常，让调用方提前处理。
第二个坑是内部调用导致的注解失效。同一个类里的方法A调用方法B，如果B上面标了@Cacheable，是失效的——因为Spring缓存是基于代理实现的，内部方法调用走的是this而不是代理对象，注解逻辑根本不会被触发。很多新手查了半天缓存不生效，最后发现是这个原因。
第三个坑和Spring三级缓存的概念容易混淆。网上常提的"Spring三级缓存"解决的是Bean循环依赖问题，和Redis缓存完全是两码事。面试时如果聊到这里，一定要把"Bean对象缓存"和"业务数据缓存"区分开，否则真的会越说越乱。
4.4 缓存一致性：更新数据库后缓存怎么办
写缓存容易，难的是保证缓存和数据库数据一致。最常见的方案有三种：
- 先更新数据库，再删除缓存。这是最推荐的做法，因为即使删除缓存失败，最坏的结果也只是多一次数据库请求把新数据缓存起来，不会出现缓存里长期残留旧数据的问题。
- 先删除缓存，再更新数据库。这个顺序坑很大，如果更新数据库失败，缓存又已经删了，下次请求发现缓存没有，就会去数据库拿到旧数据并重新缓存，造成数据不一致。
- 先更新数据库，再更新缓存。流程上可行，但更新缓存本身有成本，而且并发场景下两个线程交错更新，容易把旧值覆盖正确答案。
压垮缓存一致性的往往是并发。举个例子：线程A先更新数据库为value=1，紧接着线程B更新数据库为value=2并更新缓存为2，但线程A网络抖动了一下，缓存的更新操作反而在B之后执行，把2覆盖成了1。这就是经典的"后更新先落库"问题。
所以生产环境里我常用的策略是"更新数据库 + 删除缓存"，并且删除缓存这一步最好做成可靠的重试机制——比如借助消息队列异步重试删除，或者用延时双删。团队里如果实现了，可以适当结合业务容忍度来选择。记住一个底线：没有银弹，最终一致性才是大多数业务的实际需求，别为了"绝对一致"把自己绕进死胡同。
5. 缓存穿透、击穿、雪崩：三大事故的成因与治理方案
5.1 穿透：查了个不存在的数据也能把DB打挂
缓存穿透是指请求的数据在缓存里没有，在数据库里也没有，每次请求都落到数据库。正常情况下，缓存能把大部分查询挡在外面，但如果有人恶意构造一批不存在的ID，比如请求一个根本不存在的商品ID，缓存永远没有，数据库就被无限轰炸。
判断穿透很简单：看数据库连接的QPS是不是异常升高，同时Redis里明明没这个Key，请求却疯狂过来。最常见的手段是接口入参加校验，不合法或明显不存在的ID直接拒绝。
针对穿透，业界有几种主流解法：
- 缓存空值：查询结果为空时，也往缓存里写一个短生命周期的空值占位，比如过期时间设成60秒。缺点是空值很多时会占用内存。
- 布隆过滤器：把所有合法ID预先加入布隆过滤器，请求来了先判断ID是否可能存在，不存在的直接拦截。布隆过滤器允许"可能存在"的误判，但绝不会错杀"一定不存在"的ID，非常适合黑名单拦截。
布隆过滤器的原理可以这样理解：它用多个哈希函数把一个ID映射到位数组的多个位置，全部命中时只能说"可能见过"，但有一个位置为空就肯定没见过。代价是存在一定的误判率，但误判只会让请求继续走，不会拦掉合法请求。
5.2 击穿：热点Key在重建的瞬间被流量淹没
击穿和穿透一字之差，本质完全不同。击穿指的是某一个热点Key在过期瞬间，大量并发请求同时发现缓存不在，于是一起打到数据库去重建。比如某个明星突发新闻把一条详情数据顶上热搜，正好这条数据的缓存过期了，一瞬间几万人同时查库。
系统表现：数据库单Key相关的SQL QPS突然飙高，而Redis里这个Key明明昨天还在正常命中。解决击穿的核心是"同一时间只让一个请求去重建缓存"，其他请求要么等待要么拿到旧值。
互斥锁是典型方案：请求进来看不到缓存，先尝试获取一个分布式锁（比如SETNX lock_key），只有拿到锁的请求才去查库并回写缓存；其他请求稍作重试后再次读缓存。代价是多了锁竞争的开销，但如果热点数据不常失效，收益远大于成本。
另一种方案是逻辑过期：缓存里不设物理过期时间，而是存一个"该数据的过期时间戳"。每次读取时判断逻辑时间是否过期，过期了就让一个线程去异步刷新缓存，当前请求先返回旧数据。好处是读请求永远不会被阻塞，坏处是实现复杂度更高，需要处理好旧数据短暂可接受的问题。
5.3 雪崩：大批Key同时失效后的连锁反应
雪崩比击穿更可怕：不是单个Key失效，而是大量Key在同一时间段集体失效，导致缓存命中率瞬间跌到谷底，请求像洪水一样涌向数据库，数据库扛不住就挂，然后整个服务跟着挂。
雪崩的常见成因有三个。第一，大量Key设置了同一个过期时间，比如零点统一过期；第二，Redis实例本身宕机，所有缓存瞬间不可用；第三，缓存服务被重启时清空，还没来得及回填就收到海量请求。
治理雪崩的思路是"多管齐下"：
- 过期时间加随机值，典型做法是在基础TTL上再加一个随机秒数，比如
300 + random(0, 60)，把集体失效分散开。 - 缓存永不失效，改为后台异步定时刷新热点数据。
- 做多级缓存，比如本地进程内缓存一层，Redis再一层，Redis宕机时本地缓存还能扛一阵子。
- 给数据库设置连接池水位线和服务熔断，底层扛不住时优先保命而不是硬撑。
这里想多说一句：雪崩治理不只是Redis侧的事，网关限流、数据库连接池保护、服务降级全都得上。缓存只是第一道防线，防线后面还得有第二道和第三道。
5.4 治理方案对比：布隆过滤器、互斥锁、逻辑过期
三种方案选起来其实不困难，核心取决于你的业务容忍度。先看一张对比表：
| 方案 | 适用问题 | 优点 | 缺点 |
|---|---|---|---|
| 缓存空值 | 穿透 | 实现简单，空值也走缓存 | 空值占内存，可能放大存储量 |
| 布隆过滤器 | 穿透 | 拦截效果彻底，基本不占内存 | 需要事先构建ID集合，存在误判率 |
| 互斥锁 | 击穿 | 保证只重建一次 | 阻塞请求，可能拖慢响应 |
| 逻辑过期 | 击穿 | 请求不阻塞，用户体验好 | 实现复杂，短暂读到旧数据 |
结合我自己的项目经验，穿透优先用"参数校验+缓存空值"，如果恶意流量非常严重再加布隆过滤器；击穿优先用互斥锁，因为热点Key失效的频率一般不高，锁竞争的代价可以接受；对缓存恢复速度要求极高的场景，再用逻辑过期做异步重建。
实际落地时很少只选一种方案。高并发系统通常是"入口层拦截非法请求 + 缓存层防止击穿 + 异步补偿保证最终一致"的组合拳，而不是寄希望于某个单一方案解决问题。
6. 从单机走向分布式：主从复制、哨兵与分布式锁的落地建议
6.1 主从复制与Docker部署主从集群
单机Redis的容量和可用性都有上限。机器一挂，整个缓存服务就没了，这在高并发系统里是不可接受的。业界标准的起步方案是主从复制：一个主节点负责写，一个或多个从节点负责读，主节点的数据会自动同步到从节点。
主从复制的好处很直观：读写分离降低单点压力，主节点挂了还能让从节点顶上，数据也有了一份实时备份。在Docker环境里部署一主一从的配置非常顺手：
version: "3" services: redis-master: image: redis:7.2 command: redis-server --appendonly yes ports: - "6379:6379" volumes: - ./master/data:/data redis-slave: image: redis:7.2 command: redis-server --slaveof redis-master 6379 --appendonly yes ports: - "6380:6379" volumes: - ./slave/data:/data depends_on: - redis-master启动后用docker compose up -d拉起来，再进从节点执行INFO replication，看到role:slave和master_link_status:up就说明复制关系建立成功。这里提醒一句：--slaveof只是容器启动时指定的复制关系，如果你以后改成哨兵模式，这些静态配置都得重新梳理。
6.2 哨兵：让故障转移自动发生
主从复制解决了数据冗余，但没有解决"主节点挂了谁来接管"的问题。总不能让运维半夜爬起来手动切换主节点吧？Redis官方给出的答案是哨兵（Sentinel）。
哨兵是一组独立的Redis进程，它监控主节点的健康状态，一旦发现主节点客观下线，会在从节点里选一个提升为新的主节点，并通知其他从节点和客户端重新指向新的主节点。整个过程是自动的，不需要人肉介入。
部署哨兵时，至少要三个以上实例才能避免"脑裂"——因为哨兵之间需要投票达成一致，单个哨兵无法判断自己看到的状态是否真实。用Docker部署哨兵的坑主要是网络和配置：
sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000解释一下：mymaster是监控主节点的名字；2表示至少两个哨兵同意主节点不可用，才会触发故障转移；down-after-milliseconds是判断主观下线的等待时间。故障转移耗时通常在几秒到十几秒之间，这个窗口期写入会失败，业务方要做好重试。
我自己的建议是：如果团队规模不大、Redis实例也不多，哨兵模式完全够用；等实例数量上到几十个，再考虑集群模式不迟。不要一上来就追求最高级架构，稳定优先。
6.3 分布式锁：别用setnx裸写，这里有血的教训
分布式锁是Redis高频面试题，也是线上最容易出事故的地方。场景很典型：多个服务实例同时处理同一个订单，如果不加锁，重复扣库存、重复发送消息就会发生。
最基础的实现是SETNX加过期时间：
SET lock:order:1001 token_abc EX 30 NX拿到锁的执行业务，业务结束后再删锁。但这里有个经典陷阱：如果业务执行时间超过了锁的过期时间，锁自动释放了，另一个线程又抢到同一把锁，第一个线程执行完如果直接DEL，就把别人的锁删掉了。正确做法是在Value里放一个唯一标识，删锁前先对比是不是自己的标识，再执行删除。
# 伪代码逻辑 if redis.get(lockKey) == myToken: redis.del(lockKey)但即便这样，仍然存在"判断和删除不是原子操作"的问题。所以生产环境我更推荐直接使用Redisson，它把看门狗续期、原子释放锁、可重入这些细节全部封装好了。你不需要自己造轮子，把实现细节交给成熟库，比自己手写SETNX安全得多。我还真见过有团队手写的锁在压测下出过"超时释放锁后重复执行"的事故，教训深刻。
6.4 最后说几句心里话
Redis这条路写到这里已经覆盖了从零基础到分布式部署的主线。回顾整套学习过程，我最大的体会是：Redis的命令本身不难，难的是理解每个设计背后的"为什么"。
为什么用单线程却还这么快？为什么缓存会引发一致性问题？为什么主从复制之外还要加哨兵？这些问题比单纯背命令重要得多。面试官问你Redis，其实想看到的不是"你会用SET和GET"，而是"遇到问题你能不能在原理层面判断归因和选型"。
如果你正在学，我建议按这个节奏走：先把单机开发用熟，再花一周时间把三大缓存问题每个都做成一次回放演练，再往分布式方向推进。每一步都实际动手敲一遍，比看十篇教程都值。至于集群模式（Redis Cluster）和更多高级特性，那是后话，先把上面的基础打扎实，后面自然水到渠成。
