接触 Redis 也快十年了从最初只是把它当成一个高级缓存来用到后来在排行榜、分布式锁、消息队列这些场景里反复折腾我越来越觉得这个工具属于“门槛低但水很深”的典型代表。写这套超详细的入门教程是想把新手最需要理解、也最容易踩坑的部分一次讲清楚核心数据结构、持久化机制、缓存设计里的经典问题以及生产环境的配置和安全加固。不管你是刚学后端的学生还是工作里第一次要接 Redis 的开发者这篇文章应该能帮你少走不少弯路。1. 先弄清 Redis 到底在解决什么问题1.1 为什么把数据放在内存里很多人第一次接触 Redis只知道“它是一个缓存”但并没有仔细想过“缓存到底解决了什么”。我们先看一个最简单的场景某个接口每次请求都要从数据库查用户信息数据库的数据存在磁盘上。磁盘虽然容量大、价格便宜但随机读取的延迟通常在毫秒甚至几十毫秒级别。当请求量上来之后数据库的 CPU 和 IO 很快就成为瓶颈。这时候如果有一个工具能把热点数据放到内存里内存读取延迟是微秒到几百微秒级别差距可能是几十倍接口响应时间自然就下来了。Redis 就是干这个的。它把数据保存在内存中并且用单线程模型处理命令配合高效的数据结构在普通机器上每秒能处理的请求量可以轻松达到十万级别。这个性能数据是我在实际压测中见过的不是理论值。有一个很关键的点Redis 的单线程模型让它在处理命令时不需要频繁切换线程上下文也不存在多线程竞争锁的问题所以虽然只有一个线程干活反而能保持非常稳定的低延迟。1.2 缓存之外Redis 还能干什么如果只把 Redis 当缓存用格局就小了。我排一下在实际工作中最常见的几类用途方便你建立整体印象会话存储登录状态、购物车数据存 Redis 比存服务内存更可靠服务重启也不丢。排行榜有序集合天然支持按分数排序直播打赏榜、游戏积分榜基本都是这么做的。计数器INCR、DECR 是原子操作用来做点赞数、访问量、库存扣减都非常合适。分布式锁多个服务实例操作共享资源时用 Redis 的 SETNX 加过期时间实现互斥。发布订阅和消息队列LIST 的阻塞命令可以做简单的消息队列Stream 类型能承载更复杂的消费场景。延迟队列、附近的人、抽奖去重这些玩法也是基于数据结构和命令组合出来的。入门阶段不用把这些全部掌握但心里要有数Redis 不是只能做缓存很多高并发场景的解决方案都离不开它。理解了这一点你学习的时候就会更加重视“数据结构”这条主线因为不同的场景本质上是对不同数据结构的灵活运用。2. 环境准备安装、启动与第一个命令2.1 Linux 环境安装绝大多数服务器跑的是 Linux所以我先把 Linux 安装方式放在最前面。常见发行版里Debian/Ubuntu 用 aptCentOS/RHEL 用 yum。以 Ubuntu 为例sudo apt update sudo apt install redis-server安装完成后Redis 通常会自动作为服务启动验证一下版本redis-cli ping redis-cli -v我第一次安装的时候遇到过 redis-cli 已经装好了但 redis-server 没启动的情况ping 会报连接失败。这时候检查服务状态手动启动即可sudo systemctl status redis-server sudo systemctl start redis-server sudo systemctl enable redis-server生产环境我更推荐用编译安装因为可以自己选择版本并调整编译参数。老规矩下载稳定版源码包、解压、make、make install。编译过程需要 gcc 等基础工具碰到缺少依赖就先安装依赖。编译安装的好处是目录可控适合对服务有定制需求的场景。2.2 Windows本地学习怎么跑Redis 官方没有发布 Windows 版本但本地学习和调试经常是在 Windows 机器上进行的。我推荐两个省事的方式。第一个是使用微软维护的 Redis 分支或社区编译版网上可以找到。直接下载压缩包解压后运行 redis-server.exe然后另开一个命令行窗口运行 redis-cli.exe就能进入交互模式。第二个更推荐用 Docker 跑一个容器命令是docker run -d --name redis-dev -p 6379:6379 redis:7容器启动后本机也可以直接使用 redis-cli 连接或者再起一个临时容器执行客户端命令docker exec -it redis-dev redis-cli2.3 验证基础操作不管用哪种方式启动之后先做这几件事redis-cli 127.0.0.1:6379 SET hello world 127.0.0.1:6379 GET hello 127.0.0.1:6379 KEYS *能看到“world”返回说明环境没问题。这里提醒一句KEYS * 在开发环境玩玩可以生产环境千万别乱用它会阻塞 Redis 进程。后面讲生产配置的时候我再展开。3. 核心数据结构与常用命令解析Redis 的入门重点就是五大数据结构String、Hash、List、Set、ZSet。很多新手看教程的时候觉得自己都懂了但实际用起来总是纠结“这种情况该用哪种结构”。这一节我会把每个结构的典型场景和命令一起讲而不是单纯罗列命令。3.1 String最基础也最实用String 在 Redis 里不只是文本也可以是数字。它支持原子自增自减所以特别适合做计数器。常用命令SET key value GET key SETNX key value INCR key DECR key EXPIRE key seconds TTL key实际中会遇到这么几个问题。第一个问题是“为什么 SETNX 可以用来实现分布式锁”。SETNX 只有在 key 不存在时才设置成功所以多个进程同时请求时只有一个能拿到锁。但光 SETNX 不够还要用 EXPIRE 给锁加上超时时间否则进程崩溃后锁永远不会释放。更好的做法是用 SET 命令的扩展参数SET lock_key token EX 10 NX这一条命令同时实现了“不存在才设置”和“10 秒后过期”是一条原子命令。分布式锁细节非常多后面我可以单开一篇但入门阶段把这条命令吃透就够了。第二个常见问题是“数据为什么不更新”。比如我缓存了用户信息数据库里改了名字缓存里还是旧值。解决办法不是删掉缓存后让请求重新回源而是更新数据库后主动删除缓存或者更新缓存。经验做法是先更新数据库再删除缓存下一次请求发现缓存没有就会从数据库读取并重建缓存。3.2 Hash对象数据的最优解如果有一个对象要存比如用户信息包含昵称、年龄、积分最直观的方案是搞一个大 JSON 字符串塞进 String。但你更新其中一个字段的时候就得把整个字符串读出来修改再写回去既慢又容易出错。Hash 就是专门解决这个问题的它把对象拆成 field-value 对HSET user:1001 name Alice age 25 HGET user:1001 name HGETALL user:1001 HDEL user:1001 age HINCRBY user:1001 score 10内存里它长这样“user:1001” 是 key里面是一个小的字典。要改哪个字段就操作哪个字段不需要读整个对象。这个特性在缓存用户资料、商品详情、配置项时非常实用。新手经常忽略的一点是 key 的命名规范。Redis 官方推荐用“对象类型:id:字段”这样的模式用冒号分隔。上面例子里的 user:1001 就是这种风格。用好命名规范后续排查和维护会轻松很多。3.3 List队列和栈的基础List 本质是一个双向链表可以从左边推入、右边弹出也可以反过来。常用命令LPUSH queue task_1 RPUSH queue task_2 LPOP queue RPOP queue LRANGE queue 0 -1 LLEN queue如果把数据从左边推入、从右边取走就是先进先出的队列如果从同一端推入和弹出就是栈。实际项目里我常用它做简单任务队列比如异步发送短信、处理上传文件。不过要注意单纯用 LPUSH RPOP 做队列消费者会一直轮询浪费网络资源。更好的做法是用阻塞版本 BLPOP / BRPOP没有数据时客户端会挂起等待数据一出现就立刻弹出。List 还有一个痛点如果用 RPOP 消费后任务处理失败任务就丢了。所以有些实现会用两个队列先放进“处理中”队列成功后删除失败则重新投递。这种模式虽然原始但也算是最早的可靠消息队列雏形了。3.4 Set去重与集合运算Set 是一个无序、不重复的集合内部用哈希实现所以判断一个元素是否存在是非常快的。常用命令SADD users alice bob carol SMEMBERS users SISMEMBER users alice SCARD users SINTER set1 set2 SUNION set1 set2 SDIFF set1 set2我最常用的场景是抽奖去重和用户标签。比如抽奖时每次把中奖用户 ID 放进一个 Set下一次抽奖之前先 SISMEMBER 判断是否已经中过奖。集合运算也很有价值比如两个不同活动都参与过的用户可以用 SINTER 直接算出交集比在数据库里写 JOIN 高效得多。3.5 ZSet排行榜的利器ZSet 在 Set 的基础上给每个元素关联了一个分数Redis 内部会按照分数排序。常用命令ZADD leaderboard 100 alice ZADD leaderboard 200 bob ZINCRBY leaderboard 50 alice ZRANGE leaderboard 0 -1 ZREVRANGE leaderboard 0 -1 ZSCORE leaderboard alice ZRANK leaderboard alice排行榜业务是 ZSet 的最佳拍档。比如打赏榜每次打赏就执行 ZINCRBY把金额加到对应用户分数上然后 ZREVRANGE 取前几名。这个操作在数据库里实现要写复杂的排序 SQL在 Redis 里就是一个 O(logN) 操作。我还做过一个“最近在线用户”场景把用户 ID 作为元素、时间戳作为分数用 ZREVRANGEBYSCORE 按时间倒序捞一批在线用户。ZSet 有个容易被忽略的点分数相同的时候排序是按字典序来的。如果你想实现“先比积分、再比达成时间”可以把分数设计成“积分 时间戳函数”组合出来的数值比如“积分 * 100000 (某个固定值 - 时间戳)”。这是一个很实用的技巧我在实际项目里用过不止一次。4. 过期、持久化与数据安全4.1 过期时间为什么重要Redis 数据存在内存里内存是有限的不能无限往里面塞。所以大部分缓存 key 都要设置过期时间。设置过期时间常见命令EXPIRE key seconds SETEX key seconds value TTL keyTTL 返回 -1 表示没有过期时间-2 表示 key 不存在了。很多坑都出在“忘记设置过期时间”上结果 Redis 内存被无限制增长的数据占满最终服务崩溃。所以我在团队里定的规矩是所有缓存 key 默认必须设置过期时间除非有明确的理由。Redis 的过期删除策略是“惰性删除 定时删除”的结合。简单说key 到时间后不会立刻被物理删除而是在你访问它时发现已经过期才删除同时后台也会定期扫描一部分过期 key 清理。所以有时候你会发现内存不会瞬间下降这是正常现象。4.2 RDB 快照机制Redis 如果只把数据放内存重启后内存里的数据就全没了。持久化就是为了解决这个问题。RDB 是一种快照式持久化它把某个时间点的全部数据生成一个二进制文件 dump.rdb 保存到磁盘。RDB 的触发方式有两种手动执行 SAVE / BGSAVE或者按照配置文件里的 save 规则自动触发。比如配置save 900 1 save 300 10 save 60 10000意思是 900 秒内至少有 1 次写操作就保存一次300 秒内至少有 10 次写操作就保存一次60 秒内至少有 10000 次写操作就保存一次。SAVE 是同步保存会阻塞 RedisBGSAVE 是 fork 一个子进程异步保存不会阻塞主进程。生产环境用的都是 BGSAVE。RDB 的优点是一个文件就是一份完整快照做备份、迁移、复制都很方便。缺点也明显两次快照之间的数据如果发生掉电这部分数据就丢了。所以如果你的业务对数据丢失非常敏感光靠 RDB 不够。4.3 AOF 日志机制AOF 全称是 Append Only File它会记录每一条写命令以追加的方式写入日志文件。重启时 Redis 重新执行一遍 AOF 文件里的命令就能把数据恢复回来。开启方式是在配置文件里设置appendonly yes appendfsync everysec appendfsync 参数是刷盘策略always 表示每次写命令都同步到磁盘最安全但性能最差everysec 表示每秒刷一次盘是性能和安全的折中no 表示交给操作系统决定刷盘时机性能最好但可能丢更多数据。生产环境用 everysec 的占绝大多数。 AOF 文件会越来越大所以 Redis 提供了 AOF 重写机制本质是把当前内存里的数据用最小命令集合重新写一份新的 AOF。手动执行 BGREWRITEAOF 可以触发它也可以配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 让它在膨胀到一定程度后自动重写。现在 Redis 还支持混合持久化AOF 文件头部存一份 RDB 快照后面追加增量命令重启加载速度比纯 AOF 快很多这个功能默认是打开的配置项是 aof-use-rdb-preamble yes。 ### 4.4 持久化方案到底怎么选 我的建议很简单 - 纯缓存场景丢了数据还能回源重建可以不开 AOF只开 RDB 或者两者都不开都行。 - 需要尽量不丢数据的业务场景开启 AOFappendfsync everysec同时保留 RDB 作为兜底。 - 任何时候都不要只依赖 Redis 本身做数据唯一存储。对重要数据数据库才是最终权威数据库 Redis 用缓存旁路模式来配合是最稳妥的。 另外提醒一个恢复细节Redis 重启后如果同时存在 RDB 文件和 AOF 文件会优先加载 AOF因为它的数据通常更新。新手有时候明明开了 RDB重启后觉得数据没恢复其实就是因为 AOF 里加载出来的数据状态和预期不一致。 ## 5. 事务、管道与 Lua 脚本 ### 5.1 Redis 事务的局限性 Redis 事务通过 MULTI、EXEC、DISCARD 来实现。MULTI 之后输入的命令不会立即执行而是进入队列EXEC 后按顺序执行 bash MULTI INCR counter INCR counter EXEC很多教程都说“事务让多命令原子执行”这个说法容易误导。Redis 事务里命令不会被其他命令插队但它不支持回滚。如果某条命令语法本身有错在入队时就能发现整个事务会失败如果命令在运行时出错比如对一个字符串执行 LPUSH前面的命令已经执行了后面的命令还会继续执行。所以 Redis 事务能保证的是“一串命令按顺序执行”并不具备数据库事务的 ACID 完整特性。如果你需要“要么一起成功、要么一起失败”或者需要基于某个条件做判断事务可能并不是最优解。5.2 管道批量请求的加速器管道PIPELINE解决的是网络往返问题。如果客户端要发送 1000 条命令每条都等回应网络耗时是 1000 次 RTT。管道模式允许客户端一次把 1000 条命令发给服务器再一次性读取所有响应。RTT 大幅减少吞吐量提升非常明显。在 Java 的 Jedis 和 RedisTemplate 里都有 pipeline 接口实际项目中批量写缓存、批量查询时都可以考虑。但在入门阶段知道一点就够管道不保证原子性它只是把多条命令打包发送。管道里的命令会被分成多批执行如果中间某条失败了前后的命令依然可能已经执行。5.3 Lua 脚本解决“复合操作”真正需要原子性的时候我会优先考虑 Lua 脚本。Redis 从 2.6 开始支持在服务器端执行 Lua 脚本脚本执行过程中不会被其他命令打断。比如经典的“扣减库存并防止超卖”伪代码如下local stock tonumber(redis.call(GET, KEYS[1])) if stock 0 then redis.call(DECR, KEYS[1]) return 1 end return 0用 EVAL 命令执行这个脚本检查库存和扣减库存就是原子操作并发场景下不会出现超卖。相比用事务自己写状态机Lua 脚本在复杂场景下简洁得多。新手可能觉得 Lua 有学习成本但只需要掌握基本语法和 redis.call 的用法就足以解决 90% 的问题。6. 缓存设计里的三个经典坑6.1 缓存穿透查询不存在的数据缓存穿透指的是请求的数据在数据库里根本不存在所以缓存里永远不会有每次请求都会去数据库查一遍。攻击者如果用大量不存在的 ID 刷接口数据库压力会被瞬间打满。解决办法有几个方向对空结果也做缓存过期时间设置短一些比如 5 分钟。这个方案最简单缺点是缓存了大量无意义 key。使用布隆过滤器请求进来时先用布隆过滤器判断这个 key 是否可能存在如果过滤器说“不存在”直接返回。更严格的参数校验拦截明显非法的 ID。我个人的习惯是先做参数校验再对空结果做短时间缓存等数据量大了再引入布隆过滤器。不要一上来就用复杂方案。6.2 缓存击穿热点 key 瞬间失效缓存击穿和穿透不同它是一个热点 key 过期了这时候大量请求同时打到数据库数据库瞬间被压垮。解决的套路有两种。第一种是互斥锁当缓存失效时不是所有请求都去查数据库而是先获取分布式锁只有拿到锁的线程去查数据库并重建缓存其他线程等缓存重建好之后直接读缓存。第二种是“逻辑过期”缓存里不设置物理过期时间而是把过期时间放在 value 里后台线程发现快到过期时间就异步重建缓存。第二种方案对接口延迟更友好实现起来稍微复杂一点。6.3 缓存雪崩大批 key 同时失效雪崩和击穿的区别是范围。雪崩是大量 key 在同一个时间点一起过期导致大量请求打到数据库。最常见的原因是缓存设置的过期时间完全相同或者 Redis 实例宕机。解决方案也很直接设置过期时间时加一个随机值比如 5 分钟到 7 分钟之间随机打散失效时间。提前把热点数据做多级缓存比如本地缓存 Redis 双层。做好 Redis 的高可用比如主从 哨兵避免实例宕机后请求全部穿透到数据库。6.4 缓存与数据库的一致性这是面试经常被问到的点也是实际工作中最容易出问题的地方。我见过不少团队让“先删缓存再更新数据库”结果在并发下缓存被旧的数据库快照填回去了数据就永远对不上。比较稳妥的做法是“先更新数据库再删除缓存”也就是 Cache Aside 模式。为什么先更新数据库再删缓存更合理因为如果先删缓存数据库还没更新另一个请求就可能把旧值重新写进缓存反过来先更新数据库再删缓存虽然也有一个短暂窗口期但概率和影响都小很多。如果对一致性要求更极致可以用“延迟双删”先删除缓存再更新数据库隔一小段时间再删除一次缓存。但这不是银弹需要结合业务容忍度来判断。大部分内部系统用 Cache Aside 加合理的过期时间就够用了。7. 生产环境必备的配置与安全加固7.1 内存配置与淘汰策略生产环境最重要的配置之一是 maxmemory。如果不设置Redis 会把内存一直吃下去直到系统内存耗尽后果是整个服务被 OOM Killer 杀掉。设置方式maxmemory 4gb内存满之后写入新 key 会触发淘汰策略。策略种类很多常见的有配置项行为noeviction不淘汰写入直接报错allkeys-lru在所有 key 中按最近最少使用淘汰volatile-lru只在设置了过期时间的 key 中按 LRU 淘汰allkeys-lfu在所有 key 中按访问频率淘汰volatile-ttl在设置了过期时间的 key 中优先淘汰剩余时间短的我的选择逻辑是如果 Redis 主要做缓存用 allkeys-lru 或 allkeys-lfu如果 Redis 里还存了一些不能随便丢的数据就选 volatile-lru这样没设置过期时间的 key 不会被淘汰。7.2 安全加固别把 Redis 暴露在公网Redis 默认没有密码监听 6379 端口如果不做任何限制部署在公网服务器上很容易被人扫描到。一旦被写入恶意数据甚至命令执行漏洞利用后果很严重。我见过不止一个团队因为 Redis 没设密码被矿机程序写入CPU 被打满。基础的安全加固至少做这几件事设置 requirepass配置一个足够复杂的密码。设置 protected-mode yes这个配置默认也是开启的但如果你改过 bind 或者暴露端口要确认它是开启状态。bind 只绑定内网地址不要绑定 0.0.0.0。用 rename-command 禁掉危险命令比如 CONFIG、FLUSHALL、KEYS、EVAL或者改成一个很难猜的名字。这是我很推荐的做法因为很多攻击思路都依赖这些命令。如果通过云服务器部署安全组只放行必要的 IP。配置示例bind 192.168.1.100 protected-mode yes requirepass strong-password-here rename-command CONFIG rename-command FLUSHALL 这里我把 CONFIG 和 FLUSHALL 直接禁用了如果需要用再手动打开。很多刚入门的人会觉得这样很麻烦但等你真正线上被攻击一次就会明白这些步骤省不得。7.3 主从复制和高可用思路Redis 的高可用基础是主从复制。从节点同步主节点的数据主节点挂了之后可以升为主节点继续服务。最常用的是 Redis Sentinel它负责监控主节点状态并在主节点故障时自动选出一个从节点升级。如果数据量大、读写并发极高可以上 Redis Cluster数据自动分片到多个节点但配置和管理难度会明显上升。入门阶段不需要亲手搭建一套集群但至少要明白主从复制的基本原理主节点写数据从节点复制数据客户端可以读从节点来分担读写压力。实际项目里用一主两从加三个哨兵是比较常见的配置能扛住大多数场景的节点故障。7.4 备份与恢复RDB 文件本身就是一种备份载体。定时把 dump.rdb 或者 AOF 文件复制到其他服务器或对象存储就是最简单的异地备份方案。恢复时在新机器上启动 Redis把备份文件放到配置的 dir 目录下重启即可。恢复之前先备份线上现有文件避免误操作把新数据覆盖掉。关于备份我要多提醒一句Redis 做主从复制时从节点的数据通常落后主节点一点点所以备份从节点更安全不会影响主节点性能。这个细节很多新手不会注意。8. 常见问题排查实录我把这几年实际踩过的坑整理成一张速查表遇到问题可以直接对着排查。现象可能原因排查与解决客户端连接超时端口未开放、防火墙拦截、Redis 未绑定正确地址telnet 测试端口、检查 bind 和 protected-mode、查看安全组规则Redis 启动后内存一直涨没有设置过期时间、有大 key 堆积用 memory usage 命令定位大 key给缓存 key 加 TTL必要时设置 maxmemory重启后数据丢了没开持久化或持久化配置不当开启 AOF确认 appendfsync 策略检查 dump.rdb 文件是否生成查询突然变慢大 key 操作、KEYS 命令、慢查询用 slowlog get 查慢日志避免 O(N) 命令拆分大 key主从数据不一致网络延迟、主从复制积压缓冲不够监控主从复制偏移量调整 repl-backlog-size内存没满但写入报错可能是 maxmemory-policy 设为 noeviction修改淘汰策略或者扩展内存容量某个 key 删不掉它是大 keyDEL 阻塞 Redis用 UNLINK 异步删除避免阻塞主进程8.1 大 key 是最常见的问题我处理过的 Redis 事故里大 key 占了不小的比例。一个 Hash 里有几百万个字段或者一个 List 有几百万条消息这类数据会让 Redis 在扩容、删除、序列化时都非常慢。如何发现大 key可以使用内置命令redis-cli --bigkeys它会扫描整个实例给出最大的 String、List、Set、Hash、ZSet 的 key。定位到大 key 之后处理方式是拆分或者异步删除。Redis 4.0 之后推荐用 UNLINK 替代 DEL因为 UNLINK 是异步删除不会阻塞主线程。8.2 慢查询的正确排查姿势Redis 的慢日志记录的是执行超过阈值的命令默认阈值 10000 微秒也就是 10 毫秒。可以在 redis-cli 里查看CONFIG SET slowlog-log-slower-than 5000 SLOWLOG GET把自己觉得可疑的命令变成慢查询记录是最直接的排查手段。我真的见过有人因为业务代码里每次请求都执行 KEYS *把 Redis 阻塞得几乎不可用。这种问题的根因还是设计再多的优化都不如把命令改成 Scan 或者直接在数据结构上做索引。8.3 连接数过高排查Redis 的连接数默认上限是 10000但如果你用短连接模式高并发下容易把连接数打满。解决办法客户端使用连接池调整 tcp-keepalive 及时清理失效连接检查是否有代码每次请求都新开连接。判断连接状态可以使用INFO clients重点关注 connected_clients 和 blocked_clients 两个指标。connected_clients 居高不下结合代码排查是最快的路径。9. 入门之后怎么继续深入到这里你已经掌握了 Redis 的核心用法、持久化、缓存设计、安全和常见问题排查。接下来如果还想深入我建议按这个顺序去探索深入学习客户端连接池的使用和参数优化。研究 Redis Cluster 的槽位分配与数据迁移原理。读一读 Redis 的源码或官方文档理解事件循环和内存编码。把分布式锁的续期、可重入、防误删这些细节彻底搞懂。尝试用 Redis 实现一个简单的任务队列体会 Stream 类型。最后分享一个学习建议一定要亲自在 redis-cli 里把命令敲一遍而不是只在代码里调用封装好的 API。命令行能让你直观感受到每个命令的返回值、阻塞行为和异常表现。我在带新人时发现凡是愿意先耐着性子把基础命令过一遍的人后面排查线上问题都明显更从容。Redis 这东西看着简单用好了是性能利器用不好就是事故源头。希望这篇教程能给你打好底子少踩几个我踩过的坑。
