简介这份PPT面向后端开发、运维及缓存技术学习者系统梳理Redis的核心知识体系帮助读者快速建立从原理到配置的完整认知。内容涵盖Redis高性能读写特性、string/hash/set/sorted set/list等数据结构、原子性操作与主从复制机制并客观分析在线扩容困难、宕机影响读写等局限。配置部分详解redis.conf中port、timeout、daemonize、databases等关键参数持久化章节对比RDB快照与AOF日志两种策略的配置项、优缺点及适用场景命令部分则整理key与String等常用操作接口。资源包为1个pptx文件大小约1.59MB以图文幻灯片形式呈现结构清晰、重点突出适合课堂分享或自学参考。目前已有161人学习可作为Redis入门梳理与面试复习的轻量资料。1. Redis 知识地图从单机命令到持久化与主从的完整复习路径很多人复习 Redis 时容易陷入一个误区把命令手册从头背到尾却说不清 RDB 和 AOF 到底该怎么选、主从复制到底解决了什么问题。这份笔记的原料是一份技术分享用的 PPT梳理下来会发现它的结构其实很清晰——先建立整体认知再拆配置与持久化然后按数据类型过一遍核心命令最后落到事务与发布订阅。整条线走完Redis 单机侧的知识骨架就立起来了。这份内容适合两类人一是正在系统学 Redis、需要一张能按图索骥的复习地图的人二是已经用过 Redis、但知识点散落在各处、想集中查漏补缺的人。它不涉及集群分片和哨兵选主的深水区重点放在单机配置、两种持久化策略的取舍、五大数据结构的命令语义以及事务和发布订阅的使用边界。把这些吃透后面再看主从、集群才不会觉得空中楼阁。2. 配置与持久化redis.conf 里真正该盯住的参数2.1 启动配置端口、守护进程与数据库数量Redis 的所有配置都集中在redis.conf文件里改配置不需要动代码改完重启或者用CONFIG SET动态生效。分享里列出的几个核心参数复习时建议按「网络 → 进程 → 日志 → 存储」的顺序过一遍这样不容易漏。配置项含义复习要点port 6379监听端口默认 6379改端口后客户端连接要同步改timeout 0客户端闲置多久后关闭连接0 表示不关闭生产环境不建议长期为 0daemonize yes后台运行设为 yes 后日志不再输出到终端tcp-backlog 511TCP 监听的最大容纳数量高并发场景需要结合系统 somaxconn 调整logfile 日志文件位置空字符串表示输出到标准输出loglevel notice日志级别debug / verbose / notice / warning 四档databases 16默认数据库数量默认使用 0 号库SELECT可切换这里最容易忽略的是databases 16的含义。它不是说 Redis 有 16 个实例而是单个实例内逻辑上分了 16 个库编号 0 到 15。实际项目中通常只用 0 号库因为多库在集群模式下并不支持而且容易让 key 管理变得混乱。复习时记住一句话库是逻辑隔离不是物理隔离别把它当分库分表用。timeout这个参数也值得多说一句。设为 0 意味着客户端连接永远不会因为闲置被断开这在开发环境方便但在生产环境可能积累大量空闲连接占用文件描述符。梳理下来会发现很多「连接数莫名其妙涨上去」的问题根源就在这个参数没设。2.2 RDB 与 AOF两种持久化的取舍逻辑持久化是 Redis 复习里绕不开的重点也是面试和实际排障中问得最多的部分。Redis 提供两种方式RDB 和 AOF。它们不是二选一的关系可以同时开启但理解各自的机制和代价是关键。RDB 俗称快照核心思路是把某一时刻的内存数据整体写入硬盘生成一个紧凑的二进制文件。恢复时直接加载这个文件速度快。它的核心配置如下# redis.conf 中 RDB 相关配置 save 60 1000 # 60 秒内有 1000 次更改则触发 save stop-writes-on-bgsave-error no # 后台 save 出错时是否停止接收写请求 rdbcompression yes # 是否压缩 rdb 文件 dbfilename dump.rdb # 生成的文件名save 60 1000这个配置可以写多条形成不同时间窗口的触发条件。比如同时写save 900 1和save 300 10只要满足任意一条就会触发。stop-writes-on-bgsave-error设为 no 意味着即使上次快照失败Redis 仍然继续接收写请求——这在数据安全性要求高的场景下是危险的因为你可能在不知情的情况下持续写入却没有任何持久化保障。RDB 的优点是文件紧凑、适合备份、恢复快而且保存工作由 fork 出的子进程完成父进程几乎不受影响。但缺点同样明显两次快照之间的数据会丢失而且数据量大时 fork 过程耗时可能导致毫秒级请求出现抖动。AOF 的思路完全不同它记录的是写操作命令追加到文件末尾。恢复时重新执行这些命令。核心配置# redis.conf 中 AOF 相关配置 appendonly yes # 开启 AOF appendfsync everysec # 每秒同步一次兼顾性能与安全 no-appendfsync-on-rewrite no # 重写期间是否暂停 fsync auto-aof-rewrite-percentage 100 # 文件比上次重写后大一倍时触发重写 auto-aof-rewrite-min-size 64mb # 文件至少达到 64MB 才触发重写appendfsync有三个取值这是 AOF 复习的核心考点。always表示每条命令都同步到磁盘最安全但性能最差everysec每秒同步一次最多丢一秒数据是默认推荐值no表示交给操作系统决定何时同步性能最好但丢失数据的窗口不可控。实际项目中绝大多数场景选everysec这是一个安全与性能的平衡点。AOF 的优点是丢失数据少everysec下最多丢一秒。缺点是文件体积通常比 RDB 大恢复时需要逐条重放命令数据量大时恢复时间可能很长。梳理下来会发现两种持久化的选择本质上是在「恢复速度」和「数据完整性」之间做权衡。如果业务能容忍几分钟的数据丢失RDB 够用如果对数据安全性要求高AOF 更合适两者同时开启则兼顾了快速恢复和低丢失。3. 五大数据结构命令语义与典型使用场景3.1 key 通用命令过期、类型与遍历key 级别的命令是所有数据结构共用的复习时先把这一层过清楚后面看具体类型才不会混。核心命令包括EXISTS key检查 key 是否存在存在返回 1否则返回 0DEL key [key ...]删除一个或多个 key不存在的 key 会被忽略EXPIRE key seconds设置生存时间单位秒到期自动删除TTL key返回剩余生存时间单位秒PERSIST key移除生存时间让 key 变成永久RANDOMKEY从当前数据库随机返回一个 key不删除RENAME key newkey改名key 和 newkey 相同或 key 不存在时报错TYPE key返回 key 存储的值的类型KEYS pattern查找符合模式的 keyKEYS命令的匹配模式值得单独记KEYS *匹配所有 keyKEYS h?llo匹配 hello、hallo、hxllo 等KEYS h*llo匹配 hllo 和 heeeeelloKEYS h[ae]llo匹配 hello 和 hallo 但不匹配 hillo。这里最容易翻车的地方是KEYS *在生产环境是禁用级别的命令因为它会遍历所有 key数据量大时直接阻塞 Redis。复习时记住线上查 key 用SCAN系列命令代替虽然分享里没展开但这是必须知道的补充。EXPIRE和TTL的组合是缓存场景的基础。设置缓存时通常用SETEX key seconds value一步到位而不是先SET再EXPIRE因为两步操作之间如果客户端断开key 可能变成永久的。这是一个典型的易错点。3.2 String、Hash 与 List最常用的三种结构String 是 Redis 最基础的数据类型命令也最多。核心操作包括SET、GET、MSET、MGET、SETEX、APPEND、STRLEN、GETRANGE、GETSET以及原子增减的INCR、DECR、INCRBY、DECRBY。# String 典型用法计数器与缓存 SET page:view:1001 0 # 初始化计数器 INCR page:view:1001 # 原子加一返回 1 INCRBY page:view:1001 10 # 原子加十返回 11 SETEX session:abc 3600 data # 设置值并同时设置 3600 秒过期 GETSET page:view:1001 0 # 返回旧值并设为 0适合重置计数器INCR和DECR的原子性是 String 在计数场景的核心价值。如果 key 不存在会先初始化为 0 再执行操作。GETSET的语义是「设新值返回旧值」这个命令在重置计数器的场景很好用但要注意它和SET一样会覆盖 key 的原有类型。Hash 适合存储对象比如用户信息。核心命令有HSET、HSETNX、HGET、HGETALL、HMGET、HMSET、HDEL、HEXISTS、HLEN、HKEYS、HVALS、HINCRBY。HSETNX只在字段不存在时设置适合做去重初始化。HINCRBY对指定字段做原子增减适合对象内的计数场景。List 是双向链表支持从两端插入和弹出。LPUSH从表头插入RPUSH从表尾插入LPOP和RPOP从两端弹出LRANGE按区间返回元素LINDEX按下标取元素LSET按下标设值LINSERT在指定元素前后插入LLEN返回长度LTRIM保留指定区间LREM按 count 移除元素。LREM的 count 参数是复习时的易混点count 大于 0 从表头向表尾搜索移除数量为 countcount 小于 0 从表尾向表头搜索移除数量为绝对值count 等于 0 移除所有匹配值。BLPOP和BRPOP是阻塞版本列表为空时连接会被阻塞直到超时或有元素可弹出这是实现简单队列的关键命令。3.3 Set 与有序集合集合运算与排序能力Set 是无序不重复集合核心命令包括SADD、SCARD、SMEMBERS、SPOP、SISMEMBER、SREM以及集合运算的SDIFF、SINTER、SUNION和对应的STORE版本。SPOP随机移除并返回一个元素适合抽奖场景。SISMEMBER判断成员是否存在时间复杂度 O(1)适合做去重判断。集合运算的STORE版本会把结果存到目标 key比如SINTERSTORE destination key1 key2把交集存到 destination。这在需要多次使用交集结果的场景下很有用避免重复计算。SSCAN用于迭代大集合避免SMEMBERS一次性返回所有元素造成阻塞。分享里没有展开有序集合sorted set但作为五大数据结构之一复习时需要知道它的核心能力每个元素关联一个分数按分数排序支持范围查询和排名查询。典型场景是排行榜。命令风格和 Set 类似但多了ZADD、ZRANGE、ZSCORE、ZRANK等带分数的操作。4. 事务与发布订阅原子性边界与消息模型4.1 事务MULTI、EXEC 与 WATCH 的配合Redis 的事务和关系型数据库的事务不是一回事。它把多条命令放入队列最后由EXEC一次性顺序执行中间不会插入其他客户端的命令。核心命令MULTI标记事务开始后续命令入队EXEC执行队列中的所有命令DISCARD取消事务放弃队列中的所有命令WATCH key [key ...]监视 key如果事务执行前被其他命令改动事务被打断UNWATCH取消所有监视# 事务典型流程乐观锁式的检查与设置 WATCH balance:1001 # 监视余额 key MULTI # 开始事务 DECRBY balance:1001 100 # 扣款 100 INCRBY balance:1002 100 # 入账 100 EXEC # 执行如果 balance:1001 被改过则返回 nil这里的关键点是Redis 事务不支持回滚。如果队列中某条命令执行失败比如对 String 执行 List 命令其他命令仍然会执行Redis 不会撤销已执行的命令。所以它保证的是「命令打包执行不被穿插」而不是「要么全成功要么全失败」。WATCH提供的是乐观锁机制在EXEC时检查被监视的 key 是否被改动被改动则整个事务不执行。复习时要把这个边界记清楚避免把它当关系型数据库事务用。4.2 发布订阅频道模型与使用限制发布订阅是 Redis 提供的消息通信能力核心命令有SUBSCRIBE、PUBLISH、UNSUBSCRIBE、PUBSUB CHANNELS、PUBSUB NUMSUB。SUBSCRIBE订阅一个或多个频道PUBLISH向指定频道发送消息PUBSUB CHANNELS列出当前活跃频道PUBSUB NUMSUB返回给定频道的订阅者数量。# 终端 A订阅频道 SUBSCRIBE news:tech # 终端 B发布消息 PUBLISH news:tech Redis 持久化对比 # 终端 B查看活跃频道和订阅数 PUBSUB CHANNELS news:* PUBSUB NUMSUB news:tech发布订阅的模型是「即发即弃」消息不持久化订阅者不在线就收不到没有确认机制也没有重试。它适合做实时通知、配置推送这类允许丢失的场景不适合做可靠消息队列。梳理下来会发现很多团队一开始用发布订阅做业务解耦后来发现消息丢失问题严重最终还是换成了专门的消息中间件。复习时记住这个边界发布订阅是轻量通知不是可靠消息系统。5. 易漏点与易错点复习时最容易翻车的五个地方5.1 易漏点一RDB 和 AOF 同时开启时的恢复优先级为什么漏很多人以为两种持久化是平等的恢复时随便选一个。实际上 Redis 启动时如果同时检测到 RDB 和 AOF 文件会优先加载 AOF因为 AOF 通常包含更完整的数据。怎么补复习时明确记住「AOF 优先」这个规则。如果 AOF 文件损坏Redis 会拒绝启动这时候需要用redis-check-aof工具修复或者临时把appendonly设为 no 先启动再处理。生产环境要定期检查 AOF 文件状态。5.2 易漏点二KEYS 命令的阻塞风险为什么漏KEYS *在测试环境秒回容易让人以为它没有代价。实际上它的时间复杂度是 O(N)N 是 key 的总数数据量大时直接阻塞主线程。怎么补线上环境用SCAN cursor [MATCH pattern] [COUNT count]代替。SCAN是渐进式遍历每次返回一小批不会长时间阻塞。复习时把SCAN、SSCAN、HSCAN、ZSCAN四个命令一起记它们分别对应不同的数据结构。5.3 易错点三EXPIRE 与 SETEX 的顺序问题为什么错先SET再EXPIRE是两步操作如果中间客户端断开或进程崩溃key 会变成永久的缓存永远不过期。怎么补需要同时设置值和过期时间时用SETEX key seconds value或SET key value EX seconds一步完成。这是原子操作不存在中间状态。复习时把「设值 过期」当成一个整体动作来记。5.4 易错点四事务不支持回滚为什么错习惯了关系型数据库的人会默认事务失败后自动回滚但 Redis 事务中某条命令失败不影响其他命令执行。怎么补把 Redis 事务理解为「命令打包顺序执行」而不是「原子性事务」。如果需要真正的原子性考虑用 Lua 脚本Lua 脚本在 Redis 中是原子执行的。WATCH提供的是乐观锁不是回滚机制。5.5 易错点五主从复制下的读写分离与数据一致性为什么错主从复制是异步的主节点写入后立即返回从节点可能还没同步到最新数据。如果客户端从从节点读可能读到旧数据。怎么补对一致性要求高的读操作走主节点或者用WAIT命令等待指定数量的从节点确认。复习时记住主从复制解决的是读扩展和容灾不是强一致性。主机或从机宕机都会导致部分读写请求失败这是分享里明确提到的缺点。6. 复习清单从命令到配置的查漏补缺路径复习 Redis 单机侧的知识我自己的习惯是按「配置 → 持久化 → 命令 → 事务 → 边界」五步走一遍每一步都有具体的检查动作。第一步打开redis.conf把port、timeout、daemonize、databases、logfile、loglevel六个参数过一遍确认自己能说出每个参数改动的后果。特别是timeout 0和databases 16这两个在实际项目中经常被忽略。第二步持久化部分做一张对比表把 RDB 和 AOF 的触发条件、文件格式、恢复速度、数据丢失窗口、适用场景各写一行。然后问自己如果业务要求最多丢一秒数据选哪个如果要求恢复速度最快选哪个两个都开的时候恢复优先级是什么这三个问题能答清楚持久化就算过关。第三步五大数据结构各挑三个最常用的命令用redis-cli实际敲一遍。String 重点练SETEX、INCR、GETSETHash 重点练HSETNX、HINCRBY、HGETALLList 重点练LPUSH、LRANGE、BLPOPSet 重点练SADD、SISMEMBER、SINTERSTORE有序集合重点练ZADD、ZRANGE、ZSCORE。敲的时候注意返回值很多命令的返回值语义和直觉不一样。第四步事务部分写一个WATCHMULTIEXEC的完整流程然后故意在EXEC前用另一个客户端改动被监视的 key观察EXEC返回 nil 的行为。这个实验做一次比看十遍文档都管用。第五步把易错点清单过一遍AOF 优先加载、KEYS 阻塞、SETEX 原子性、事务不回滚、主从异步。每一条都问自己「如果线上遇到我怎么排查」。复习模块检查动作过关标准配置过一遍 redis.conf 核心参数能说出每个参数改动的后果持久化做 RDB/AOF 对比表能根据业务场景选策略命令五大数据结构各练三个命令能说出返回值语义事务做一次 WATCH 打断实验理解乐观锁边界易错点过一遍五个易错清单能说出排查思路这份笔记的原料是一份分享用的 PPT内容覆盖了单机 Redis 的主要知识点但没有展开集群和哨兵。复习时先把这一层吃透后面再看分布式部分会顺很多。我自己的习惯是每次复习完都强制走一遍上面的五步尤其是持久化对比表和事务实验这两块最容易在面试和排障时被问到。希望这份梳理能帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/23 9:24:11 · 阅读 1.2k Redis单机复习全攻略：配置、持久化、命令与事务边界
简介这份PPT面向后端开发、运维及缓存技术学习者系统梳理Redis的核心知识体系帮助读者快速建立从原理到配置的完整认知。内容涵盖Redis高性能读写特性、string/hash/set/sorted set/list等数据结构、原子性操作与主从复制机制并客观分析在线扩容困难、宕机影响读写等局限。配置部分详解redis.conf中port、timeout、daemonize、databases等关键参数持久化章节对比RDB快照与AOF日志两种策略的配置项、优缺点及适用场景命令部分则整理key与String等常用操作接口。资源包为1个pptx文件大小约1.59MB以图文幻灯片形式呈现结构清晰、重点突出适合课堂分享或自学参考。目前已有161人学习可作为Redis入门梳理与面试复习的轻量资料。1. Redis 知识地图从单机命令到持久化与主从的完整复习路径很多人复习 Redis 时容易陷入一个误区把命令手册从头背到尾却说不清 RDB 和 AOF 到底该怎么选、主从复制到底解决了什么问题。这份笔记的原料是一份技术分享用的 PPT梳理下来会发现它的结构其实很清晰——先建立整体认知再拆配置与持久化然后按数据类型过一遍核心命令最后落到事务与发布订阅。整条线走完Redis 单机侧的知识骨架就立起来了。这份内容适合两类人一是正在系统学 Redis、需要一张能按图索骥的复习地图的人二是已经用过 Redis、但知识点散落在各处、想集中查漏补缺的人。它不涉及集群分片和哨兵选主的深水区重点放在单机配置、两种持久化策略的取舍、五大数据结构的命令语义以及事务和发布订阅的使用边界。把这些吃透后面再看主从、集群才不会觉得空中楼阁。2. 配置与持久化redis.conf 里真正该盯住的参数2.1 启动配置端口、守护进程与数据库数量Redis 的所有配置都集中在redis.conf文件里改配置不需要动代码改完重启或者用CONFIG SET动态生效。分享里列出的几个核心参数复习时建议按「网络 → 进程 → 日志 → 存储」的顺序过一遍这样不容易漏。配置项含义复习要点port 6379监听端口默认 6379改端口后客户端连接要同步改timeout 0客户端闲置多久后关闭连接0 表示不关闭生产环境不建议长期为 0daemonize yes后台运行设为 yes 后日志不再输出到终端tcp-backlog 511TCP 监听的最大容纳数量高并发场景需要结合系统 somaxconn 调整logfile 日志文件位置空字符串表示输出到标准输出loglevel notice日志级别debug / verbose / notice / warning 四档databases 16默认数据库数量默认使用 0 号库SELECT可切换这里最容易忽略的是databases 16的含义。它不是说 Redis 有 16 个实例而是单个实例内逻辑上分了 16 个库编号 0 到 15。实际项目中通常只用 0 号库因为多库在集群模式下并不支持而且容易让 key 管理变得混乱。复习时记住一句话库是逻辑隔离不是物理隔离别把它当分库分表用。timeout这个参数也值得多说一句。设为 0 意味着客户端连接永远不会因为闲置被断开这在开发环境方便但在生产环境可能积累大量空闲连接占用文件描述符。梳理下来会发现很多「连接数莫名其妙涨上去」的问题根源就在这个参数没设。2.2 RDB 与 AOF两种持久化的取舍逻辑持久化是 Redis 复习里绕不开的重点也是面试和实际排障中问得最多的部分。Redis 提供两种方式RDB 和 AOF。它们不是二选一的关系可以同时开启但理解各自的机制和代价是关键。RDB 俗称快照核心思路是把某一时刻的内存数据整体写入硬盘生成一个紧凑的二进制文件。恢复时直接加载这个文件速度快。它的核心配置如下# redis.conf 中 RDB 相关配置 save 60 1000 # 60 秒内有 1000 次更改则触发 save stop-writes-on-bgsave-error no # 后台 save 出错时是否停止接收写请求 rdbcompression yes # 是否压缩 rdb 文件 dbfilename dump.rdb # 生成的文件名save 60 1000这个配置可以写多条形成不同时间窗口的触发条件。比如同时写save 900 1和save 300 10只要满足任意一条就会触发。stop-writes-on-bgsave-error设为 no 意味着即使上次快照失败Redis 仍然继续接收写请求——这在数据安全性要求高的场景下是危险的因为你可能在不知情的情况下持续写入却没有任何持久化保障。RDB 的优点是文件紧凑、适合备份、恢复快而且保存工作由 fork 出的子进程完成父进程几乎不受影响。但缺点同样明显两次快照之间的数据会丢失而且数据量大时 fork 过程耗时可能导致毫秒级请求出现抖动。AOF 的思路完全不同它记录的是写操作命令追加到文件末尾。恢复时重新执行这些命令。核心配置# redis.conf 中 AOF 相关配置 appendonly yes # 开启 AOF appendfsync everysec # 每秒同步一次兼顾性能与安全 no-appendfsync-on-rewrite no # 重写期间是否暂停 fsync auto-aof-rewrite-percentage 100 # 文件比上次重写后大一倍时触发重写 auto-aof-rewrite-min-size 64mb # 文件至少达到 64MB 才触发重写appendfsync有三个取值这是 AOF 复习的核心考点。always表示每条命令都同步到磁盘最安全但性能最差everysec每秒同步一次最多丢一秒数据是默认推荐值no表示交给操作系统决定何时同步性能最好但丢失数据的窗口不可控。实际项目中绝大多数场景选everysec这是一个安全与性能的平衡点。AOF 的优点是丢失数据少everysec下最多丢一秒。缺点是文件体积通常比 RDB 大恢复时需要逐条重放命令数据量大时恢复时间可能很长。梳理下来会发现两种持久化的选择本质上是在「恢复速度」和「数据完整性」之间做权衡。如果业务能容忍几分钟的数据丢失RDB 够用如果对数据安全性要求高AOF 更合适两者同时开启则兼顾了快速恢复和低丢失。3. 五大数据结构命令语义与典型使用场景3.1 key 通用命令过期、类型与遍历key 级别的命令是所有数据结构共用的复习时先把这一层过清楚后面看具体类型才不会混。核心命令包括EXISTS key检查 key 是否存在存在返回 1否则返回 0DEL key [key ...]删除一个或多个 key不存在的 key 会被忽略EXPIRE key seconds设置生存时间单位秒到期自动删除TTL key返回剩余生存时间单位秒PERSIST key移除生存时间让 key 变成永久RANDOMKEY从当前数据库随机返回一个 key不删除RENAME key newkey改名key 和 newkey 相同或 key 不存在时报错TYPE key返回 key 存储的值的类型KEYS pattern查找符合模式的 keyKEYS命令的匹配模式值得单独记KEYS *匹配所有 keyKEYS h?llo匹配 hello、hallo、hxllo 等KEYS h*llo匹配 hllo 和 heeeeelloKEYS h[ae]llo匹配 hello 和 hallo 但不匹配 hillo。这里最容易翻车的地方是KEYS *在生产环境是禁用级别的命令因为它会遍历所有 key数据量大时直接阻塞 Redis。复习时记住线上查 key 用SCAN系列命令代替虽然分享里没展开但这是必须知道的补充。EXPIRE和TTL的组合是缓存场景的基础。设置缓存时通常用SETEX key seconds value一步到位而不是先SET再EXPIRE因为两步操作之间如果客户端断开key 可能变成永久的。这是一个典型的易错点。3.2 String、Hash 与 List最常用的三种结构String 是 Redis 最基础的数据类型命令也最多。核心操作包括SET、GET、MSET、MGET、SETEX、APPEND、STRLEN、GETRANGE、GETSET以及原子增减的INCR、DECR、INCRBY、DECRBY。# String 典型用法计数器与缓存 SET page:view:1001 0 # 初始化计数器 INCR page:view:1001 # 原子加一返回 1 INCRBY page:view:1001 10 # 原子加十返回 11 SETEX session:abc 3600 data # 设置值并同时设置 3600 秒过期 GETSET page:view:1001 0 # 返回旧值并设为 0适合重置计数器INCR和DECR的原子性是 String 在计数场景的核心价值。如果 key 不存在会先初始化为 0 再执行操作。GETSET的语义是「设新值返回旧值」这个命令在重置计数器的场景很好用但要注意它和SET一样会覆盖 key 的原有类型。Hash 适合存储对象比如用户信息。核心命令有HSET、HSETNX、HGET、HGETALL、HMGET、HMSET、HDEL、HEXISTS、HLEN、HKEYS、HVALS、HINCRBY。HSETNX只在字段不存在时设置适合做去重初始化。HINCRBY对指定字段做原子增减适合对象内的计数场景。List 是双向链表支持从两端插入和弹出。LPUSH从表头插入RPUSH从表尾插入LPOP和RPOP从两端弹出LRANGE按区间返回元素LINDEX按下标取元素LSET按下标设值LINSERT在指定元素前后插入LLEN返回长度LTRIM保留指定区间LREM按 count 移除元素。LREM的 count 参数是复习时的易混点count 大于 0 从表头向表尾搜索移除数量为 countcount 小于 0 从表尾向表头搜索移除数量为绝对值count 等于 0 移除所有匹配值。BLPOP和BRPOP是阻塞版本列表为空时连接会被阻塞直到超时或有元素可弹出这是实现简单队列的关键命令。3.3 Set 与有序集合集合运算与排序能力Set 是无序不重复集合核心命令包括SADD、SCARD、SMEMBERS、SPOP、SISMEMBER、SREM以及集合运算的SDIFF、SINTER、SUNION和对应的STORE版本。SPOP随机移除并返回一个元素适合抽奖场景。SISMEMBER判断成员是否存在时间复杂度 O(1)适合做去重判断。集合运算的STORE版本会把结果存到目标 key比如SINTERSTORE destination key1 key2把交集存到 destination。这在需要多次使用交集结果的场景下很有用避免重复计算。SSCAN用于迭代大集合避免SMEMBERS一次性返回所有元素造成阻塞。分享里没有展开有序集合sorted set但作为五大数据结构之一复习时需要知道它的核心能力每个元素关联一个分数按分数排序支持范围查询和排名查询。典型场景是排行榜。命令风格和 Set 类似但多了ZADD、ZRANGE、ZSCORE、ZRANK等带分数的操作。4. 事务与发布订阅原子性边界与消息模型4.1 事务MULTI、EXEC 与 WATCH 的配合Redis 的事务和关系型数据库的事务不是一回事。它把多条命令放入队列最后由EXEC一次性顺序执行中间不会插入其他客户端的命令。核心命令MULTI标记事务开始后续命令入队EXEC执行队列中的所有命令DISCARD取消事务放弃队列中的所有命令WATCH key [key ...]监视 key如果事务执行前被其他命令改动事务被打断UNWATCH取消所有监视# 事务典型流程乐观锁式的检查与设置 WATCH balance:1001 # 监视余额 key MULTI # 开始事务 DECRBY balance:1001 100 # 扣款 100 INCRBY balance:1002 100 # 入账 100 EXEC # 执行如果 balance:1001 被改过则返回 nil这里的关键点是Redis 事务不支持回滚。如果队列中某条命令执行失败比如对 String 执行 List 命令其他命令仍然会执行Redis 不会撤销已执行的命令。所以它保证的是「命令打包执行不被穿插」而不是「要么全成功要么全失败」。WATCH提供的是乐观锁机制在EXEC时检查被监视的 key 是否被改动被改动则整个事务不执行。复习时要把这个边界记清楚避免把它当关系型数据库事务用。4.2 发布订阅频道模型与使用限制发布订阅是 Redis 提供的消息通信能力核心命令有SUBSCRIBE、PUBLISH、UNSUBSCRIBE、PUBSUB CHANNELS、PUBSUB NUMSUB。SUBSCRIBE订阅一个或多个频道PUBLISH向指定频道发送消息PUBSUB CHANNELS列出当前活跃频道PUBSUB NUMSUB返回给定频道的订阅者数量。# 终端 A订阅频道 SUBSCRIBE news:tech # 终端 B发布消息 PUBLISH news:tech Redis 持久化对比 # 终端 B查看活跃频道和订阅数 PUBSUB CHANNELS news:* PUBSUB NUMSUB news:tech发布订阅的模型是「即发即弃」消息不持久化订阅者不在线就收不到没有确认机制也没有重试。它适合做实时通知、配置推送这类允许丢失的场景不适合做可靠消息队列。梳理下来会发现很多团队一开始用发布订阅做业务解耦后来发现消息丢失问题严重最终还是换成了专门的消息中间件。复习时记住这个边界发布订阅是轻量通知不是可靠消息系统。5. 易漏点与易错点复习时最容易翻车的五个地方5.1 易漏点一RDB 和 AOF 同时开启时的恢复优先级为什么漏很多人以为两种持久化是平等的恢复时随便选一个。实际上 Redis 启动时如果同时检测到 RDB 和 AOF 文件会优先加载 AOF因为 AOF 通常包含更完整的数据。怎么补复习时明确记住「AOF 优先」这个规则。如果 AOF 文件损坏Redis 会拒绝启动这时候需要用redis-check-aof工具修复或者临时把appendonly设为 no 先启动再处理。生产环境要定期检查 AOF 文件状态。5.2 易漏点二KEYS 命令的阻塞风险为什么漏KEYS *在测试环境秒回容易让人以为它没有代价。实际上它的时间复杂度是 O(N)N 是 key 的总数数据量大时直接阻塞主线程。怎么补线上环境用SCAN cursor [MATCH pattern] [COUNT count]代替。SCAN是渐进式遍历每次返回一小批不会长时间阻塞。复习时把SCAN、SSCAN、HSCAN、ZSCAN四个命令一起记它们分别对应不同的数据结构。5.3 易错点三EXPIRE 与 SETEX 的顺序问题为什么错先SET再EXPIRE是两步操作如果中间客户端断开或进程崩溃key 会变成永久的缓存永远不过期。怎么补需要同时设置值和过期时间时用SETEX key seconds value或SET key value EX seconds一步完成。这是原子操作不存在中间状态。复习时把「设值 过期」当成一个整体动作来记。5.4 易错点四事务不支持回滚为什么错习惯了关系型数据库的人会默认事务失败后自动回滚但 Redis 事务中某条命令失败不影响其他命令执行。怎么补把 Redis 事务理解为「命令打包顺序执行」而不是「原子性事务」。如果需要真正的原子性考虑用 Lua 脚本Lua 脚本在 Redis 中是原子执行的。WATCH提供的是乐观锁不是回滚机制。5.5 易错点五主从复制下的读写分离与数据一致性为什么错主从复制是异步的主节点写入后立即返回从节点可能还没同步到最新数据。如果客户端从从节点读可能读到旧数据。怎么补对一致性要求高的读操作走主节点或者用WAIT命令等待指定数量的从节点确认。复习时记住主从复制解决的是读扩展和容灾不是强一致性。主机或从机宕机都会导致部分读写请求失败这是分享里明确提到的缺点。6. 复习清单从命令到配置的查漏补缺路径复习 Redis 单机侧的知识我自己的习惯是按「配置 → 持久化 → 命令 → 事务 → 边界」五步走一遍每一步都有具体的检查动作。第一步打开redis.conf把port、timeout、daemonize、databases、logfile、loglevel六个参数过一遍确认自己能说出每个参数改动的后果。特别是timeout 0和databases 16这两个在实际项目中经常被忽略。第二步持久化部分做一张对比表把 RDB 和 AOF 的触发条件、文件格式、恢复速度、数据丢失窗口、适用场景各写一行。然后问自己如果业务要求最多丢一秒数据选哪个如果要求恢复速度最快选哪个两个都开的时候恢复优先级是什么这三个问题能答清楚持久化就算过关。第三步五大数据结构各挑三个最常用的命令用redis-cli实际敲一遍。String 重点练SETEX、INCR、GETSETHash 重点练HSETNX、HINCRBY、HGETALLList 重点练LPUSH、LRANGE、BLPOPSet 重点练SADD、SISMEMBER、SINTERSTORE有序集合重点练ZADD、ZRANGE、ZSCORE。敲的时候注意返回值很多命令的返回值语义和直觉不一样。第四步事务部分写一个WATCHMULTIEXEC的完整流程然后故意在EXEC前用另一个客户端改动被监视的 key观察EXEC返回 nil 的行为。这个实验做一次比看十遍文档都管用。第五步把易错点清单过一遍AOF 优先加载、KEYS 阻塞、SETEX 原子性、事务不回滚、主从异步。每一条都问自己「如果线上遇到我怎么排查」。复习模块检查动作过关标准配置过一遍 redis.conf 核心参数能说出每个参数改动的后果持久化做 RDB/AOF 对比表能根据业务场景选策略命令五大数据结构各练三个命令能说出返回值语义事务做一次 WATCH 打断实验理解乐观锁边界易错点过一遍五个易错清单能说出排查思路这份笔记的原料是一份分享用的 PPT内容覆盖了单机 Redis 的主要知识点但没有展开集群和哨兵。复习时先把这一层吃透后面再看分布式部分会顺很多。我自己的习惯是每次复习完都强制走一遍上面的五步尤其是持久化对比表和事务实验这两块最容易在面试和排障时被问到。希望这份梳理能帮到你。本文还有配套的精品资源点击获取