1. 为什么是 Redis先搞清楚缓存到底解决了什么问题我见过太多人一上来就敲redis-server把服务跑起来了然后照着网上的教程set key value再get key最后对着终端发呆——然后呢然后就没有然后了。这不是你的问题是整个学习路径出了问题。你学的是 Redis 的操作命令但没学 Redis 要解决的那个问题。在正式开始操作之前我们得先回答一个看似废话、但绝大多数人答不清楚的问题缓存技术到底在解决什么想象一个场景你在做一个电商网站首页要展示热销商品列表。没有缓存的时候每个用户打开首页后端都要去数据库里查一次商品表关联库存、价格、评论数可能还得调一次推荐算法的接口。平时流量不高还好一到双十一或者某个主播帮你带了一波货数据库的连接数瞬间被打满查询响应从 5 毫秒变成 500 毫秒再变成 5 秒。用户等不了 5 秒用户会关掉页面用户会去别家买。缓存的思路极其朴素把那些被反复查询、又不容易变动的数据放到一个更快的存储介质里。下次再有人问同样的问题直接从这个更快的介质里取不去打扰数据库。那 Redis 为什么是干这件事的首选因为它跑在内存里。内存的随机读写速度是纳秒到微秒级别而磁盘即使是固态硬盘也要几十微秒到几百微秒。如果再加上网络传输和数据库 SQL 解析执行的开销差距会被拉到几十倍甚至上百倍。Redis 单实例的读写性能可以轻松突破 10 万 QPS这在数据库层面是非常难做到的。更关键的是Redis 不只是快这么简单。它支持 String、List、Hash、Set、ZSet 五种基础数据类型还有后续的 Stream、HyperLogLog 等这意味着你能用缓存解决的不只是按 key 查 value这一种需求还能做排行榜、去重统计、消息队列、分布式锁等一系列事情。这也是为什么 Redis 在面试题里出现频率那么高——因为它就是个瑞士军刀看起来简单用好了是架构利器。顺便说一下正文里提到的安装、数据类型、分布式锁、缓存穿透这些热搜词其实就对应了这个工具从上手到实战再到排障的完整链路。这一篇我会按照这个链路来写你跟着走完基本就能达到能干活、能面试、能排查问题的水平。2. 五分钟跑起来Windows / Linux / macOS / Docker 四种安装姿势官方文档推荐的安装方式是源码编译但如果你只是学习我建议怎么快怎么来。先把服务跑起来看到PING返回PONG建立一点正反馈再回头研究编译参数也不迟。2.1 各平台安装速览既然热搜词里反复出现redis windows 下载macos 安装 redisdocker 安装 redis我就把这三种方式都列出来加上 Linux 下的常见做法方便你按自己的环境对号入座。环境推荐方式核心命令备注Windows微软维护的 Memurai 或官方未正式支持的 Redis for Windows直接下载 msi 安装包安装后redis-server --service-install官方不支持 Windows但学习够用macOSHomebrewbrew install redis brew services start redis会自动注册为后台服务Linux (apt)包管理器sudo apt-get install redis-server仓库里版本可能偏旧学习可用Docker官方镜像docker run -d --name redis -p 6379:6379 redis:7最干净不污染宿主机环境我在实际工作中遇到的情况是很多人卡在安装这一步就直接放弃了。所以这里我给你一个忠告——但凡遇到安装问题立刻切换到 Docker 方式。镜像拉下来端口映射好什么都不用装环境干干净净。2.2 Docker 方式详解为什么我建议你用这个Docker 安装命令长这样docker run -d \ --name redis \ -p 6379:6379 \ -v redis-data:/data \ redis:7-alpine拆开解释一下-d表示后台运行--name redis给容器起名字方便之后用docker exec -it redis redis-cli进容器操作-p 6379:6379把宿主机 6379 端口映射到容器的 6379这样宿主机的客户端工具也能连上-v redis-data:/data挂载数据卷Redis 的持久化文件 RDB 会写在容器内/data挂载出来之后即使容器删了数据还在跑起来之后验证一下是否正常docker exec -it redis redis-cli ping如果返回PONG说明服务已经跑起来了。这时候你就可以用任意客户端连接127.0.0.1:6379了。注意你如果是在 Windows 上玩 Docker记得用 PowerShell 或 CMD 测试连接时确保 Docker Desktop 处于运行状态。另外 macOS 上的 Docker 也是同理。2.3 连接客户端redis-cli 与可视化工具Redis 自带命令行客户端redis-cli这是最可靠的工具任何环境都能用而且排查问题的时候命令行永远比图形界面高效。redis-cli -h 127.0.0.1 -p 6379进去之后敲几个命令感受一下127.0.0.1:6379 set mykey hello redis OK 127.0.0.1:6379 get mykey hello redis 127.0.0.1:6379 type mykey string命令行适合快速验证但如果数据量大了或者你要浏览某个业务模块下的几十个 key命令行就不太直观了。这时候就需要可视化工具。可视化工具里现在最主流的两个是Redis Desktop ManagerRDM和Another Redis Desktop ManagerAnotherRedisDesktopManager。RDM 老牌但是商业授权AnotherRedisDesktopManager 是开源免费的跨平台支持 Windows / macOS / Linux我目前主力用的是后者。用可视化工具做的事情主要有几个浏览 key 列表、查看 key 的 TTL过期时间、删除某个特定的 key、观察内存占用情况。排查线上问题的时候连接配置里记得填对密码测试环境可以留空生产环境必须有密码。3. 五种基础数据类型不只是存字符串那么简单Redis 的全部魅力都在它的数据类型上。如果面试问Redis 为什么快除了内存之外第二个要答的点就是数据类型的精巧设计。五种类型每一种都是被设计出来解决一类问题的。3.1 String最简单的结构最广泛的应用String 是 Redis 最基础的数据类型一个 key 对应一个 value。你存一个字符串、一个数字、一个 JSON 序列化后的对象都属于 String。127.0.0.1:6379 set user:1001 {name:张三,age:30} OK 127.0.0.1:6379 get user:1001 {\name\:\张三\,\age\:30}String 有四个高频操作要记住SET、GET、INCR、EXPIRE。其中INCR特别值得展开讲因为热搜词里出现了 redis incr不准。INCR是把 key 存的数字加一。它的特点是原子性——多个客户端同时执行 INCR不会出现并发加一导致结果偏小的问题。这在计数器场景比如文章阅读量、点赞数、库存扣减里非常好用。但有人反馈 incr不准这个声音通常集中在两种情况下第一种是 Redis 版本本身有 bug 吗不是。Redis 的 INCR 在单机上非常准因为它是单线程模型所有命令天然串行执行。第二种就常见了跨多个 Redis 实例或 Redis 集群时如果用多个 key 分别计数再汇总那汇总结果一定不对。比如你有三个 Redis 节点把用户请求散列到不同节点分别 INCR最后你统计总数时要自己在应用层做聚合这就可能因为延迟或数据一致性问题导致统计不准。还有一种情况是囤货倒卖抢购场景你在 INCR 之后又做了其他业务操作比如发送响应给前端如果 Redis 持久化配置不当或者发生主从切换计数可能会回退。所以记住INCR 的准确性在单实例上是可靠的但跨实例、跨网络时必须自己设计好汇总方案。3.2 Hash和对象天生一对Hash 类似于编程语言里的 map一个 key 下面可以存多个字段。这特别适合存储一个对象的多个属性。比如存一个用户对象127.0.0.1:6379 HSET user:1002 username 李四 age 25 city 上海 (integer) 3 127.0.0.1:6379 HGETALL user:1002 1) username 2) 李四 3) age 4) 25 5) city 6) 上海 127.0.0.1:6379 HGET user:1002 age 25它比 String 的好处是可以单独读写某个字段不用每次都把整个对象序列化后整个读出来。比如只改用户的 cityHash 只需要 HSET 一个字段String 的话得先 GET 出来反序列化改字段再 SET 回去开销大还容易出错。所以如果你用 Redis 存对象属性优先用 Hash。这个选择我从一开始就建议做对否则后面数据量规模上来你会因为每个对象都占了一整个 JSON 字符串而难受死。3.3 List满足队列、时间线、评论列表等需求List 是一个双向链表。可以从左边插入LPUSH右边插入RPUSH左边弹出LPOP右边弹出RPOP。它天然适合做消息队列。生产者用 LPUSH 往左边塞数据消费者用 RPOP 从右边取数据先进先出。127.0.0.1:6379 LPUSH task:email send email to user1001 (integer) 1 127.0.0.1:6379 LPUSH task:email send email to user1002 (integer) 2 127.0.0.1:6379 RPOP task:email send email to user1001你会看到一个特性RPOP 弹出来的是最早 LPUSH 进去的元素也就是先进入队列的任务先被处理。这才是符合业务直觉的队列行为。当然Redis 做消息队列是简化版没有消息确认机制也没有复杂的消费者组管理。真正要求高可靠的消息队列还是得上 Kafka 或 RabbitMQ。但如果你是内部异步任务、量级不大、丢失容忍度高List 型的轻量队列完全够用。3.4 Set去重、抽奖、共同好友Set 是无序、不重复的集合。你去重用 Set你判断一个元素是否存在用 Set你想做随机抽奖也用它。常用命令SADD key member添加元素SREM key member删除元素SMEMBERS key列出所有元素SISMEMBER key member判断是否存在SINTER key1 key2取交集SCARD key取集合数量举一个实际例子。你的社区网站要做共同好友推荐每个用户的好友列表存成一个 Set然后两个用户之间的共同好友就是两个 Set 的交集127.0.0.1:6379 SADD user:1:friends user2 user3 user4 (integer) 3 127.0.0.1:6379 SADD user:2:friends user3 user4 user5 (integer) 3 127.0.0.1:6379 SINTER user:1:friends user:2:friends 1) user3 2) user4一条命令就能算出共同好友数据库如果要算这个交集得写 JOIN 语句或者应用层循环Redis 里是 O(N) 复杂度性能完全不一样。3.5 ZSet有分值的排序集合排行榜的不二选择ZSet 在 Set 的基础上加了一个 score分值Redis 会按照 score 自动排序。它是实现排行榜最优雅的方案。127.0.0.1:6379 ZADD leaderboard 100 player1 (integer) 1 127.0.0.1:6379 ZADD leaderboard 95 player2 (integer) 1 127.0.0.1:6379 ZADD leaderboard 120 player3 (integer) 1 127.0.0.1:6379 ZREVRANGE leaderboard 0 -1 WITHSCORES 1) player3 2) 120 3) player1 4) 100 5) player2 6) 95ZREVRANGE是从高到低排序输出排行榜。日常用到的场景还有直播平台的礼物排行榜电商活动的销量排行游戏服务器的段位榜文章的实时热度榜ZSet 的底层实现是跳表Skip List插入、删除、查找的时间复杂度都是 O(log N)所以数据量大到几百万条排行榜操作依然是毫秒级。面试时如果被问到为什么 ZSet 用跳表而不是平衡树回答方向是跳表实现简单、支持范围查找、内存占用可控这是比较稳妥的答案。4. 持久化与淘汰策略数据不丢与内存不爆的两条保险丝学 Redis 最容易忽视的就是持久化机制。很多人以为内存数据库重启了就什么都没了其实 Redis 提供了完整的持久化方案用得好可以做到重启后数据快速恢复。4.1 RDB 快照持久化RDB 方式会在指定时间间隔内把内存中的数据集快照写入磁盘dump.rdb 文件。默认配置下如果 1 小时内改了 1 次数据或者 5 分钟内改了 100 次数据Redis 就会触发一次快照生成。这就像你玩单机游戏时手动存档。缺点是如果 Redis 异常宕机最后一次快照之后新写入的数据会丢失。丢失多少取决于快照触发频率。4.2 AOF 追加日志持久化AOFAppend Only File的方式是把每一条写操作命令追加到日志文件里。Redis 重启时通过重放日志把数据恢复出来。AOF 有三种刷盘策略策略行为数据安全性性能影响appendfsync always每次写命令都同步到磁盘最安全几乎不丢数据慢appendfsync everysec每秒同步一次最多丢 1 秒数据快appendfsync no由操作系统决定何时刷盘可能丢较长时间数据最快生产环境最常用的组合是AOF everysec RDB 定时快照。这样兼顾了恢复速度和数据安全。我自己的配置里还会设置auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb让 AOF 文件在膨胀到一定程度后自动重写防止日志文件无限增长。4.3 内存淘汰策略别让 Redis 被写爆Redis 是内存数据库内存是有限的资源。如果往 Redis 里写数据写满了会怎样默认情况下Redis 会直接拒绝写入报错OOM command not allowed when used memory maxmemory。生产环境发生这种事就是事故。所以你要主动配置淘汰策略。在 redis.conf 中设置maxmemory-policy常见选择noeviction默认策略不淘汰拒绝写入allkeys-lru从所有 key 中按 LRU 淘汰最少使用的volatile-lru从设置了过期时间的 key 中按 LRU 淘汰allkeys-random随机淘汰任意 keyvolatile-ttl从设置了过期时间且剩余时间最短的 key 中淘汰我的经验是如果这个 Redis 完全用作业务缓存用allkeys-lru最省心。因为它不会因为某个缓存 key 没有设置过期时间就疯狂占用内存写满之后会自动先把最久没用的清掉。但如果你在里面存了用户会话、分布式锁这类绝对不能丢的 key就不能这么选你得把这些数据放到独立的 Redis 实例里或者给这类 key 统一加前缀配合volatile-lru使用。再配合expire过期时间设置Redis 的内存管理才算完整。比如缓存商品详情5. 缓存穿透、缓存击穿、缓存雪崩三个必会的经典问题与治理方案搜索引擎热搜词里redis缓存穿透的出现率极高面试问这场面的概率也极高。这三个问题其实描述的是缓存系统在不同故障形态下的表现。5.1 缓存穿透查询了一个不存在的数据缓存穿透是指查询的数据在缓存和数据库中都不存在。比如你的电商系统里用户查询商品 ID 为 99999999 的商品这个商品根本没有每次请求都会直接穿透缓存到数据库数据库查出来没有又不会写缓存。大量这种请求一来数据库承受了所有压力。解决办法有三种第一缓存空值。查不到数据库就写一个 null 到缓存里设置一个较短的过期时间比如 60 秒。这样同样 key 的请求直接命中空缓存不会打到数据库。第二布隆过滤器Bloom Filter。在请求到达 Redis 之前先用布隆过滤器判断这个 key 是否存在。布隆过滤器说不存在就一定不存在说可能存在则可能误判。把所有合法 ID 预先存入布隆过滤器查询前先过滤掉非法 ID。第三参数合法性校验。比如商品 ID 必须大于 0且符合数字格式。随手拦截掉明显非法的请求这在网关层面就能做。我的建议是线上系统两者都上。布隆过滤器挡掉非法 key缓存空值兜底合法的临时 key。5.2 缓存击穿热点 key 过期的瞬间缓存击穿和穿透只有一字之差但完全不同。击穿是指某个非常热点的 key 正好在某个时刻过期了瞬间大量请求同时打到数据库。比如一个爆款商品的详情被缓存了缓存过期时间是 1 小时。到了 1 小时的那一刻刚好有 1 万人同时点开这个商品大家都发现缓存里没有就一起冲向数据库。解决的思路有几种第一互斥锁。在缓存失效时不是立刻去查数据库而是先获取一个分布式锁。只有拿到锁的线程才能去查数据库查到后写回缓存其他线程等待后从缓存读取。代价是请求的响应时间会略微变长。第二逻辑过期。不设置物理过期时间而是给缓存数据里额外放一个逻辑过期时间字段。读取时检查逻辑时间是否过期如果没过期就直接返回如果过期了就后台异步刷新缓存。这是避免性能损耗的比较好的办法。第三热点 key 永不过期。如果是更新不频繁的数据干脆永远不设置过期时间由后台定时任务主动更新缓存。5.3 缓存雪崩大量 key 同时过期缓存雪崩是缓存层大面积失效或者 Redis 集群整体宕机导致大量请求直接打到数据库。常见诱因有几种大量 key 设置了相同的过期时间比如缓存冷启动时把所有商品都缓存 1 小时1 小时后全部同时过期缓存服务器宕机整个缓存层不可用应对方案过期时间加随机值。每个 key 的 TTL 不要用固定值而是在一个区间内随机。比如 3600 秒加上 0 到 300 秒的随机值避免同时过期多级缓存。Redis 之上再用一层本地缓存Caffeine 或 Guava CacheRedis 挂了还有本地缓存兜底Redis 高可用。部署主从架构和哨兵Sentinel或直接用 Redis Cluster 集群避免单点故障流量削峰。如果预计有大流量涌入可以在网关层限流5.4 分布式锁用 Redis 解决多服务竞争问题分布式锁这个热搜词也是面试高频。场景是这样的你有多个服务实例比如三个 Java 服务同时处理同一个订单的退款如果不加锁三个实例都去操作数据库就会重复退款。用 Redis 实现分布式锁的主流方式基于 SET NX EX 的原子操作SET lock:order:1001 token_value NX EX 30这条命令的意思是仅当lock:order:1001不存在时设置这个 key并设置 30 秒过期时间。这是原子操作多个客户端同时执行时只有一个能成功成功的那个就拿到了锁。释放锁时要小心不能直接 DEL要先用 GET 检查值是否是自己的 token再用 Lua 脚本原子地删除if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end为什么要这样做因为锁可能已经自动过期了被其他线程拿到。你直接 DEL 会把别的线程的锁删掉引发并发问题。先比较 token 再删除可以保证只释放自己的锁。更专业的分布式锁方案是 RedLock 算法但实际工程中使用较少能用 Redis Cluster 合理过期时间的加锁方案覆盖大多数场景。真正要求严格的生产系统会引入 etcd 或 Zookeeper 来实现高可靠的分布式锁。面试时你可以先说 RedLock 的基本思路再补一句生产中需要权衡可靠性与复杂度这会显得你有真实落地经验。6. 连接、序列化与日志日常开发和排障绕不开的三个细节这部分通常没人系统讲但在实际干活时总踩坑。我自己带的团队里新人犯的错几乎都集中在这几处。6.1 序列化问题你存进去的和读出来的不一样当我们使用 Java / Python / Go 等语言的 Redis 客户端库时数据要经过序列化才能存储。不同的客户端设置不同的序列化器可能造成同一个 key在 A 服务里能读在 B 服务里读到乱码的情况。最常见的案例是项目里用了 FastJSON 序列化了一个对象然后读取时用了 Jackson。两者对字段名、类型、泛型的处理差异让你感觉数据坏了。我的建议统一用一个全局序列化方式别多个库混用。如果你在 Spring Boot 里用 RedisTemplate设置GenericJackson2JsonRedisSerializer作为 value 序列化器并且让所有服务都依赖同一份 Redis 配置。如果涉及跨语言调用Java 和 Go 都要读写同一个 key干脆约定用字符串存 JSON 原文不要用语言自带的序列化保证可读性和兼容性。6.2 连接池配置为什么突然连不上 RedisRedis 本身可以扛很多连接但客户端这边如果没配置好连接池服务一启动就可能出现连接超时或连接数不够。以 Java 的 Lettuce 为例连接池的核心参数一般是maxTotal最大连接数maxIdle最大空闲连接数minIdle最小空闲连接数maxWaitMillis获取连接的超时时间调优思路是这样的先估算你的并发请求量和单请求 Redis 操作耗时。假设高峰并发 1000单个 Redis 操作 1 毫秒一个连接一毫秒内可以处理一个请求那 1000 并发需要约 1000 个连接。当然实际操作中连接会被复用通常maxTotal设置为并发数的 1/10 左右起步再压测观察。有个常见坑maxWaitMillis设置太短比如默认 1 秒当并发尖峰来临时获取连接等待超时业务直接报错。这时候很多人会误以为是 Redis 挂了其实是连接池没调好。6.3 Redis 日志慢查询日志和运行日志排障时最有价值的是 Redis 的慢查询日志。在 redis.conf 里配置slowlog-log-slower-than 10000 slowlog-max-len 128表示超过 10000 微秒10 毫秒的命令会被记录。运行SLOWLOG GET查看慢命令127.0.0.1:6379 SLOWLOG GET 10慢查询常见的元凶有KEYS命令全量扫描 key、HGETALL大哈希、SMEMBERS大集合、以及大批量MGET但 key 分散在不同 slot 的场景。运行日志则是 Redis 自己输出的日志文件。排查启动失败、主从同步断开、内存打满等问题时要看这个文件。默认在logfile 表示输出到标准输出Docker 方式下用docker logs redis查看。注意线上禁止使用KEYS命令。它会阻塞 Redis 主线程数据量一大整个服务卡死。如果确实要查询 key可以用SCAN命令它是游标式的增量遍历不会阻塞。7. 部署模式进阶主从复制、哨兵与集群到底该选谁大家搜redis哨兵模式和集群模式的区别其实就是想知道自己的业务该选哪种。Redis 部署从简单到复杂有这么几个形态。单机模式最简单但单点故障自不必说机器挂了数据就没了服务也断了一条命令都不用学就能搭出来。主从复制模式是给单机加了一个备份主节点写、从节点同步。主节点宕机时需要手动把从节点提升为主节点这中间会出现服务中断。哨兵模式就是自动化的主从切换哨兵节点监控主从的健康状态主节点挂了自动把从节点升为新的主节点实现故障转移。Redis Cluster 则是把数据分片到多个主节点每个主节点还可以有从节点容量和性能都能水平扩展。用一句话总结主从负责备份哨兵负责自动故障切换集群负责数据分片。如果你的数据量没超过单机内存QPS 也不是巨型量级用哨兵模式就够了复杂度完全可控官方也一直在完善哨兵的稳定性遇到故障切换的误差通常在秒级内。如果数据量超过单机物理内存或者 QPS 要求几十万以上那才需要 Redis Cluster。三种模式没有绝对的哪个更好而是哪个更匹配你的业务规模。8. 从会用走向会用明白我踩过的一些坑文章写到这该给你留点真正从实操里长出来的经验了。最后分享几个我实际工作里踩过的坑希望你能绕过。第一个坑Redis 挂载数据卷权限不对。用 Docker 跑 Redis 时宿主机上的数据目录如果没有正确权限容器会启动失败日志里报.rdb文件无法写入或者容器频繁重启。解决办法是给数据目录分配可写权限比如chmod 777 redis-data或者指定正确的 UID注意千万别为了省事直接把整个目录权限改成 777。第二个坑没有给连接设置密码。测试时的 Redis 裸奔没问题但一旦暴露到公网就会被扫描工具瞬间入侵植入挖矿脚本。我用过一次血的教训换来的经验通过CONFIG SET requirepass或修改 redis.conf在任何写操作之前先设密码。并且不要用弱口令。第三个坑误用 INFRA 内存存非业务数据。有段时间我们把日志摘要也放在 Redis 里一堆log:2024-01-*的 key 堆积。等发现时内存已经快满了清理的时候不得不重启整个 Redis 才能释放。所以 Redis 里只放有价值的数据日志还是老老实实交给日志系统。第四个坑持久化策略和生产环境不匹配。默认的 RDB 配置在流量很大的写密集场景下可能导致频繁 fork 子进程做快照期间会产生短暂的卡顿。如果你对响应时间极其敏感把auto-aof-rewrite的参数调好并且适当调大 RDB 触发的阈值减少不必要的 fork。第五个坑把过期时间全部设成同一秒。我在压测环境里遇到过缓存雪崩就是因为测试程序把一万个 key 统一设置了EXPIRE 3600。一小时后数据库直接被打挂。之后所有缓存 key 的 TTL 我一定会加随机偏移。Redis 这个工具的学习曲线其实是陡峭的——不是因为它难上手而是因为它太容易上手导致你以为会了结果遇到大量并发、内存紧张、主从切换问题时才发现处处是坑。希望这篇文章能帮你少走一些弯路。把基础命令弄熟把持久化和淘汰机制弄清再动手做一些分布式锁、排行榜、消息队列之类的小项目你对 Redis 的理解就会非常扎实了。