先从一个查了很久的真实故障说起。当时我们的后端服务遇到一次大促流量接口平均响应时间从 80ms 一路涨到 2 秒多数据库连接池被打满慢查询日志里反复出现同一条 SQL——查某个秒杀商品的详情。同一个 key 在短时间内被几万个请求同时查询数据库当然扛不住。后来我们引入 Redis 做缓存把热点数据挡在数据库前面接口耗时直接掉到 5ms 左右。Redis 就是在这个背景下成为后端开发绕不开的“第一个中间件”。这篇文章想做的不是给你罗列一堆命令而是把 Redis 从安装部署、五种核心数据结构、持久化、缓存治理、分布式锁、内存淘汰到主从哨兵高可用整个入门链路串起来。每部分都会结合真实业务场景讲“为什么这么做”也会把我实际踩过的坑直接标出来省得你再走一遍弯路。无论你是刚接触 Redis 的在校学生还是准备系统补基础的后端工程师都可以照着这篇文章从零把它跑起来并理解每个操作背后的设计缘由。1. 先用业务场景搞懂 Redis 到底解决了什么问题1.1 缓存层不是数据库的替代品而是“挡箭牌”很多人第一次听说 Redis记住的标签就是“缓存”。这个说法没错但要理解到位得先搞清楚它到底在系统里扮演什么角色。数据库把数据存在磁盘上靠索引和预读来提速但磁盘 IO 的速度再快跟内存相比也差着几个数量级。当同一批数据被高频访问时每次都去打数据库就是在拿系统的瓶颈点硬扛流量。Redis 做的事情是把高频访问的数据从磁盘搬到内存让请求在内存里直接被“接住”。用大白话说它就是一层挡在数据库前面的挡箭牌把业务对数据库的读压力卸下来。你访问一次数据库可能要走 1~5ms还得承担连接池、事务日志、磁盘随机读的连锁开销而 Redis 的读写通常是在 0.1ms 这个量级纯内存操作加高效网络模型差距就是这么拉开的。所以判断一个场景要不要用 Redis先问自己这个数据是不是被高频读读多写少对一致性要求是不是可以做到最终一致如果三个问题都符合那就非常适合用 Redis 做缓存。反过来如果数据本来就很少有人读或者写入非常频繁且要求强一致那 Redis 不是万能的硬上只会引入新的复杂度。1.2 Redis 和 Memcached 的选型对比为什么它不是简单的“升级版”在 Redis 之前Memcached 才是“缓存”领域的代名词。不少老项目里至今还有 Memcached 的身影所以面试也爱问两者区别。直接说结论Memcached 能做的事 Redis 基本都能做而且 Redis 做得更多但多出来的能力也意味着你必须更懂它。对比维度RedisMemcached数据类型String、Hash、List、Set、ZSet 等丰富类型仅支持 key-value 字符串持久化RDB、AOF 支持数据落盘纯内存重启数据即丢主从复制原生支持配合哨兵可实现自动故障转移不具备内置主从复制能力线程模型单线程执行命令6.0 起网络层多线程多线程处理网络请求适用定位缓存、计数器、分布式锁、排行榜、队列等简单的分布式缓存这个表不是让你背下来而是帮你理解设计上的取舍。Memcached 把简单做到了极致所以它的性能天花板也很高但 Redis 选择用更丰富的数据结构和持久化能力去覆盖更多的业务场景。实际项目里我现在的默认选择基本就是 Redis只有在纯粹追求极致缓存性能、完全能接受数据丢失、且只存简单字符串的老系统里才会考虑 Memcached 保留不动。1.3 Redis 的适用边界哪些场景不适合硬上讲完“Redis 能做什么”必须泼一盆冷水说说“它做不了什么”。首先是复杂查询比如多表关联、条件聚合、模糊搜索这些是数据库和搜索引擎的强项放在 Redis 里强行实现只会是一场灾难。其次是强事务场景Redis 的事务模型和关系型数据库的 ACID 完全不同它不保证回滚也没有隔离级别订单扣款这类场景不能靠 Redis 事务来保证资金安全。再次是超大数据量场景Redis 是内存数据库数据量大到内存装不下时成本会非常夸张这时候需要考虑冷热分层或引入其他存储方案。一句话总结Redis 是“高频小数据”的加速器不是“全量大数据”的仓库。搞清楚了边界再看后面的安装和配置你会知道每一项参数背后是在为什么场景服务。2. 安装部署三路线Windows、Linux、Docker 里把 Redis 跑起来2.1 Windows 本地安装的两条路径虽然 Redis 官方并没有提供非常完整的 Windows 原生支持但企业级项目里确实有很多开发同学日常用的是 Windows 电脑。第一条路径是直接下载 Windows 移植版本。GitHub 上 tporadowski 维护的 Redis Windows 版本流传最广支持到 5.0.14 左右。解压后打开一个命令窗口先启动服务端redis-server.exe再打开另一个窗口验证redis-cli.exe ping看到 PONG 就表示服务已经起来了。这种方式的优点是快缺点是版本通常落后于 Linux 官方版本所以它只适合本地学习验证不建议部署到生产。第二条路径是 Windows 上装个 WSLWindows Subsystem for Linux然后在 WSL 里按 Linux 的方式装。这样你既能体验 Linux 环境又可以直接执行 Redis 官方最新版本的命令本地开发和线上环境更接近。我个人更推荐这条路径做环境模拟因为入门阶段最容易遇到“本地能跑、线上起不来”的坑早点适应 Linux 环境能少踩很多雷。2.2 Linux 编译安装与基础配置Linux 服务器上安装 Redis最稳妥的方式还是下载源码自己编译。以 7.x 版本为例整体步骤大约四分钟wget https://download.redis.io/releases/redis-7.4.1.tar.gz tar xzf redis-7.4.1.tar.gz cd redis-7.4.1 make make install前提是系统装了 gcc、make 等编译工具链。编译结束直接执行 redis-server 就能启动但我一般会加--daemonize yes让它后台运行redis-server --daemonize yes redis-cli ping这里有一个新手常见的疑问为什么不像 Windows 一样直接下个安装包原因很简单生产服务器环境千差万别源码编译能让你在编译过程中提前暴露环境依赖问题而且编译出的二进制文件与系统兼容性更好。后面你如果需要定制某些编译参数比如打开 TLS 支持也必须在源码编译阶段完成。2.3 用 Docker Compose 跑一个开发环境现在很多团队已经默认用 Docker 来管理中间件了Redis 也不例外。我建议你哪怕本地不装 Redis也要把 Docker 这条路线跑通因为后面学主从、哨兵时Docker Compose 能让你用很低的成本搭出一整套模拟环境。开发环境我通常就用一个最简配置services: redis: image: redis:7.4 container_name: redis-dev restart: always ports: - 6379:6379 command: redis-server --requirepass 123456 --appendonly yes --maxmemory 512mb --maxmemory-policy allkeys-lru volumes: - redis-data:/data volumes: redis-data:把上面内容保存为 docker-compose.yml在同目录执行docker compose up -dRedis 就起来了。这里故意加了密码、持久化和内存淘汰参数三项配置后面章节里会逐一展开。用 Docker 的好处是干净玩坏了随时docker compose down再重建坏处是如果你完全不懂容器网络后面做主从时会困惑为什么容器之间能通、宿主机连不上这个我在第八部分专门讲。2.4 安装完最容易踩的三个坑第一个坑是protected-mode。Redis 默认开启保护模式如果你没有设置密码它只接受本机回环地址 127.0.0.1 的连接。很多人在 Linux 上启动完说外部连不上以为是防火墙问题其实改一下 bind 配置和密码就解决了。我建议本地学习时不要图省事直接关掉保护模式而是设一个密码这样既安全又能复现生产环境的认证流程。第二个坑是daemonize yes之后日志去哪了。后台运行后启动信息不会打印在当前屏幕上默认输出到配置文件里的 logfile。如果没配 logfile你甚至看不到日志遇到启动失败会一脸懵。排查技巧是先不带 daemonize 参数前台启动让错误直接打出来看到具体报错再改配置。第三个坑是 Windows 下端口被占用。Windows 上的 Hyper-V、WSL 网络组件经常占用 6379 端口启动 redis-server 时可能报 bind 失败。用netstat -ano | findstr 6379找到占用进程或者干脆在本地配置里把端口改成 6380先跑起来再说。3. 五种核心数据结构决定你的使用层次3.1 String别只会当缓存用它还是计数器和高频操作的主角String 是 Redis 里最基础、也最容易低估的类型。它的本质就是一个二进制安全的字符串最大能存 512MB可以存普通文本、JSON 序列化后的对象、数字甚至图片的二进制内容。入门操作基本就是SET和GETSET user:1001:name 张三 GET user:1001:name但 String 真正的威力在它的自增自减能力。INCR系列命令能在一个原子操作内对数值加一不需要你先读出来再写回去。比如一个文章阅读量计数器直接执行INCR article:read:1001每次请求加一不需要加锁也不会出现并发覆盖问题。这在数据库里用 UPDATE 也能实现但要付出行锁和事务的开销在高频场景下Redis 的原子自增有着不可替代的性能优势。使用 String 存储对象时常用的做法是把对象序列化成 JSON 字符串再存比如SET user:1001 {name:张三,age:28}。这种方式的优点是存取简单、兼容性好缺点也非常明显——如果你想修改其中一个字段必须把整个字符串取出来反序列化、修改、再序列化存回去。业务里对象字段比较多且经常只改部分字段时就要考虑用 Hash 了。3.2 Hash对象存储的天然载体可读性秒杀 StringHash 在 Redis 里的结构相当于对象或 map。它允许你在一个 key 下面挂多个 field-value 对非常适合存储用户、商品、订单这类结构化数据。示例HSET user:1001 name 张三 age 28 city 杭州 HGET user:1001 name HGETALL user:1001 HINCRBY user:1001 age 1对比 String 存 JSONHash 的优势是字段级操作。我只想改用户的年龄HINCRBY一下就完成了不需要动其他字段。生产环境在做会话存储时也经常用 Hash 保存用户登录态信息比如session:{token}下面挂 userId、loginTime、expireTime查询单字段方便整体过期时间可以由 key 的 TTL 统一控制。Hash 还有一个特别实用的上层用法当你用 Redis 做配置中心或开关系统时把一组配置放在一个 Hash 里修改某个配置项时只影响其中一个 field其他字段的缓存仍然可用不会造成整个配置缓存失效。这个细节在缓存治理章节还会再提。3.3 List消息队列与分页列表的底层结构List 在 Redis 里是一个双向链表结构既可以从头部压入也可以从尾部弹出。最经典的用法是LPUSH配合BRPOP实现一个简单的消息队列生产者往列表左边塞消息消费者从右边阻塞等待消息。LPUSH msg:queue task-001 BRPOP msg:queue 0这里的 BRPOP 带阻塞参数0 表示没有消息就一直等。这种方式比轮询更省资源很多轻量级业务场景不引入 RabbitMQ、Kafka 时就是靠这个组合顶上的。不过要提醒一句Redis 列表队列没有消费者确认机制消息被弹出后消费者如果崩溃这条消息就丢了。所以它适合任务可以重试、即使丢失也能兜底的场景核心业务队列还是交给专业消息中间件。List 的另一个常见场景是分页查询比如论坛的最新评论列表。LRANGE key 0 9取第一页LRANGE key 10 19取第二页相当于按插入顺序的倒序读取。加上LTRIM可以只保留最近 N 条天然适合做“最近浏览记录”“操作日志”这种只关心最新几条数据的业务。3.4 Set 和 ZSet去重、标签与排行榜Set 是无序集合自动去重支持多个集合之间的交并差运算。做好友列表、用户标签、抽奖去重都很顺手SADD user:1001:tags Java Redis 后端 SISMEMBER user:1001:tags Java SINTER user:1001:tags user:1002:tags上面SINTER是求两个用户共同标签用来做兴趣推荐或好友推荐。很多人学 Set 只记住去重忽略了集合运算这个杀手级特性。在实际项目里用户有没有某个权限、商品在不在某几个分类下这类“包含关系”用 Set 的SISMEMBER判断时间复杂度是 O(1)比数据库里 IN 查询快很多。ZSet 是加权的 Set每个元素带一个 score 分数Redis 内部根据分数排序。排行榜功能基本就是为它量身定做的ZADD rank:2025 100 user:1001 ZINCRBY rank:2025 10 user:1001 ZREVRANGE rank:2025 0 9 WITHSCORESZADD初始分数ZINCRBY给某个用户加分ZREVRANGE取分数最高的前十名。除了排行榜延时队列也能用 ZSet 实现score 存执行时间戳轮询时用ZRANGEBYSCORE key -inf now取出所有已到期的任务处理完再ZREM删除。这种玩法面试也爱问因为它能体现你对数据结构的理解层次。4. 持久化选型RDB、AOF 与混合持久化的取舍4.1 RDB 快照的触发机制与丢失窗口Redis 默认开启的是 RDB 快照持久化。它会定期把内存中的全量数据生成一个二进制快照文件默认叫 dump.rdb。快照的触发条件是配置里的 save 规则典型配置是save 900 1 save 300 10 save 60 10000意思是900 秒内至少 1 次写操作就做一次快照300 秒内至少 10 次写操作做一次快照60 秒内至少 10000 次做一次快照。这种“条件触发”的设计很务实低频写入时不会频繁落盘高频写入时又能保证数据不太旧。但 RDB 的问题也很明确它是一个时间点快照两次快照之间如果 Redis 崩溃或断电这期间写入的数据全部丢失。你可以回忆一下本地服务没保存就断电的后果RDB 的开销机制与之类似。如果业务能接受最近几十秒甚至几分钟的数据丢失RDB 够用但凡是涉及订单、交易痕迹这种不能丢的场景就必须开 AOF。4.2 AOF 日志与刷盘策略每隔一秒钟的妥协AOF 持久化的思路是“写操作日志”。每次 Redis 执行写命令都会把命令追加到 aof 文件末尾重启时重新执行日志里的命令从而恢复数据。相比 RDB 的全量快照AOF 的恢复粒度更细丢失数据的窗口更小。关键配置是 appendfsync 的三种策略策略行为数据安全性性能表现always每次写命令都 fsync 到磁盘最安全最多丢一个命令最慢everysec每秒 fsync 一次最多丢 1 秒数据推荐no由操作系统决定何时刷盘可能丢较多数据最快生产环境我基本固定用 everysec这是数据安全性和性能之间的一个合理折中。顺便补一个知识点AOF 文件会随着写入不断变大Redis 提供了重写机制用BGREWRITEAOF或达到自动重写阈值时把当前数据的最短命令集重新生成一份日志避免文件无限膨胀。不要把重写想得多复杂它就是压缩日志的“瘦身”操作。4.3 混合持久化和备份恢复演练Redis 4.0 之后提供了混合持久化配置项是aof-use-rdb-preamble yes。它的做法很巧妙AOF 文件头部用 RDB 格式记录全量数据后面追加增量命令日志。这样重启恢复时先加载 RDB 快照再执行增量日志恢复速度快数据丢失窗口又小。我现在的默认配置就是 AOF 开启 混合持久化开启。持久化配置只是第一步真正的“生存能力”来自恢复演练。我一个实际建议每季度至少在测试环境干一次“删库恢复”实验。步骤很简单先redis-cli shutdown然后把 dump.rdb 或 appendonly.aof 从备份目录拷回来重新启动 Redis用DBSIZE核对数据量是否与预期一致。不要等到真出故障时才第一次试恢复流程那种“看着配置妥当、恢复时才发现文件损坏”的教训我见过不止一次。5. 缓存治理穿透、击穿、雪崩与数据一致性5.1 缓存穿透请求的是“不存在的数据”Redis 根本拦不住缓存穿透是指请求的数据在缓存和数据库中都不存在。比如一个用户传了个不存在的商品 IDRedis 查不到于是请求继续打到 MySQLMySQL 也查不到。如果是恶意循环攻击大量这样的请求会直接绕过缓存把数据库击穿。解决办法有三种层次。第一层是参数校验比如 ID 必须为正整数、长度必须在合法范围内这能从源头挡掉大部分非法请求。第二层是缓存空值查不到数据时也在 Redis 里写一个空 value设置较短的 TTL比如 60 秒后续请求直接返回空结果不再穿透到数据库。第三层是布隆过滤器在查询前先判断这个 key 是否可能存在如果过滤器说不存在直接返回这个方案的缺点是布隆过滤器存在误判率实现成本也更高。实际项目中不太厚重的接口用“空值缓存”就够了高风险场景再上布隆过滤器。5.2 缓存击穿热点 key 过期的那一瞬间谁能扛住缓存击穿和穿透只差一个字问题却完全不同。击穿是缓存里明明有这个 key但它正好在某一刻过期了此时大量并发请求同时涌进来全部没有命中缓存同时打到数据库。典型场景就是微博热搜、秒杀商品详情这类超高热点数据。最常见的解决办法是互斥锁加缓存重建。请求发现缓存没命中时先尝试获取一个 Redis 分布式锁后面章节会讲拿到锁的请求去数据库查询并重建缓存其他请求短暂等待后再次查询缓存就能命中。缺点是一旦缓存重建时间较长请求会产生一定的等待延迟。另一种思路是“逻辑过期”在 value 里存一个过期时间字段读时发现逻辑上过期不影响返回旧值但后台异步线程去重建缓存并更新 value。这种方式对耗时重建非常友好但对代码的侵入性更高一些。5.3 缓存雪崩大面积 key 一起过期引发的连锁反应雪崩是击穿的扩大版。击穿是一个热点 key 过期雪崩是大量 key 在同一时间段集中过期或者 Redis 实例直接宕机导致所有请求都落到数据库数据库瞬间被压垮。最容易出问题的一种做法是给缓存数据设置一个统一的固定过期时间比如全部 30 分钟那么每 30 分钟就会迎来一次雪崩峰值。基础解法是在过期时间上加上随机因子比如 30 分钟加上 0~300 秒的随机值让过期时间错开。进阶解法是采用多级缓存Redis 之上再放一层本地缓存比如 Caffeine本地缓存可以设计成“永不主动过期”而是由后台任务定时刷新这样即使 Redis 整层不可用本地缓存也能扛住一部分流量。最后一定要加限流降级兜底当数据库压力超过阈值时放弃非核心数据的实时性直接返回旧缓存或提示稍后再试。5.4 缓存与数据库的双写一致性Cache Aside 模式的细节缓存治理绕不开一致性问题。现在的主流模式还是 Cache Aside旁路缓存读的时候先读缓存不命中则查数据库并回填缓存写的时候先更新数据库再删除缓存。问题恰恰出在“先更新库还是先删缓存”的顺序上。如果先删缓存再更新数据库在删完缓存到更新数据库之间有一个时间窗口另一个线程读到旧数据并回填缓存就会把旧数据重新写进缓存。所以实践上更推荐“先更新数据库再删除缓存”。为什么删除比更新好因为缓存重建成本高而且更新缓存与数据库操作叠加容易出现并发覆盖。有些场景容不下“先更新库再删缓存”的窗口可以加“延迟双删”更新完数据库后删除一次缓存等几百毫秒后再删除一次。第二次删除的目的是清掉那几百毫秒窗口里被并发请求回填的旧缓存。要注意这个方案仍然不是强一致它只是把不一致窗口压缩到很小。真正需要严格一致的场景应该考虑用订阅数据库 binlog 的方式来同步缓存而不是在业务代码里去手动维护。6. 事务、Lua 与分布式锁把原子性用在刀刃上6.1 Redis 事务能做到什么程度做不到什么程度Redis 事务用MULTI、EXEC、DISCARD三个命令组合。开启 MULTI 之后后续命令不会立刻执行而是进入一个队列EXEC 时再一并发送执行。这种批量执行可以保证队列里的命令按顺序、原子地执行中间不会插入其他客户端的命令。但必须明确Redis 事务不支持回滚。如果执行过程中某条命令语法有误它是不会执行前面命令再撤回的而是直接报错已执行的结果保留。它也不提供关系型数据库那种隔离级别只是“打包执行一批命令”而已。事务的实用性其实是有限的很多初学者会误以为它像 MySQL 事务一样安全这个认知必须纠正。在实际业务代码里如果只是希望多条命令原子执行我更推荐用 Lua 脚本。6.2 Lua 脚本真正的原子操作利器Lua 脚本在 Redis 里的定位就是“把多条命令打包成一个整体由 Redis 单线程执行中间不会被插队”。它天然具备原子性也天然避免了很多竞态问题。比如之前分布式锁里判断锁值并删除的经典脚本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这个脚本用一段逻辑完成了“判断删除”两步操作第二步不会因为服务崩溃而漏执行。如果你在处理限流、库存扣减、排行榜更新这类需要“先读后写且中间不能被打断”的逻辑第一反应应该是能不能用 Lua 解决而不是去加分布式锁。6.3 分布式锁的正确实现与 Redisson 的价值分布式锁是 Redis 在分布式系统里最经典的应用之一。最朴素的实现是SETNX但只写一行SETNX lock:order 1是一个标准反模式如果客户端拿到锁后崩溃了这个锁永远不会释放后面的请求全部卡死。补救办法是给它加过期时间但SETNX和EXPIRE是两条命令不是原子的中间又可能出事。正确写法是 Redis 2.8 之后提供的原子命令SET lock:order requestId NX PX 30000NX 表示 key 不存在才设置PX 设置过期时间requestId 用来标识当前持有锁的客户端。释放锁时不能直接 del因为可能你的锁已经因为执行业务太久自动过期其他客户端拿到了同一把锁你一个 del 把别人的锁删掉了。所以释放必须用前面那段 Lua 脚本先比对 value 是自己才执行删除。这些逻辑其实都很机械生产环境不建议手写直接使用 Redisson 这种封装好的客户端。Redisson 的锁自带“看门狗”机制默认加锁 30 秒如果持锁线程还在执行它会自动续期执行完主动释放。这样就不用手动估算业务耗时也避免了业务没跑完锁就过期的问题。另外提一句 RedLock它的思路是让锁在多个独立 Redis 节点上分别加锁用来降低单点风险但在业界争议很大普通项目用单节点 Redis Redisson 就足够稳定了。7. 内存淘汰与过期策略Redis 内存被打满时的存活之道7.1 过期删除的两种机制想了想还是定期加惰性Redis 里的 key 可以设置 TTL到期后会被删除。删除并不是“时间一到立刻删”而是靠两种机制配合惰性删除和定期删除。惰性删除的意思是当某个请求访问一个 key 时Redis 会先检查它是否过期过期了就先删除再返回空。这种方式的优点是省资源缺点是过期了没人访问就一直在内存里占地方。定期删除则是 Redis 每隔一段时间随机抽出一批设置了过期时间的 key检查并删除其中的过期 key。为什么不用定时器逐个精确删除因为那需要一个额外的线程不断扫描所有 key代价太高。反之如果只靠惰性删除大量过期 key 会堆积成“内存垃圾”。所以 Redis 用这两种机制配合希望达到一种平衡大多数过期 key 在访问时被惰性清掉没被访问到的定期任务也会慢慢扫出来。也正因为这种设计你设置相同 TTL 的 key删除时间不会是分秒不差的。7.2 八种内存淘汰策略maxmemory-policy 怎么选当 Redis 内存达到maxmemory上限时会触发内存淘汰策略。这个策略不是随便设的它直接决定了哪些数据会被保留、哪些会被清理。常用策略如下maxmemory-policy行为适用场景noeviction不淘汰数据写命令直接返回错误不能容忍缓存丢失的核心数据allkeys-lru从所有 key 中淘汰最近最少使用的通用缓存最常用volatile-lru只从设置了 TTL 的 key 中淘汰最近最少使用的缓存与永久 key 混合存储allkeys-lfu从所有 key 中淘汰访问频率最低的冷热数据访问频率差异明显的场景volatile-lfu只从设置了 TTL 的 key 中淘汰访问频率最低的访问频率模型清晰的数据allkeys-random从所有 key 中随机淘汰所有 key 访问概率均等volatile-random只从设置了 TTL 的 key 中随机淘汰操作均匀且带 TTLvolatile-ttl从设置了 TTL 的 key 中淘汰剩余时间最短的优先保留新鲜数据我的默认习惯是 allkeys-lru因为绝大多数缓存业务都符合“热点数据频繁访问冷数据长时间无人问津”的规律。需要注意如果业务中有一些 key 是长期存在的配置项不希望被淘汰那应该把它们归到一种单独的存储逻辑里比如用固定前缀区分并在淘汰策略上选择 volatile-lru保证永久 key 不会被清掉。7.3 内存监控与调优用 info 命令看门道配置完成不代表一劳永逸上线后还要会看指标。最常用的命令是redis-cli info memory它会输出当前 Redis 已用内存、峰值内存、碎片率等关键数据。used_memory_human直接看当前占用mem_fragmentation_ratio是碎片率正常情况下在 1~1.5 之间如果远大于 1.5说明内存碎片化严重可能需要重启或执行内存整理。还有一个常见问题为什么内存明明没到 maxmemory却感觉响应变慢了这时要看info stats里的evicted_keys如果这个值在持续增长说明淘汰策略已经在高频工作了说明 maxmemory 设置不合理或数据过多需要扩容或清理无用缓存。我踩过的坑是给 Redis 设了一个很小的 maxmemory结果高峰流量一来evicted_keys 暴涨大量缓存被过期淘汰缓存命中率直线下降数据库压力反而更大了。调参前一定要先观察真实内存增长曲线。8. 主从复制与哨兵模式Redis 高可用的最小完整方案8.1 主从复制的同步原理先全量再增量单点 Redis 最怕的是宕机一旦挂了所有依赖缓存的请求都会压到数据库。主从复制是解决单点问题的第一步一台主节点负责写多台从节点负责读和冗余备份。从节点通过REPLICAOF指令指定主节点REPLICAOF 192.168.1.10 6379第一次连接时从节点会请求全量同步主节点把当前数据生成 RDB 快照发给从节点从节点加载后再持续接收主节点随后的写命令并执行。此后进入增量同步阶段主节点把写命令发送到复制积压缓冲区从节点持续拉取执行。这个机制里有几个关键点全量同步比较耗时如果主节点数据量很大从节点的首次同步可能持续几秒甚至更久复制是异步的主节点写成功不等待从节点确认所以从节点数据有轻微延迟。生产环境里从节点通常设置为只读防止客户端误写从节点导致数据不一致。如果你观察到主从数据差异很大优先检查网络延迟和从节点的处理能力而不是怀疑 Redis 复制协议有问题。8.2 哨兵模式监控、通知与自动故障转移主从复制本身只能做冗余和读写分离不能自动处理故障。如果主节点宕机了从节点不会自动升级为新的主节点整个写服务就断掉了。哨兵Sentinel就是来解决这个问题的它会不断监控主节点和从节点的健康状态发现主节点下线后会从从节点中推举一个成为新的主节点并把其他从节点重新指向新主节点随后通知客户端新主节点的地址。这个动作叫故障转移。一个细节值得注意哨兵通常要部署奇数个节点至少三个因为它依赖“多数派”来决定主节点是否真的下线。如果只有两个哨兵网络分区时可能无法达成共识。很多人入门时直接在单机上跑一个哨兵做实验看效果是可以的但生产环境必须按奇数节点部署。8.3 Docker Compose 搭建主从哨兵的完整配置用 Docker Compose 搭一套“一主一从一哨兵”的环境是练习高可用最好的方式。先准备 sentinel.confsentinel monitor mymaster redis-master 6379 1 sentinel auth-pass mymaster 123456 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 10000注意这里mymaster是自定义的监控名称redis-master是 Docker 网络里的容器主机名不是本机 IP。sentinel monitor ... 1最后的 1 表示一个哨兵认定主节点下线就触发故障转移。再写 docker-compose.ymlservices: redis-master: image: redis:7.4 container_name: redis-master command: redis-server --appendonly yes --requirepass 123456 ports: - 6379:6379 networks: - redis-net redis-slave: image: redis:7.4 container_name: redis-slave depends_on: - redis-master command: redis-server --slaveof redis-master 6379 --masterauth 123456 --requirepass 123456 networks: - redis-net redis-sentinel: image: redis:7.4 container_name: redis-sentinel depends_on: - redis-master - redis-slave volumes: - ./sentinel.conf:/etc/redis/sentinel.conf command: redis-sentinel /etc/redis/sentinel.conf networks: - redis-net networks: redis-net:启动之后在哨兵容器里执行redis-cli -p 26379 info sentinel如果看到Sentinels1、Slaves1说明哨兵已经正确感知整个拓扑。这里有一个很容易困惑的点如果 start 日志里没有出现monitor master mymaster这条消息大概率是 sentinel.conf 里的容器名解析不了或者mymaster名称不一致。另外sentinel 运行时会尝试把状态写回配置文件如果文件权限是只读启动会有异常或更新失败给 sentinel.conf 加上写权限可以避免这个坑。验证故障转移最简单的办法是docker stop redis-master过一会儿再查看哨兵日志你会看到它自动完成了从节点推举和切换。9. 可视化客户端、序列化注意点与面试高频自测9.1 趁手的可视化客户端怎么选命令行玩得再溜日常开发时也需要一个可视化客户端来查看 key 和数据的分布。Redis 官方推出了 RedisInsight界面现代支持数据浏览、命令分析、慢查询查看而且对 Redis 系列版本支持得很全。如果你更习惯开源免费的工具还有个 Another Redis Desktop ManagerARDM它同时支持 Windows、macOS、Linux连接管理做得不错适合本地日常调试。热搜词里也经常能看到 Redis Desktop Manager一些版本在旧系统上反而更稳定选哪个不强求关键是别忽略加密连接和密码认证生产环境连接一定要走 TLS别为了省事在公网裸连 Redis。连接不上时按这个顺序排查先redis-cli ping确认服务本身正常再检查 bind 配置、端口监听、密码认证最后看云安全组和本地防火墙。这个排查顺序能覆盖 90% 的“可视化工具连不上 Redis”问题。9.2 序列化与日志两个容易被忽略的细节“Redis 序列化”在很多 Java 项目里是个会莫名从缓存取不到数据的问题。比如使用 Spring Data Redis 时如果不自定义序列化器默认会用 JDK 序列化key 前面会带一堆类型字节value 是一长串不可读的二进制内容存进去之后在 Redis 里长得完全不像你预期的数据。更麻烦的是不同版本之间 JDK 序列化的兼容性很差一旦对象的类结构变化从缓存里反序列化就可能直接报错。我的建议是key 一律用 String 序列化并加上业务前缀value 根据团队技术栈选 JSON、protobuf 或 msgpack统一封装在客户端配置里不要在业务代码里散落着各自不同的序列化方式。日志方面新手往往盯住持久化日志忽略了 Redis 自身的慢查询日志。配置slowlog-log-slower-than 10000单位微秒这里表示 10ms和slowlog-max-len 128然后通过SLOWLOG GET查看哪些命令耗时过长。很多“Redis 变慢”的排查第一步就是看慢查询排除掉大 key 和复杂命令再往下分析网络和内存碎片。9.3 面试高频考点把这些点串成一个自测清单Redis 是面试里出现频率极高的中间件围绕入门知识问到的问题基本是这几类为什么 Redis 那么快、单线程为什么还能高效、数据类型的底层实现、缓存三大难题、分布式锁、持久化、淘汰策略、主从哨兵。我整理了一份自己面试别人时也会用的检查清单能解释 Redis 的高性能来自内存存储、单线程避免锁竞争、IO 多路复用、高效数据结构四者叠加。能说清 6.0 多线程到底多线程在哪里网络读写使用多线程命令执行仍是单线程。能说出 String、Hash、List、Set、ZSet 各至少两个典型业务场景。能画出主从全量同步的步骤说出复制积压缓冲区的作用。能说明哨兵故障转移的大致流程以及为什么要奇数个哨兵。能写出正确的分布式锁命令和释放锁的 Lua 脚本。能说出 RDB、AOF、混合持久化的区别和适用场景。这些点本质上都是这篇文章每个章节压缩出来的核心。能把它们完整讲清楚Redis 入门这一关就算真正迈过去了。最后再说一个从实际项目里得到的体会别急着追新版本和新功能先把五种数据结构用熟、把持久化和内存淘汰这两种“保命配置”弄懂再逐步掌握主从哨兵和分布式锁。很多线上故障不是 Redis 不够强而是使用者对它的工作机制理解存在盲区。希望这篇文章能帮你把这些盲区一个个补齐。