1. 先把环境装好Redis下载、安装与版本选型1.1 下载渠道与版本怎么定很多刚接触Redis的人第一反应就是去官网redis.io/download找安装包这个方向没错但选版本时容易纠结。官网提供的有两种路线一种是源码包适合Linux服务器另一种是桌面安装包不过这个对Windows用户并不友好——Redis官方一直不提供原生Windows版本Windows下那些exe安装包基本都是第三方编译的版本滞后而且生产环境基本不会用。我的习惯是生产环境一律用Linux源码编译安装追求省事就用发行版仓库里现成的包Windows上想体验就开Docker。版本选择上主线版本里选最新的稳定版也就是版本号中第二位是偶数的比如6.2、7.2、7.4这类。不要一上来就去追最新大版本尤其是刚发布的8.x虽然新特性诱人但生态兼容性和踩坑案例都还没沉淀下来稳定版本反而更可靠。如果只是本地学习Windows上用Docker跑一个redis容器是最省心的。官方镜像封装得很干净一行命令就能拉起来docker run --name redis-local -p 6379:6379 -d redis:7 redis-server --appendonly yes这样连安装环境都不用折腾数据还自动落盘到容器里。不过要提醒一点用Docker跑Redis做练习没问题但生产环境部署时一定要把数据目录挂载到宿主机持久化存储上否则容器一删数据就全没了。1.2 Linux源码安装三步走Linux上装Redis最推荐的方式还是源码编译。原因很简单你可以自己指定安装目录、选择内存分配器、按需生成systemd服务后续维护心里有底。发行版仓库里的包虽然方便但版本往往偏旧而且不少仓库的配置路径和官方默认值不一致容易给人埋坑。以CentOS/RHEL系为例完整步骤是这样# 1. 下载源码包 wget https://download.redis.io/releases/redis-7.4.1.tar.gz # 2. 解压并进入目录 tar xzf redis-7.4.1.tar.gz cd redis-7.4.1 # 3. 编译安装 make make install PREFIX/usr/local/redis编译之前建议先确认系统里有没有装gcc没有就执行yum install -y gcc。编译完成后redis-server和redis-cli会被安装到/usr/local/redis/bin下。你可以顺手做一步操作把这两个命令软链到/usr/bin/这样后面不用每次拼完整路径。ln -s /usr/local/redis/bin/redis-server /usr/bin/redis-server ln -s /usr/local/redis/bin/redis-cli /usr/bin/redis-cli启动时也不建议直接裸奔运行而是通过配置文件启动方便后续调整参数redis-server /usr/local/redis/etc/redis.conf第一次运行如果提示找不到配置文件可以去源码目录的redis.conf模板里复制一份。很多人忽略了一个细节make install并不会自动帮你安排配置文件这需要手动处理。1.3 重点配置别让Redis裸奔Redis默认配置是为“本机学习”设计的直接拿来当生产用安全隐患很大。这里把几个最关键的配置项拎出来说明白。配置项默认值生产建议说明bind127.0.0.1 -::1按需改为内网IP或保留本机只允许指定网卡访问不要轻易设成0.0.0.0protected-modeyes保持yes没有设置密码且bind公网时拒绝外部连接requirepass空必须设置设置访问密码建议强度不低于普通服务密码daemonizeno按需yes是否后台运行生产建议配systemd托管maxmemory0不限制设置为物理内存的50%~70%防止Redis把机器内存吃满appendonlyno建议yes开启AOF持久化避免重启丢数据其中bind和protected-mode这两个参数是新手最容易忽略的。protected-mode开启时如果Redis没有密码且监听了公网地址它只接受本机回环连接这其实是个保护机制。但很多人第一件事就是把protected-mode改成no这等于亲手把门锁拆了。我的经验是即使在内网只要Redis里存了业务数据也一定设密码并开AOF持久化别图省事。启动后可以用redis-cli -a 你的密码 ping验证是否正常看到PONG就说明服务起来了。2. Redis数据类型从“知道命令”到“知道为什么”2.1 String计数器、缓存与分布式锁的底层String是Redis世界最基本的砖块但它的底层设计并没有那么简单。Redis的String是用SDS简单动态字符串实现的而不是直接用C语言的char*。SDS的特点是可以O(1)获取字符串长度、自动扩容、二进制安全所以哪怕存的是序列化后的二进制对象也没问题。日常使用中String最常见的三个场景是缓存SET user:10086 {name:张三} EX 300带过期时间存对象。计数器INCR page:view:20241201文章阅读量、接口调用次数都是这么做的。INCR是原子操作不需要担心并发覆盖问题。分布式锁SET lock:order:12345 uuid EX 10 NX只有Key不存在时才能SET成功抢到锁的线程处理完业务再DEL释放。这里有个坑必须提醒String的value虽然最大能到512MB但生产环境里单个value超过几十KB就要警惕。我曾经排查过一个线上事故某业务把用户画像全量塞进一个Key结果value达到了几MB每次读取不仅耗内存网络传输也拖慢了接口响应。正确的做法是对象拆分、压缩存储或者改用Hash结构。另外GETSET、APPEND这些命令虽然好用但使用前要思考底层操作复杂度APPEND每次都会重新分配内存频繁追加对大Key是灾难。String的简单是用底层的精心设计换来的。2.2 Hash最像“对象”的一个类型Hash适合用来存一个对象的多个字段比如用户信息用户名、年龄、邮箱。它有两大特点一是内存友好字段少时底层用listpack紧凑编码存储二是可以单独操作某个字段不必整存整取。常用命令很直白HSET user:10086 name 张三 age 18 HGETALL user:10086 HINCRBY user:10086 score 10用Hash存对象比用String存JSON序列化结果强的地方在于Hash可以单独更新一个字段读取某个字段不必把整个对象都传回来这对大对象的高频局部更新来说省了很多流量。但Hash也有自己的局限它没有原生的“字段级过期”机制也就是说你不能让某个field在30秒后自动消失。真要实现字段过期最常见做法是在Hash里额外放一个时间戳字段读取时手动判断是否过期。另外要注意HGETALL的副作用——当Hash字段很多时HGETALL会一次性把所有数据拉到客户端类似于关系数据库里的SELECT *。我用它时都会先看字段数量字段超过几百个就把操作替换为HSCAN避免阻塞主线程。2.3 List和Set队列、去重与关系运算List底层是quicklist可以当队列用。经典用法是异步任务队列生产者LPUSH task:queue jobId消费者BRPOP task:queue 0。BRPOP是阻塞读取没有数据时会让客户端挂起等待比轮询高效得多。不过要注意Redis的List不适合做要求严格ACK的消息队列——消息取走了如果业务处理失败数据就丢了。这点要给想拿List替换MQ的朋友打个预防针。Set专门处理“唯一性”和“集合关系”点赞去重SADD post:123:likes user:1001自然去重。抽奖SPOP post:123:participants 3随机弹出3个元素公平不重复。共同好友SINTER user:10086:friends user:10002:friends交集即共同好友。顺带提醒一个运维大坑SMEMBERS会把集合里所有元素一次性取出如果集合有几十万个元素这条命令会让Redis卡顿数秒。别去问我是怎么知道的。需要遍历时用SSCAN代替分批次取出。2.4 Sorted Set排行榜、延迟队列与滑动窗口限流Sorted SetZSet是Redis里我最喜欢的数据结构它的每个成员都带一个score分数按分数有序排列。核心命令ZADD leaderboard 10000 user:1001 ZREVRANGE leaderboard 0 9 WITHSCORES # 取Top10 ZINCRBY leaderboard 10 user:1001 # 给用户加分底层用的是跳表哈希表所以既能按分数范围高效查询又能O(1)按成员找到分数。除了排行榜两个常见高级用法延迟队列score存任务执行的时间戳任务进来时ZADD delay:queue 未来时间戳 taskId有一个后台线程每隔几秒执行ZRANGEBYSCORE delay:queue 0 当前时间戳 LIMIT 0 100把到期的任务取出来处理再ZREMRANGEBYSCORE移除。这套方案比轮询数据库高效很多。滑动窗口限流比如限定某个用户每分钟最多请求10次用ZADD key 当前时间戳 唯一标识再统计ZCOUNT key 当前时间戳-60 当前时间戳超过10就拒绝。为了防止内存无限增长可以配合ZREMRANGEBYSCORE key 0 当前时间戳-60定期清理窗口外的记录。有个容易踩的坑当两个成员的score相同ZSet按字典序排列。设计排行榜时如果只给一个score可能出现名次跳变。我会在score里塞一个“积分*1000000 时间戳尾号”之类的组合值让score真正代表业务排序而不是依赖字典序。2.5 Bitmap、HyperLogLog、Geo看着冷门其实很香这三种类型相对冷门但用好之后能显著简化某些业务的实现。Bitmap本质是String按位操作适合做布尔状态记录。最经典的案例是用户签到一年365天给每个用户分配一个365位的Bitmap某天签到就SETBIT sign:user:10086 第几天 1查询签到天数用BITCOUNT想查某天是否签到用GETBIT。相比每个签到记录都存一条数据这种方案内存占用几乎是零头。HyperLogLog适合做海量数据的去重统计。用PFADD uv:20241201 userId记录访问用户PFCOUNT uv:20241201统计UV数。它的底层是用概率算法估算的误差大约0.81%对UV这种本身就有统计误差容忍度的指标完全够用。只是需要注意它不适合精确统计也不支持查“具体有哪些用户”。Geo是Redis 3.2之后引入的地理位置结构底层还是ZSet的实现。GEOADD city:locations 116.397 39.908 北京记录坐标GEORADIUS city:locations 经度 纬度 半径 km可以查出附近的地点。实现“附近的人”这类功能几十行代码就搞定不需要接入专门的LBS服务。3. 实战中躲不开的坑问题排查与性能事故3.1 大Key、热Key先定位再拆解生产环境里Redis卡顿十次有八次是大Key或者热Key惹的祸。大Key指单个Key的value特别大比如几MB的String、几万个元素的Set热Key指某个Key被超高频率访问导致单节点压力集中。定位手段很简单Redis自带的--bigkeys参数可以直接扫描出大Key的分布情况redis-cli -a 密码 --bigkeys扫描结果会按String、List、Set、ZSet、Hash分类列出最大的几个Key。需要提醒的是--bigkeys是遍历全量Key虽然底层用的是SCAN渐进式扫描不会阻塞主线程但在线上大实例上跑还是要挑业务低峰期。拆解大Key的思路一般是分片。比如一个大Hash可以按用户ID取模拆成多个Hash比如user:info:0、user:info:1。字符串大Value可以压缩、分离冷热数据。热Key的应对方式则更偏架构层面给热点Key加本地缓存JVM/Caffeine或者用多级缓存分摊Redis压力实在不行还可以做Key副本把热点Key复制成多份在多个节点上分担读流量。3.2 缓存穿透、击穿、雪崩一次讲完应对套路这三个词在面试里高频出现实际线上也会遇到值得放在一起说。穿透请求一个根本不存在的数据缓存里查不到每次都打到数据库。应对办法有两种一是把空结果也缓存起来设置一个较短的过期时间比如30秒二是用布隆过滤器先判断数据是否存在不存在直接返回避免无效查询到后端。击穿某个热点Key在过期的一瞬间大量请求同时穿透到数据库。最常用的方案是互斥锁缓存过期后抢到锁的请求去查库并重建缓存其他请求先等一会儿再读缓存。伪代码如下# redis-py示例 data redis.get(key) if data is None: if redis.set(lock_key, 1, nxTrue, ex5): data db.query(...) redis.set(key, data, ex300) redis.delete(lock_key) else: time.sleep(0.1) data redis.get(key)当然还有逻辑过期方案即缓存永不过期但给Value塞一个过期时间字段后台线程发现逻辑过期就主动更新。雪崩大量Key在同一时间集中过期数据库瞬间被压垮。解决办法也直接过期时间加随机因子比如300秒基础上随机加0到60秒打散过期时间窗口。我自己上线缓存时都会写一个工具方法生成“基础过期时间 随机偏移”的TTL已经成了固定习惯。3.3 DEL和SCAN删除也要讲究技巧平时删Key大多数人就是一个DEL走天下。但面对数百万Key的实例DEL一个包含大量元素的大Key会导致Redis主线程卡顿因为DEL的时间复杂度跟元素数量成正比。Redis从4.0开始提供了UNLINK命令本质是异步删除主线程只负责把Key的引用摘掉真正释放内存交给后台线程UNLINK user:10086业务代码里删除大Key时我通常直接用UNLINK效果一样但不会阻塞。另一个高频错误是用KEYS命令扫描所有Key。KEYS *会遍历全库数据量大时瞬间阻塞服务。正确的是用SCAN游标分批遍历redis-cli -a 密码 --scan --pattern user:*小规模清理的时候还可以写个循环脚本分批删除比如下面这样# 分批删除示例 redis-cli -a 密码 --scan --pattern temp:* | head -n 1000 | xargs -r redis-cli -a 密码 UNLINK这种方案每次只处理1000个Key压力可控不会把主线程打满。3.4 持久化数据安全RDB、AOF、混合持久化到底怎么选很多初学者刚用上Redis时只把它当缓存完全没有持久化的概念。后来遇到一次服务器重启丢了大量数据才意识到持久化的分量。我建议只要Redis里存了不能接受丢失的数据就一定开启持久化。Redis的持久化方式就三种方式工作机制优点缺点RDB按时间间隔生成全量快照恢复快、文件紧凑两次快照之间数据可能丢AOF追加每一条写命令数据安全性高文件大、恢复慢混合持久化RDB快照 AOF增量日志兼顾恢复速度与数据安全Redis 4.0支持默认配置下Redis用的是RDBsave规则默认是这样900秒内有1次写操作、300秒内有100次写操作、60秒内有10000次写操作满足任意一条就触发一次快照。如果你的业务对数据一致性要求高建议开启AOF并把appendfsync设为everysec也就是每秒刷一次磁盘。这意味最多丢一秒的数据对绝大多数业务完全可接受。AOF文件会随时间膨胀Redis会在满足触发条件时执行BGREWRITEAOF自动重写压缩成新的日志文件。如果开启了混合持久化aof-use-rdb-preamble yes重写后的AOF文件前段是一个RDB快照后面跟上增量命令重启恢复时既快又安全。有个容易踩的坑是RDB快照触发频率过高。save 60 10000这条规则在高写入场景下可能每分钟触发一次BGSAVE而BGSAVE会fork子进程内存占用瞬时翻倍。我在一个内存64G、已用50G的机器上就踩过这种爆内存的坑后面专门把快照频率调低改靠AOF兜底。4. 线上监控与调优INFO命令就够了4.1 一眼看出问题INFO关键指标速查Redis自带一套运行时指标系统就是INFO命令。不需要上什么监控平台先用它确认基本情况。常用指标有这么几个redis-cli -a 密码 INFO重点关注这些字段指标含义关注点connected_clients当前客户端连接数接近maxclients时需扩容或排查连接池used_memory已用内存含数据开销结合maxmemory判断是否快满mem_fragmentation_ratio内存碎片率长期高于1.5需考虑碎片整理或重启instantaneous_ops_per_sec当前每秒操作数观察流量变化容量规划依据keyspace_hits/keyspace_misses缓存命中/未命中累计命中率持续偏低说明缓存策略有问题evicted_keys因内存淘汰被逐出的Key数持续增加说明容量不足或淘汰策略过严rejected_connections因达到maxclients被拒的连接数非零则说明连接数不够或存在连接泄漏以上指标配合一个简单的逻辑就能做初步判断used_memory居高不下再加evicted_keys持续增长基本可以实锤容量不足mem_fragmentation_ratio长期徘徊在1.5以上说明内存碎片严重低峰期DEBUG DEFRAG或者直接重启主从节点能缓解。4.2 内存快不够了过期策略与逐出策略Redis默认情况下内存用光了就直接拒绝写请求这在缓存场景下非常致命。解决办法是设置合理的maxmemory和maxmemory-policy。maxmemory-policy有以下几个选择策略行为适用场景noeviction内存满时拒绝写操作默认适合不能淘汰数据的场景allkeys-lru全部Key中淘汰最久没用的纯缓存allkeys-lfu全部Key中淘汰访问最少的访问频率差异大的缓存volatile-lru只在设了过期时间的Key中淘汰有一部分Key不能丢的场景volatile-random从设了过期时间的Key中随机淘汰临时数据缓存我遇到的大部分缓存场景直接用allkeys-lru就够了比默认的noeviction抗压能力强很多。要注意区分lru和lfu访问次数少但每次访问都宝贵的场景lru会把它们淘汰掉lfu会更精细。Redis 4.0后默认支持LFU如果你的Redis发行版版本较新可以直接选allkeys-lfu。内存还有一个隐藏开销容易被忽视过期Key并不是一到时间就立刻被删除的Redis是“惰性删除定期删除”混合策略。定期删除每100ms跑一次抽样检查但大量过期Key积压时会占着内存这时候可以用INFO里的expired_keys观察。如果积压严重适当调小hz间隔可能会加剧扫描负担更推荐的做法是业务层面打散过期时间别让几十万Key同一秒过期。4.3 慢查询与阻塞把“卡顿”变成“可量化”Redis对慢请求有自己的记录机制叫做slowlog。默认阈值是10000微秒10毫秒生产环境建议调低到1毫秒或5毫秒才能抓到潜伏的问题redis-cli -a 密码 CONFIG SET slowlog-log-slower-than 5000 redis-cli -a 密码 SLOWLOG GET 20SLOWLOG GET能看到最近20条慢命令包括命令内容、执行耗时、执行时间。看到一条命令耗时几十毫秒不要急着骂Redis慢先想想这条命令是不是O(N)操作。最常见的慢命令是KEYS *、SMEMBERS、HGETALL、LRANGE配合大Key使用。解决办法用SCAN替代KEYS用SSCAN/HSCAN替代全量拉取List做队列时只取必要的一小段。另一个容易忽略的阻塞点是fork。RDB快照或AOF重写时都会fork子进程即使使用了Copy-On-Writefork瞬间也可能阻塞数十毫秒。内存占用越大fork越慢。处理思路是控制单个Redis实例的内存使用量常见建议是单实例4G到8G以内超过这个规模优先考虑分片集群或者多实例部署而不是一味地往单实例里塞数据。还有一类阻塞来自客户端线上操作大量BRPOP阻塞连接不释放、连接池泄漏导致connected_clients虚高。用INFO CLIENTS可以看具体连接分布排查的时候我会重点看哪些客户端长时间idle为0但又一直占用着连接。5. 给新手的几条心法把笔记变成自己的工具这套笔记写到这里核心内容差不多都覆盖了。最后想聊几句学习心得这些不是标准答案但我自己走下来真的觉得受益。第一命令背会不如理解数据结构。Redis的命令虽多但本质上都是在操作那五种基本结构把String、Hash、List、Set、ZSet的底层设计和适用场景琢磨明白遇到业务场景自然知道用什么结构而不是一个个命令去试。第二一定要亲手搭一个实例往里面塞数据然后故意搞点问题再排查。比如把某个Key写到100MB跑一次--bigkeys看看内存变化故意开一小时的save 1 1观察fork后内存突变。没有这些坏体验你永远不会对“大Key”三个字有体感。第三把笔记持续更新起来。我现在说的这些坑随着Redis版本迭代可能部分过时但排查思路和调优方法论是通用的。真正值钱的不是你收藏了多少篇文章而是你看完笔记后自己动手验证过多少遍。Redis入门快精通难但这条路上踩过的每个坑都会在某个深夜救你一命。希望这份笔记能让你少走几步弯路剩下的路还得你自己去跑。