Redis我陆陆续续用了好几年说实话一开始就是当成一个高级一点的缓存工具来用set、get、expire三板斧走天下。直到后来某次生产环境出了事故内存被大Key撑爆、持久化文件恢复慢、集群脑裂数据丢失我才意识到Redis远不是“一个缓存”这么简单。痛定思痛我把整套体系从底层数据结构到持久化、事务、集群、生产治理完整过了一遍又把踩过的坑整理成这份学习笔记。这篇文章适合三类人刚接触Redis想系统入门的同学、已经用了一段时间但知识比较零散的开发者、还有准备技术面试把Redis当作重点考察项目的朋友。我会尽量把每一个机制背后的“为什么”讲清楚而不是只列命令这样你学完才能真正理解它而不是背完就忘。1. Redis到底是什么为什么值得花时间学1.1 从一个最常见的缓存场景说起先退一步想一个最基础的问题为什么要有Redis最直观的场景是数据库扛不住高并发。传统的关系型数据库数据存在磁盘上每次查询都要经历磁盘寻道和读取这个物理过程再快也有上限通常在毫秒到十毫秒级别。而Redis把数据存放在内存里读写速度可以做到微秒到亚毫秒级别单实例QPS轻松跑到10万以上这中间的性能差距是几个数量级。但这不足以解释Redis为什么这么流行。Memcached同样也是内存缓存性能也不差它才是真正意义上的“纯缓存”。Redis和它最本质的区别在于Redis不只是能存key-value字符串它本身就是一套数据结构服务器。你往里面放的不是死板的键值对而是List、Hash、Set、ZSet这样的结构服务端直接帮你完成列表操作、集合运算、排序等逻辑。这意味着很多原本要写一堆Java代码、SQL才能实现的业务逻辑可以下沉到Redis这一层用几条命令就完成。我刚上手的时候也有个误区觉得“把所有东西都塞进缓存过期时间设置长一点就行了”结果出现各种缓存一致性问题。实际上Redis最适合做的不是“给数据库当挡箭牌”而是把那些天然适合在内存里算好的热点数据、中间结果、共享状态放到它里面。理清这个定位后面学起来会顺畅很多。1.2 只有缓存吗盘点Redis的核心应用场景把Redis的应用场景完整盘一遍你就能理解为什么它在一线技术栈里几乎是标配。数据缓存最经典的使用方式。把热点数据、登录会话、配置信息缓存到Redis降低数据库压力提升接口响应速度。排行榜ZSet天然就是为排行榜而生的。每个用户的分数作为score用户ID作为memberZREVRANGE一下就能拿到Top N。游戏电竞、电商热销榜、内容热度榜都是这么做的。计数器与限流String的INCR/DECR原子自增可以用于点赞数、播放量、库存扣减。配合EXPIRE还能做滑动窗口限流比如每分钟最多允许多少请求。分布式锁多台服务器竞争某个共享资源时必须有一个跨进程的锁机制。Redis的SET NX EX可以实现一个简单可靠的分布式锁这是单体应用里synchronized做不到的。消息队列List的LPUSH/BRPOP可以实现可靠的消息队列Stream则提供了消费者组等更完善的消息模型在轻量级场景下可以替代专业的MQ中间件。Session共享多实例部署的Web应用把Session从进程内存搬到Redis里用户请求打到任何一台机器都能读到会话状态。布隆过滤器与去重通过Redis的bitmap或者专门的模块实现布隆过滤器可以高效判断某个数据是否在集合中常用于防止缓存穿透、推荐系统去重。发布订阅一些轻量级的实时通知场景比如聊天消息提醒、配置变更广播可以用PUBLISH/SUBSCRIBE实现。这些场景有一个共同特点要么是对性能要求极高、要么是需要跨进程共享视图、要么是需要服务端原生地完成某种数据结构操作。换句话说Redis补的不是某一个具体功能的短板而是整个系统的状态共享和快速计算能力。这也是它长盛不衰的根本原因。1.3 Redis常用存储选型对比很多人会有疑问既然有MySQL、MongoDB、Memcached这些存储组件为什么偏偏是Redis我把它们放在一张表里比较你会看得更清楚。组件数据模型存储位置读写性能持久化典型用途MySQL结构化表磁盘较低完整事务核心业务数据存储MongoDB文档型磁盘中完整灵活可变结构的数据Memcached纯Key-Value内存高无简单内容缓存Redis多种数据结构内存很高支持RDB/AOF缓存、队列、排行榜、锁MySQL的核心价值是事务性和关系约束它负责“真相”。Memcached的职责只是“加速”过期就丢从不纠结。而Redis是介于两者之间的它有数据结构操作能力、支持持久化但在强一致性和复杂查询上并不擅长。在实际系统里Redis不是替代谁而是配合MySQL、消息队列等一起把事情做好。理解这一点你在做技术选型的时候才不会走偏。2. 从零搭建一个可用的Redis环境2.1 安装方式选择与基础配置学习阶段安装Redis主要有两种方式编译安装和Docker启动。编译安装能让你看到完整的构建过程也能更直观地理解版本和目录结构Docker则胜在干净利落几秒就能拉起一个环境。我个人建议你两种都试一下。编译安装的步骤大致是这样# 下载并解压源码 wget https://download.redis.io/releases/redis-7.0.15.tar.gz tar -xzf redis-7.0.15.tar.gz cd redis-7.0.15 # 编译安装 make make install PREFIX/usr/local/redis编译完成后redis-server、redis-cli这些可执行文件就会出现在/usr/local/redis/bin目录下。用Docker的话更简单docker run -d --name redis-lab -p 6379:6379 redis:7.0无论哪种方式验证Redis是否正常工作只需要执行redis-cli ping # 返回 PONG 就说明没问题安装完第一件要做的事是修改配置文件。默认配置只允许本机访问也不能安全地用于生产环境。REDIS的配置主要集中在redis.conf里关键的几项包括bind 127.0.0.1默认只监听本机回环地址如果需要被其他机器访问要改成具体的网卡地址或0.0.0.0但要注意这同时也意味着暴露端口必须搭配requirepass使用。protected-mode yes保护模式在没有密码且监听所有网卡时它会拒绝外部访问。如果你设了密码它才会允许非本机连接。port 6379默认端口没有特别理由不建议改改了会带来运维识别成本。requirepass设置访问密码。我用过很多部署脚本第一件事就是配这个。daemonize yes是否后台运行。学习的时候可以手动启动看日志生产环境建议用systemd管理。maxmemoryRedis最大可用内存。不设置的话它可能吃掉整台机器的物理内存直到操作系统开始swap最后被OOM Killer干掉。这个一定在生产环境配好。appendonly yes是否开启AOF持久化。默认是关的生产建议开启。我第一次自己搭环境的时候就是把这些配置一股脑都写上去了结果客户端连接时报DENIED Redis is running in protected mode排查了半天才发现是protected-mode和bind、requirepass配合的问题。这算是新手最容易踩的一个坑。2.2 五大数据结构快速上手Redis的核心是数据结构这五个最基础的你必须要掌握。我在下面把每个结构的核心命令、底层形态、典型场景都列出来一个个过。String字符串最基本的类型可以存字符串、整数、二进制数据。常用命令包括SET、GET、INCR、DECR、SETNX、SETEX。典型场景是缓存、计数器。需要注意Redis中的value大小上限是512MB虽然看着很大但实际生产极少有人真的往里塞这么大的数据太大了会带来网络传输和内存碎片问题。INCR系列操作是原子性的多线程并发下也不会超卖这是它做计数器的底气。Hash哈希相当于一个对象内部的字段集合。常用命令有HSET、HGET、HGETALL、HDEL、HINCRBY。典型场景是存对象比如用户信息、商品详情。好处是你可以只读取对象的某一个字段而不用像序列化字符串那样把整个对象传来传去。尤其适合“部分字段经常更新、其他字段保持不变”的场景。List列表双向链表结构。常用命令LPUSH、RPUSH、LRANGE、LPOP、RPOP、BRPOP、BLPOP。典型场景有最新消息列表、简单消息队列。BRPOP是阻塞弹出可以配合多消费者实现一个任务分发队列。这里有个看起来奇怪但很实用的技巧用LPUSH去写、LRANGE取前几条就实现了时间线功能。Set集合无序、元素唯一。常用命令SADD、SREM、SMEMBERS、SISMEMBER、SINTER、SUNION、SPOP。典型场景是标签系统、共同好友、抽奖。集合运算能力是它最大的价值SINTER可以求两个集合的交集这在社交关系里简直是神器。ZSet有序集合每个元素关联一个score按score排序。常用命令ZADD、ZRANGE、ZREVRANGE、ZSCORE、ZRANK、ZINCRBY。典型场景是排行榜、延迟队列、滑动窗口限流。和Set的区别在于多了一个排序维度底层是用跳跃表实现的插入和查找的时间复杂度都是O(logN)。说实话新手阶段最容易犯的错是明明数据有结构却全用String一把梭把所有字段拼接成一个JSON字符串塞进去。这样做的代价是你想改其中一个字段必须先把整个字符串读出来反序列化再写回去性能损失不说代码也丑。学会用Hash、ZSet这些原生结构会让你的代码优雅得多。2.3 命令使用中的关键禁忌使用Redis命令时有几条红线初学者很容易踩进去。禁止在生产环境使用KEYS命令KEYS pattern会遍历整个键空间在数据量大的情况下会阻塞Redis主线程几秒甚至几十秒期间所有读写请求全部卡住。要扫描key应该用SCAN命令它基于游标批量返回每次只查一小部分不会长时间阻塞。禁止随意使用FLUSHALL/FLUSHDB它会瞬间清空全部数据没有后悔药。除非你有完整的备份否则不要在生产环境执行。避免大Value的单次读写一个几MB的字符串通过redis-cli输出到终端和内部网络传输的成本完全不一样。大Value会拖慢单次命令执行时间也影响其他请求。注意阻塞命令的使用比如BLPOP、BRPOP如果业务逻辑允许一定要设置合理的超时时间否则消费者挂掉时这些连接会一直挂着不释放拖垮连接数。这些禁忌背后有个共同逻辑Redis是单线程处理命令的任何一条慢命令都会让后面所有命令排队。你写的每一条命令都要想一想它在最坏情况下会阻塞主线程多久。3. 深入Redis核心机制数据结构、持久化与内存策略3.1 底层数据结构选型与实现原理Redis能在性能和功能上都有出色表现一个很重要的原因是它对每种数据类型都根据数据规模进行了编码优化的灵活切换。我一个个说。String底层是SDS简单动态字符串而不是C语言传统的char数组。C字符串的问题是获取长度要遍历到末尾缓冲区溢出要自己处理遇到\0就认为结束了没法存二进制数据。SDS则额外记录了长度和使用空间实现了O(1)获取长度、自动扩容、二进制安全。我在学习的时候专门去看过源码一个short类型的SDS头部只有几个字节却能换来这么多好处很划算。List底层是quicklist它混合了压缩列表和双向链表两种结构的优势。元素少的时候是压缩列表节省内存元素多了会转成多个小的压缩列表节点用链表串起来。这样既避免了双向链表指针占用过多空间的浪费又避免了压缩列表在追加大量元素时的连锁扩容问题。Hash和ZSet在元素数量少、值比较小时使用压缩列表内存占用极低元素数量变大时Hash切换成哈希表ZSet切换成跳跃表。压缩列表的问题在于查找和更新是O(N)所以Redis在数据量超阈值时会果断切换成更适合快速查找的结构。这个阈值和hash-max-listpack-entries等配置有关具体数值根据版本略有区别。ZSet底层的跳跃表为什么不用红黑树或者平衡树有个很实际的原因跳跃表的实现比平横数简单太多却能在查找、插入、删除上做到差不多的复杂度。而且跳跃表天然支持范围查询比如按分数区间取TOP N这正好是ZSet的核心需求。用平衡树的话范围查询实现起来反而麻烦。理解底层结构不需要你手写一遍C代码但它能帮你回答很多实践中的问题为什么ZSet适合排行榜为什么小数据量时内存占用那么低为什么List在数据量大时依然能保持不错的操作性能这些都是面试高频问题也是有经验工程师和CV战士的分水岭。3.2 持久化机制详解RDB与AOF怎么选Redis是内存数据库如果只靠内存进程一崩数据全丢所以持久化是绕不开的话题。它有两套方案理解它们的取舍很关键。RDB快照在指定时间间隔内把内存中的数据集全量写入二进制文件。触发方式有三种手动执行SAVE同步阻塞、BGSAVE异步fork子进程写、自动触发如900秒内有1个key变更、300秒内有10个、60秒内有10000个。它的核心优势是文件紧凑、恢复速度快几GB的RDB文件加载也就几秒缺点是两次快照之间的数据会丢失而且BGSAVE时fork子进程在数据量巨大时可能短暂阻塞父进程。AOF日志每次写命令追加到日志文件末尾。通过appendfsync配置控制刷盘策略always每条命令同步刷盘最安全但最慢、everysec每秒刷盘一次最多丢一秒数据、no操作系统决定刷盘时机性能最好但最不安全。AOF最大的好处是数据安全性高缺点是日志文件比RDB大很多恢复速度也慢而且AOF重写时会占用额外的磁盘和CPU。混合持久化Redis 4.0之后引入了aof-use-rdb-preamble配置开启后AOF文件的前缀是RDB格式的内容后面追加新增的写命令。这样既保留了AOF的数据安全性又利用了RDB文件紧凑恢复快的优势。这个配置在生产环境强烈建议开启。那到底选哪个我的经验是能承受分钟级丢失、对恢复速度要求高可以只用RDB不能丢数据就开启AOF刷盘策略选everysec就能兼顾安全和性能而现代版本最稳妥的组合是RDBAOF同时开启并且启用混合持久化。你自己测试的时候可以把save 禁用自动RDB、appendfsync always、aof-use-rdb-preamble yes都配一遍各自做一次kill -9测试看看数据丢失的实际情况比看文档直观得多。3.3 过期策略与内存淘汰机制详解Redis存储的那些key最终都会面临内存放不下的问题。它有两套机制处理一个是“怎么删除过期key”另一个是“内存满了怎么办”。过期key的删除策略不是靠后台定时任务把所有过期key都扫一遍删掉那样开销太大。Redis用的是惰性删除 定期删除的组合拳。惰性删除当一个key被访问时如果发现它已经过期了就立即删除它。这个策略的缺点是如果过期key一直不被访问它就会一直在内存里。所以还需要定期删除每个一段时间默认100ms随机抽取一部分带过期时间的key检查并删除其中已过期的。注意这里是“随机抽取”不是全量扫描所以一个key可能过了很久才被随机扫到。但惰性删除和定期删除都做不到百分百清理真正兜底的是内存淘汰策略。当使用的内存达到maxmemory限制时Redis会按指定策略删除某些key可以通过maxmemory-policy配置去控制。常见策略有noeviction不淘汰任何key直接返回OOM错误。这是默认值生产环境如果没配策略内存满了新写入会直接报错。allkeys-lru对所有key按LRU最近最少使用算法淘汰。volatile-lru只对设置了过期时间的key按LRU淘汰没设过期时间的key永远不会被淘汰。allkeys-random随机淘汰任意key。volatile-random只对设置了过期时间的key随机淘汰。volatile-ttl淘汰剩余存活时间最短的key。实际操作中如果Redis只是纯缓存用allkeys-lru最直接如果还想保留一部分长期key用volatile-lru更安全。这里有个经验不要把volatile-random当默认策略因为“随机淘汰”意味着你的热点key也可能被淘汰一旦被淘汰下个请求就会穿透到数据库。我自己吃过这个亏当时用volatile-random结果热点数据过期瞬间把数据库打挂了。3.4 设置过期时间引发的缓存一致性思考这个部分不完全是Redis本身的功能而是你用它做缓存时一定要想清楚的逻辑。当数据库里的数据更新了缓存里那份怎么处理两种常见做法是先更新数据库再删除缓存或者先更新数据库再更新缓存。删除缓存比更新缓存更稳妥因为更新缓存相当于把数据库数据写了一遍到Redis并发情况下容易产生“后写的旧数据覆盖先写的新数据”的问题。而删除缓存策略配合“读时回源”机制可以保证数据最终一致。这里有三个注意点更新数据库和删除缓存不是原子的可以用消息队列或者订阅binlog来兜底重试。不做强一致性的业务允许缓存短暂不一致就没必要引入复杂的分布式事务。如果数据本身变化极频繁甚至不建议走Redis缓存因为缓存命中率太低还要承担一致性问题。缓存一致性是设计题不是Redis功能题想清楚你的业务能忍受多长时间的“脏数据”再决定用哪种方案。4. 事务、管道与Lua脚本让多条命令组合出更强的能力4.1 Redis事务机制与乐观锁实践Redis的事务是用MULTI、EXEC、DISCARD、WATCH这几个命令实现的。MULTI开始一个事务之后输入的所有命令会进入队列而不是立刻执行直到EXEC才会一次性按顺序执行所有命令。它保证的是事务中所有命令要么都执行要么都因为语法错误全部不执行而且执行过程中不会被其他客户端的命令插入。但要注意Redis事务和关系型数据库事务有本质不同它不支持回滚。如果一个命令在EXEC之后因为运行时报错比如对字符串做INCR失败其他命令照样执行。作者的理由是认为Redis命令的错误基本都是编程错误编程错误应该在开发阶段被发现而不是靠回滚兜底为了保证核心性能故意做得简单。这个设计哲学一直有争议但你必须在实践中接受它。如果需要给事务加“条件”就用WATCH实现乐观锁WATCH某个key然后在MULTI/EXEC中执行事务如果事务执行前被监测的key发生了修改EXEC会返回空值此时你可以重试。这个机制适合“先读后写、担心并发改”的场景比如账户余额扣减、库存预占等。它是许多分布式锁和秒杀方案的基础。4.2 管道技术把网络开销降下来Redis的执行时间大部分不是花在命令本身而是花在网络往返上。每个命令的Round Trip Time累积起来非常可观尤其是一次要执行几百个写操作时一条条发送的性能惨不忍睹。管道技术就是用来解决这个问题的客户端一次把多个命令连续发送给Redis服务端服务端依次执行后一次性返回所有结果。管道特别适合的批量写入场景比如一次性缓存几百个商品信息、批量增加计数器等。它的收益很容易算如果每秒钟能发出的请求是1万条有100条命令要发送用管道就能把网络往返从100次降到1次。但要注意管道里的命令太多了也可能撑爆接收缓冲区一般建议每次纳管在几十到几百条之间。Python和Java的客户端都有现成的pipeline接口用之前先看一下文档。4.3 Lua脚本实现原子操作的正确姿势管道和事务都不解决“原子执行”的问题。管道只是网络层面的优化命令之间可能被其他客户端插入事务虽然保证串行执行但不提供条件判断。如果需要“读一个值、判断条件、再写入”这种复合操作必须用Lua脚本。原理很简单Redis的Lua脚本执行是原子的脚本执行期间不会执行其他任何命令。比如扣减库存典型的场景先检查库存是否足够如果够就扣减否则直接返回失败。这一段逻辑用Lua写在Redis里就不存在并发超卖问题。分布式锁的释放也常用Lua先验证当前持有锁的标识符是不是自己是才删除。因为验证和删除是两个步骤如果分开执行很可能在验证之后删除之前锁过期被其他人拿到误删别人的锁。一个简单的减库存Lua伪代码如下local stock redis.call(GET, KEYS[1]) if tonumber(stock) tonumber(ARGV[1]) then return -1 end return redis.call(DECRBY, KEYS[1], ARGV[1])这里有个实用建议Lua脚本在Redis集群模式下所有被操作的key必须在同一个哈希槽上否则会报CROSSSLOT错误。解决办法是用hash tag比如把key设计成{user:1001}:order_list这样的格式让相关的key强制落到同一个slot上。我在刚开始用集群的时候就被这个问题卡了很久。5. 单机扛不住流量主从复制、哨兵与集群方案5.1 主从复制与读写分离的取舍单台Redis有瓶颈CPU、内存、网络都有限。最直接的扩展是主从复制一台主节点负责写多台从节点负责读从节点通过SYNC协议实时同步主节点的数据。这套方案有三个核心价值读写分离扩展读性能、数据热备、为后面哨兵自动故障转移打基础。主从复制的流程是这样的从节点启动后发送SYNC或PSYNC给主节点。如果是第一次同步主节点会BGSAVE生成RDB快照同时把快照期间的写命令缓存在repl_backlog缓冲区里快照传给从节点后从节点加载RDB主节点再把缓冲区的增量命令继续传给从节点直到两边数据一致。之后的同步就是持续地把主节点执行的写命令增量传播给从节点。实现上也简单配置就一行# 在从节点的redis.conf里加上 replicaof 主节点IP 6379或者直接用命令redis-cli -p 6379 REPLICAOF 主节点IP 6379这个方案在实际使用中有个容易忽略的坑主从同步是异步的从节点存在数据延迟。如果你让读请求打到从节点读到的可能是几十毫秒甚至更久之前的数据。对一致性要求高的业务不要无脑读写分离。还有个问题是主节点故障时从节点不会自动顶上需要人工介入这就要引入哨兵。5.2 哨兵模式自动检测与故障转移哨兵Sentinel解决的是“主节点挂了怎么办”的问题。它是一个独立部署的Redis进程主要做三件事监控主从节点的运行状态、在主节点故障时通知管理员或客户端、自动在从节点中选出一个新的主节点并执行故障转移。哨兵的判断机制可以分为主观下线和客观下线两个阶段每个哨兵周期性地向其他节点发送PING如果某个节点在超时时间内没有回复这个哨兵就认为它“主观下线”。当多个哨兵都认为主节点主观下线了并且数量超过quorum阈值时主节点被标记为“客观下线”随后进入故障转移流程。选出新主节点时哨兵会先淘汰那些复制偏移量落后太多的从节点然后按优先级排序优先级一样则选择复制偏移量最大的那个最后选runid最小的。这里面有个细节新主选出后其余从节点会自动指向新主节点重新建立复制关系。哨兵模式依然没有解决“写能力扩展”的问题写请求还是全落在单一主节点上。5.3 Redis Cluster集群分片与高可用的融合当单台Redis写性能也撑不住、或者内存容量需要几十G上百G时就得上Redis Cluster。它的核心思路是数据分片把整个键空间按hash映射分配到16384个哈希槽中每台节点负责一部分槽位。客户端通过CRC16(key) % 16384计算key属于哪个槽然后路由到对应节点。这里很多人会问为什么是16384个槽不是更多或更少这是多方权衡的结果槽太少数据分布不均匀槽太多心跳消息传状态的成本会增大。16384在大多数规模集群下够用消息体控制在合理范围。它的上限几乎不用考虑因为槽数量是逻辑概念和数据大小无关。集群模式下会遇到两类重定向错误MOVED错误key不在当前节点集群返回正确的节点地址客户端应该根据它去目标节点访问。ASK错误在槽位迁移过程中部分数据已经移到新节点旧节点无法处理返回ASK让客户端暂时去新节点查询。集群模式最大的限制是跨槽位的多键操作不支持。比如你想对一个hash里多个字段做事务操作这些字段必须都在同一个槽里。解决办法是hash tag把相同的标识用{}包起来让它们落到同一个槽代价是可能会造成数据倾斜所以在做key设计时要想清楚哪些字段必须被捆绑。在实际部署里我建议的演进路线是单节点验证方案然后做主从哨兵保证高可用再升级到Cluster处理更大规模。不要一上来就上Cluster它的运维复杂度比你想象得高很多如果不了解槽位和重定向机制排查问题会非常痛苦。6. 生产环境避坑实录常见问题与排查技巧6.1 缓存穿透、击穿、雪崩三个必须背下来的场景这三个词面试常考实践里更是日常。它们听着类似实际上是完全不同的故障场景对策也不同。缓存穿透查询一个根本不存在的数据Redis查不到请求就直接打到数据库。如果有恶意用户持续用不存在的ID发起请求数据库直接被拖垮。标准解法有两个一是用布隆过滤器在Redis前面做一层过滤大概率判断这个key是否存在不存在就直接拒绝二是对空结果也做缓存比如把不存在的key也缓存一个空值设置很短的过期时间避免反复打到数据库。缓存击穿某个热点key在过期的瞬间大量请求同时穿透到数据库导致数据库压力瞬间暴增。这个问题的特点是“单个key过期”。常见解法是互斥锁当缓存过期时只有一个请求能去数据库加载数据并回写缓存其他请求可以先等待或者用逻辑过期方案key不设置物理过期时间而是保存一个逻辑过期时间戳发现逻辑过期后马上返回旧数据同时发起异步线程去更新数据保证用户体验不中断。缓存雪崩大量key在同一时间段集中过期导致海量请求同时打到数据库。这和击穿的区别是“很多key同时过期”而不是一个key。解法上一个是给过期时间加一个随机值比如5-10分钟±随机分钟分散过期时间另一个是保底方案多级缓存比如本地Caffeine缓存 Redis即使Redis出问题本地缓存还能扛一下。我踩过一个很典型的坑上线优惠活动时给商品配置了统一的过期时间结果零点一到所有商品key同时过期瞬间数据库连接被打满整个服务不可用。从那以后我写过期时间都会做一个随机抖动避免“定时炸弹”式的同时过期。6.2 大Key与热Key两颗定时炸弹的排查与处理大Key指的是单个key的value过大比如一个String超过1MB一个Hash/Set有几十万甚至上百万元素。它的危害有几个网络传输耗时高会拖慢该连接上的所有命令删除大Key时如果用的是DEL主线程会阻塞很长时间集群模式下大Key会导致某个分片的数据量明显高于其他分片形成数据倾斜。怎么发现大Key# 扫描全库找出大Key redis-cli --bigkeys这个命令会对每个key做一次lazy统计输出最大的几个字符串、列表、集合等。它只是估算不完全准确但用来发现明显问题足够了。还有一个更精细的方法是MEMORY USAGE key可以精确地看某个key占用了多少内存。处理大Key的手段不外乎几种拆分成多个小key、压缩value、集合类数据分片存储、淘汰掉不用的字段。删除时要用UNLINK而不是DELUNLINK是异步后台删除不会阻塞主线程。热Key指的是某个key被访问的频率异常高单台Redis节点CPU被打满所有请求都集中在这一个节点上。常见表现是单节点CPU高、其他节点闲置。识别热Key可以通过redis-cli --hotkeys需要开启LFU策略或者用INFO commandstats看命令统计。处理思路一是给热Key加后缀拆分成多个副本分散到不同节点读请求随机访问其中一个副本二是做一层本地缓存把最热的数据放到应用进程内直接不去请求Redis。还有一个思路是用读写分离把热点数据复制到从节点由从节点分流。热Key问题在大促秒杀场景特别容易出现预案必须提前准备。6.3 慢查询、连接数与内存碎片排查Redis主线程是单线程的一旦出现慢查询所有请求都会排队。排查慢查询主要靠SLOWLOGSLOWLOG GET 10 CONFIG SET slowlog-log-slower-than 10000第一条命令查看最近10条慢查询第二条命令把“超过10毫秒”的命令记录下来并发日志。慢查询常见原因使用了KEYS或者某个大Key的提交、删除、排序操作。发现慢命令后优先检查是不是大Key在作怪。连接数也是一个隐形大坑。默认Redis最多允许10000个客户端连接如果应用没做好连接池复用每次请求都新建连接很快会达到上限。排查时用INFO clients看connected_clients正常的单实例连接池一般不会超过几百个。如果发现连接数异常增长先怀疑代码是不是没有归还连接。内存碎片也需要定期观察。INFO memory里的mem_fragmentation_ratio表示内存碎片率如果这个值大于1.5说明Redis的内存碎片很严重需要重启或考虑整理内存。碎片率过高通常是频繁修改value或者大量删除key造成的。还有一种情况碎片率低于1说明内存已经被swap到磁盘了这才是最危险的情况性能会急剧下降这就是为什么maxmemory必须提前设置好。6.4 监控命令与生产配置建议清单我梳理了一份生产环境必做的配置清单照着检查可以省很多事配置项推荐值说明maxmemory根据机器内存设置防止OOM建议为物理内存的60%-70%maxmemory-policyallkeys-lru缓存场景首选保留长期key可用volatile-lruappendonlyyes开启AOF持久化aof-use-rdb-preambleyes开启混合持久化save900 1 300 10 60 10000RDB自动快照策略按需调整slowlog-log-slower-than10000记录超过10ms的命令timeout300空闲连接超过300秒关闭tcp-keepalive60保持连接探活rename-command禁用危险命令比如FLUSHALL、CONFIG、KEYS可以改名或禁用监控方面我平时会用INFO servers看基础状态、INFO memory看内存指标、INFO stats看瞬时命令数再用redis-cli --stat实时滚动观察。这些信息帮助我快速定位问题是出在内存、连接还是慢命令上。如果你用的是云服务平台他们一般也有现成的监控告警面板但底层指标仍是这些东西。7. 写在最后通用的实践建议把这些内容从头到尾过一遍之后我最想说的一点是Redis的入门门槛确实很低但深入理解它的核心机制并不容易。一个简单的过期策略背后藏着惰性删除、定期删除和内存淘汰三级机制一个看似基础的持久化也有RDB、AOF、混合持久化的不同取舍。如果只是上网搜个命令绝对拼不出这个完整的认知拼图。我自己重新系统地学习一次之后最大的体会是把“为什么”搞清楚了。以前看到一个配置项只知道照着网上推荐填不知道它的背景和代价现在至少能回答“填这个配置是为了避免什么、它牺牲了什么”这个问题。生产环境出问题时也能更快地对照是内存、连接、慢命令还是同步哪个环节出的故障。最后分享一个很实用的小技巧用CONFIG SET可以动态修改运行中的Redis配置而不需要重启实例比如想临时改慢查询阈值、切换淘汰策略都可以。但要注意这些修改默认不会写到redis.conf里重启后丢失。所以调试没问题后记得把改动固化到配置文件里。Redis的学习资料非常多但真正能给你带来成长的一定是亲手搭建环境、亲手造故障、亲手解决故障的过程。别怕踩坑多踩几次你就明白为什么生产环境的老司机们总是反复唠叨那些“看起来很简单”的配置项了。