★ FEATURED ARTICLE 说个实话Redis 是被低估得最厉害的一个中间件。很多人学了几天会了SET和GET知道五种数据类型就以为自己入门了结果一到面试被问“缓存穿透怎么解决”“主从切换会不会丢数据”或者一上线就被慢查询、内存暴涨、分布式锁失效折腾到怀疑人生才发现自己根本没摸到 Redis 的门。这篇笔记不是给你背面试题的是按我实际折腾 Redis 的路径整理的从安装选型、数据类型底层逻辑到高可用架构、缓存治理、常见故障排查一次讲透。内容适用于用 Redis 做缓存、做分布式锁、做排行榜、做消息队列的开发者和运维同学也适合准备大厂面试、想系统梳理 Redis 知识体系的人。我尽量用大白话讲清楚每个关键选择的“为什么”而不是只告诉你“怎么做”。1. 学习路线与整体设计思路拆解1.1 为什么你该把 Redis 当“数据结构服务器”来学很多教程开场就说“Redis 是高性能 KV 缓存数据库”这个定位本身没错但它直接把你的思路带窄了。如果只把 Redis 当缓存那你永远只会用它来存字符串遇到实际需求就想“这玩意儿是不是不适合”——排行榜用 ZSet、去重用 Set、消息队列用 List 或 Stream、分布式 ID 用 INCR、附近的人用 GEO这些都不是“缓存”而是数据结构能力。我建议把 Redis 理解成“一个跑在内存里的数据结构服务器”。它和 MySQL 最大的区别不是快而是它的数据模型本身就是为特定数据结构设计的你往里面放 String、Hash、List、Set、ZSet它帮你维护增删改查、排序、聚合、去重这些能力。学 Redis 的第一原则就是拿到一个需求先判断“这个数据结构适不适合用 Redis 表达”而不是“能不能塞进缓存里”。带着这个思路学习路径就清晰了先掌握命令和数据结构再理解持久化和过期策略接着上高可用和集群最后回到缓存治理和分布式锁这些真实场景。每一步都在解决前一步带来的新问题是一条完整的链路。1.2 按阶段拆解基础、进阶、实战三步走第一阶段是基础目标是“会用”。这个阶段只需要搞定三件事安装、五种数据类型、常用命令。你可以把 Redis 跑起来然后用redis-cli或者可视化工具比如 Another Redis Desktop Manager手动敲命令把每种数据类型的增删改查、过期时间、TTL 都过一遍。这一步不需要背命令大全先把最常用的三十个命令用到条件反射就行。第二阶段是进阶目标是“懂原理”。这个阶段要搞清楚三块内容Redis 为什么快单线程 IO 多路复用、数据怎么不丢RDB 和 AOF、内存不够了怎么办过期策略和淘汰策略。这三个问题是面试高频题也是你以后排查性能问题和设计缓存方案的理论基础。很多人在这个阶段容易犯的错是只背概念不结合命令去验证。比如你背了“Redis 默认有 16 个库”但你不知道SELECT 1切库之后AOF 重写、RDB 快照到底怎么处理多库数据你背了“LRU 淘汰”但你不知道 Redis 的 LRU 是近似实现不是严格 LRU。第三阶段是实战目标是“会排障”。这一阶段要围绕真实场景展开主从怎么搭、哨兵解决了什么问题、集群的槽位是怎么分配的、缓存穿透击穿雪崩分别怎么应对、分布式锁怎么实现才不会出事故。这个阶段的标志是你开始能看懂redis.log里的告警信息能根据INFO命令的输出判断系统健康度能在 Redis Desktop Manager 的连接失败提示里快速定位问题。我个人建议这个阶段配合 Docker 来做实验因为主从、哨兵、集群的搭建会反复摧毁重建用容器最省心。2. 环境准备安装、选型与可视化工具的坑2.1 Windows 安装别去官网下“官方 Windows 版”先说一个很多人踩过的坑Redis 官方是不支持 Windows 的官网只提供 Linux 源码包。你在网上搜“redis windows 下载”搜到的那些.exe安装包基本都是第三方移植版或者微软旧版维护分支。不是说不能用而是要选对来源。如果你只是本地学习我推荐最常见的方案去 Redis 的 Windows 移植仓库比如 tporadowski/redis下载 zip 包解压后直接运行redis-server.exe默认端口 6379 就能起来redis-cli.exe就是命令行客户端特别适合新手。注意两个细节第一这个移植版大多停留在 Redis 5.x 或 6.x 版本学习和单机测试没问题但它和 Linux 官方版在高版本特性上会有差异生产环境千万别用第二启动后进程会一直占着控制台窗口关掉窗口 关掉服务学习阶段无所谓但你最好知道有redis-server --service-install这种以 Windows 服务方式运行的命令。Linux 上安装是更正经的做法。以 CentOS 和 Ubuntu 为例源码编译是标准的安装路径下载源码包、make、make install。编译之前记得装好gcc和make否则会报一堆让人头大的编译错误。编译安装完Redis 的可执行文件会放在/usr/local/bin配置文件在源码目录下的redis.conf。这里有个常见坑很多人直接./redis-server启动结果发现根本没有配置文件生效所有的数据持久化和后台运行配置都失效了。正确姿势是./redis-server /path/to/redis.conf显式指定配置文件。2.2 Docker 方式学习高可用架构最快的路径如果你要学主从、哨兵、集群我强烈建议直接用 Docker。手写配置文件、在一台机器上起多个实例不是不行但改端口、改 pid 文件、调日志路径会消耗大量耐心。用 Docker 的话一条docker run命令就是一个独立实例网络隔离也是天然的。举个例子搭建一主两从的 Redis 主从结构# 创建自定义网络方便容器间通过容器名互相访问 docker network create redis-net # 主节点 docker run -d --name redis-master --network redis-net -p 6379:6379 redis:7.0 redis-server --appendonly yes # 从节点1 docker run -d --name redis-slave1 --network redis-net -p 6380:6379 redis:7.0 redis-server --appendonly yes --slaveof redis-master 6379 # 从节点2 docker run -d --name redis-slave2 --network redis-net -p 6381:6379 redis:7.0 redis-server --appendonly yes --slaveof redis-master 6379启动完成后进入主节点容器执行INFO replication你就能看到两个从节点已经连接上来。用 Docker 做这种实验的好处是环境干净、销毁容易、模拟故障特别方便。比如你直接docker stop redis-slave1就能观察主从断开后主节点有没有报错、从节点重连后的数据同步情况。注意Docker 方式虽然方便但你要分清两个概念——--slaveof这是主从复制的配置不是集群的配置。主从复制解决的是“数据多副本冗余”集群解决的是“数据分片存储”。很多人把这两个搞混后面看集群文档时一脸懵。2.3 可视化客户端Redis Desktop Manager 的替代品Redis Desktop Manager简称 RDM是搜索最多、知名度最高的 Redis 可视化客户端但它的坑也不少。2022 年起新版 RDM 开始收费如果你搜“redis desktop manager 免费版”或者“redis desktop manager 开源旧版”能找到的是最后一个免费开源版本大概停在 2022 年 6 月左右。当年很多人就在这个坎上栽了跟头——下载安装了新版一打开就弹试用提醒还看不到 key 列表的完整功能。我实际用下来的推荐是如果只是日常学习直接用Another Redis Desktop Manager这是一个完全开源免费、持续维护的替代品。它的 UI 比旧版 RDM 更现代支持 SSH 隧道、支持可视化查看 stream、支持命令执行的实时监控对单机、集群、哨兵模式都有不错的支持。当然如果你只有几台服务器、键也不多用命令行的redis-cli其实完全够可视化客户端的核心价值是让你看清 key 的分布、内存占用和过期时间排查问题时特别直观。3. 五大数据类型与底层实现逻辑3.1 String不只是字符串的三层编码String 是一个绕不开的基础但你真不一定了解它。Redis 的 String 除了存文本还能存数字配合 INCR/DECR 做计数器、存二进制数据比如图片的字节流但容易让你翻车的点在于它的内存编码。Redis 对 String 做了三种内部编码int纯数字、embstr短字符串、raw长字符串。前两种字节数少存储紧凑超过 44 字节会自动转成raw。这个 44 字节不是随便定的它和 Redis 内部redisObject结构的对齐、内存分配器的分配粒度有关你不需要死记但你得理解Redis 对短字符串做了极致优化所以设计 key 时别弄动辄几百字节的 value除非业务必须。实际测试下来一个几百字节的 value 比短字符串多占 3~5 倍内存这在千万级 key 的缓存里就是几十 GB 的差距。String 最常见的生产场景有三个缓存、计数器、分布式 ID。计数器用INCR时要留心INCR不准的坑——这里说的“不准”不是 Redis 算错而是并发下的计数语义问题。如果你用INCR做库存扣减命令本身是原子的没问题但如果你先GET再SET这就是经典的读改写竞态丢更新就是必然结果。类似“浏览量 1”这种业务用INCR没问题但“基于当前值做复杂计算再写回”就必须用 Lua 脚本或者加锁。3.2 Hash对象类数据的“常规武器”和 Redis 的“乞丐版分片”Hash 在业务里最典型的应用是存储对象。比如一个用户信息最笨的存法是SET user:1001 {name:tom,age:18}问题是改一个字段就要整体覆盖整个 JSON浪费网络和内存。用 Hash 存就变成了HSET user:1001 name tom age 18改哪个字段就只更新哪个字段还能单独对字段设置过期时间吗不行Hash 本身没有字段级别的 TTL这是它和 String 的另一个取舍。Hash 内部编码有两种ziplist和hashtable。当字段数量少、字段值小的时候用ziplist紧凑存储字段多了或者值大了自动转成hashtable。这里有一个用 Hash 做“小分片”的思路当单个 key 的 value 过大比如一个大 List 存了百万条记录会导致读写这个 key 的耗时增加这在 Redis 里叫“大 key 问题”。解决方案之一就是把一个大集合拆成多个小 Hash。举例来说如果你要存一个用户的行为记录一天几十条不要用SET user_actions:1001 大JSON而是按天分片HINCRBY user_actions:20250120:1001 type_click 1这样每个 key 只负责一天的增量数据。这个思路在任何需要给单个 key 瘦身的场景都通用理解它能帮你解决一大批“Redis 查询越来越慢”的问题。3.3 List 和 Stream队列功能到底用谁List 的LPUSHRPOP组合是最简单的生产者消费者模式配合BLPOP还能实现阻塞读很多轻量级消息队列就是用这个做的。但 List 做队列有天然的毛病消息丢失没有重试机制没有消费确认消费者崩了就永远丢了而且LRANGE翻页取数据虽然方便但对长列表是 O(N) 操作列表一长就拖垮性能。所以 Redis 5.0 之后引入了 Stream它的设计目标就是正儿八经的消息队列支持消费者组、支持消息确认ACK、支持 PEL待处理列表、支持持久化。如果你在做项目时需要一个“能用但不想引入 Kafka/RabbitMQ”的轻量队列Stream 几乎是唯一正解。我自己的建议是队列非常简单的场景比如事件通知丢了也无所谓可以用 List要求消息不丢、要消费组、要重试用 Stream。面试问到“Redis 做消息队列”你要能说出这个演进关系比单纯背命令值钱多了。3.4 Set 和 ZSet从去重到排行榜Set 用来做去重和集合运算交集、并集、差集典型场景是抽奖、标签系统、共同好友。ZSet 比 Set 多了分值排序底层是跳跃表 哈希表跳跃表的时间复杂度是 O(log N)所以 ZSet 在百万级数据量下的排序操作依然很快。排行榜、实时热点、延时队列都是 ZSet 的主场。我要提醒一个 ZSet 的坑同样是ZADD如果你在写入时不控制 member 的规模一个 ZSet 里有几百万个 member后续的ZRANGE、ZREM虽然单次很快但内存占用会非常吓人。ZSet 的成员越多跳跃表的指针开销越大单个 member 的额外开销可能有几十字节。所以设计上要注意排行榜类数据要么只保留 Top N用ZREMRANGEBYRANK定期清理要么按业务维度拆 key比如按天拆排行榜千万别让一个 ZSet 无限增长。4. 高可用架构主从、哨兵与集群4.1 主从复制REPLICAOF 背后的增量与全量同步主从复制解决的是“单点故障”问题。主节点可读可写从节点默认只读主节点把写操作同步给从节点。同步分两种情况全量同步和增量同步。全量同步发生在从节点刚连接主节点、或者主从数据差距过大时。流程是从节点发送PSYNC命令主节点执行BGSAVE生成 RDB 快照发给从节点从节点清空旧数据并加载快照然后主节点把快照生成期间新增的写命令存在复制缓冲区里再发给从节点。增量同步靠的是主从之间维护的复制偏移量如果偏移量还在缓冲区范围内只需要同步差额部分如果从节点断连太久缓冲区里的数据已经覆盖了就得重新全量同步。这里有一个隐藏很深的坑如果从节点断连时间很短但主节点的复制缓冲区太小默认 1MB可通过client-output-buffer-limit replica调大也会触发全量同步。全量同步一旦频繁发生主节点要反复 BGSAVE 传输数据CPU 和网络都会被打满导致主节点阻塞。生产环境出现“主从反复全量同步”的情况第一件事就是去看INFO replication里的偏移量差值和缓冲区大小。4.2 哨兵自动故障转移的“哨兵进程”主从复制解决了数据冗余但主节点挂了从节点不会自动顶上需要人工切换。哨兵Sentinel就是来解决这个问题的它是一个独立进程负责监控主从节点的健康状态在主节点挂掉后自动从从节点中选举出一个新主节点并把其他从节点重新指向新主节点。但哨兵不是万能的。它最被人质疑的点是哨兵本身就是单点虽然可以部署哨兵集群而且故障转移期间存在“脑裂”窗口。经典场景主节点和哨兵之间的网络发生分区哨兵认为主节点挂了选举出新的主节点但原主节点其实还活着还能接收写入等网络恢复后原主节点的数据就和新主节点不一致了这部分丢失的数据无法找回。所以涉及钱的业务比如扣库存、交易流水不能只靠 Redis 主从 哨兵保证强一致这是架构层面的问题。用 Docker 搭建哨兵的时候最容易被坑的是配置文件里的sentinel monitor master-name host port quorum这个host不能写127.0.0.1因为哨兵需要通知“其他”哨兵和“其他”从节点连接主节点。在容器环境里主机地址要写容器网络中可达的别名的地址比如redis-master。这个细节我当年调试了一下午白屏的时间都浪费在地址可达性上。4.3 集群数据分片的槽位分配以及为什么集群也有“一票否决”Redis Cluster 和主从哨兵是两套不同的体系。Cluster 把整个数据空间分成 16384 个槽位每个节点负责一部分槽位key 通过CRC16(key) % 16384计算属于哪个槽。写请求如果落到了非负责节点节点会返回MOVED错误客户端要跟着重定向。这是 Cluster 和单机模式最大的体验差异——你的客户端必须支持集群协议比如 Jedis 的JedisCluster、Lettuce 的集群模式否则会出现各种莫名其妙的连接和写入失败。Cluster 本身自带主从冗余每个主节点可以挂一个或多个从节点主挂了从自动顶上。但要注意Cluster 的可用性判定比哨兵更严格如果一个主节点和它的所有从节点同时挂掉整个集群就会进入不可用状态即使其他槽位的主节点都活着。这就是少数派不可访问导致集群不可用的经典场景。查询操作可以通过CLUSTER SLOTS命令看清楚每个槽位的负责节点这个命令排障时非常好使。Docker 部署集群有几个注意点端口映射不能只映射 6379因为集群通信要用 16379总线端口不映射会造成节点间通信失败容器重启后 IP 变化会让集群变的不可用解决办法是给容器设置固定 IP--ip或使用 Docker Swarm / Kubernetes 的稳定 DNS 名称。这些问题在本地实验时不明显但如果你用 KubeSphere 之类的平台去搭建 Redis 集群就会频繁遇到“集群状态正常但客户端连不上”的怪事排查到最后基本都是网络标识变动引起的。4.4 从“会搭”到“会调”配置参数背后的取舍搭建完高可用架构你才能真正读懂配置文件里的各种参数。比如maxmemory和maxmemory-policy决定了内存耗尽后的行为——allkeys-lru是全局近似 LRU 淘汰volatile-ttl只对设置了过期时间的 key 淘汰。再比如appendonly yes开启 AOF 后appendfsync everysec表示每秒刷盘一次这是性能和可靠性的折中方案always最安全但性能下降明显no交给操作系统决定但可能丢失一秒钟的数据。关于 AOF 和 RDB我的建议是生产环境两者都开RDB 做快速恢复的冷备AOF 做灾备的精确日志。只开 AOF 的坑是AOF 文件会越来越大虽然 rewrite 能瘦身但如果宕机时 AOF 文件有损坏Redis 可能启动失败需要先运行redis-check-aof --fix修复。只开 RDB 的坑更明显两次快照之间的数据全部丢失。我遇到过把 RDB 快照间隔设成 900 秒的项目一次断电丢了十五分钟缓存虽然后台有 MySQL 兜底但那个时间段的请求压力直接把 DB 打崩了这个教训说明持久化参数不是随便填的。5. 缓存治理穿透、击穿、雪崩与分布式锁5.1 缓存三大灾难的应对不是靠 Redis 本身缓存穿透、击穿、雪崩这三个问题面试必问但很多人回答得过于套路化。我按自己的经验说说区别和处理优先级。缓存穿透是查一个根本不存在的数据缓存里没有数据库里也没有请求直接打到 DB。对 Redis 而言它根本没压力坏的是 DB。常见的解法有三种缓存空值设置一个较短的过期时间比如 5 分钟、布隆过滤器一种空间效率很高的概率型数据结构不存在则直接短路、参数校验拦截非法请求。我个人觉得业务层参数校验是最先该做的布隆过滤器适合 key 基数大的场景空值缓存适合 key 容易被穷举暴力的场景。缓存击穿是某一个热点 key 过期瞬间大量请求直接打到 DB。注意是“单个 key”不是“一批 key”。应对的核心思路是“不让 DB 扛流量”一是互斥锁只有一个线程去查 DB 重建缓存其它线程等待或返回默认值二是逻辑过期不让 key 实际过期而是在 value 里塞一个过期时间戳后台异步刷新适合对一致性要求不高的热点数据。缓存雪崩是大量 key 同时过期或者 Redis 实例宕机导致流量直扑 DB。处理手法过期时间加随机值比如SETEX key (base random(0,300))、热点 key 预热、多级缓存兜底本地 Caffeine 再挡一层。在 Redis 本身宕机时多级缓存几乎是唯一能在 Redis 恢复前保护 DB 的手段否则你再怎么设计过期时间也挡不住洪水。5.2 分布式锁SET NX EX 和 Lua 缺一不可说到分布式锁最常见的实现是基于SET key value NX EX seconds。注意这个命令必须是一条命令完成不能拆成SETNX再EXPIRE因为两条命令之间有间隙进程崩了锁就没过期时间了死锁就是这么来的。然后是释放锁很多人写成if (redis.call(GET, KEYS[1]) ARGV[1]) then return redis.call(DEL, KEYS[1]) else return 0 end为什么要用 Lua因为“判断值是否是自己的”和“删除 key”是两个操作拆开执行中间锁过期了别的线程拿到了锁然后你把这个别人的锁删了。这个 bug 在并发稍高的场景下必现。用 Lua 把两步合并成一个原子操作这是分布式锁最底层的底线。还有两个进阶问题要心里有数。第一个是“锁过期时间怎么设”业务执行时间可能超过锁的过期时间导致锁被提前释放解决办法是“看门狗”机制——在持有锁期间定期续期但这是 Redisson 这些客户端库实现的能力自己裸写要慎重。第二个是“主从切换锁丢失”的问题主节点拿到了锁但数据还没同步到从节点主节点挂了从节点顶上后锁就没了。Redisson 的 RedLock 试图解决这个问题但代价是复杂度陡增而且在大规模部署下正确性争议一直存在。我的建议是能用数据库唯一约束解决的业务就别用 Redis 分布式锁用了就要接受它的“在极端故障下有锁丢失风险”这个前提。5.3 序列化Redis 客户端里最容易被忽视的性能瓶颈Java 用 Redis 时序列化方式直接影响你能存什么、占多少内存。最常用的两个StringRedisTemplate是纯字符串读写存 Java 对象时你得自己把对象转成 JSONRedisTemplateGenericJackson2JsonRedisSerializer可以自动把对象序列化成 JSON 存入取出来时反序列化回对象非常方便但代价是存储的内容里会带一段class类型信息占用并不大但是读出来的数据肉眼看起来也不是那么干净。序列化还有一个隐藏痛点默认的JdkSerializationRedisSerializerSpring Data Redis 默认配置如果没做任何定制是 Java 原生序列化二进制格式占用空间大而且存进去的东西你在可视化工具里完全看不懂全是\xAC\xED开头的一堆乱码。我强烈建议任何项目都显式配置 JSON 序列化方式除非你能忍受排查问题时对着乱码猜内容。Python 连接 Redis 也有类似问题用pickle序列化存进去的数据别指望redis-cli能人类可读。跨语言读写同一个 key 时一定要统一序列化方案否则等着你的就是乱码或者反序列化异常。5.4 Lua 脚本不是炫技是原子性的救命稻草Redis 的 Lua 脚本能力很多初学者不重视觉得“我是业务开发用不上 Lua”。但实际上只要你的操作需要“读当前值 - 计算 - 写回”这样的组合Lua 就是最优雅的原子性保证。前面说的分布式锁释放逻辑只是一个例子还有“限流器”INCR后判断当前计数是否超限超过则返回失败整个过程塞进 Lua 里执行就没有并发下超发的问题。Lua 在 Spring 中通常用DefaultRedisScript配合execute调用在 Python 里是redis.register_script。用 Lua 时有几个细节容易踩坑第一Lua 脚本里要访问 Redis key 必须通过KEYS[]数组传入不能写在脚本里拼字符串否则 Redis 无法预分配槽位第二脚本执行期间会阻塞 Redis千万别写死循环或者毫秒级都算慢的重计算第三脚本的“确定性”要求它不能在执行过程中读取自身的写入结果在集群模式下会直接报错所以你在集群环境用 Lua 时要特别克制尽量只对单个 key 做操作。6. 从学习到面试高频题、监控日志和排障手册6.1 高频面试题我建议你追根溯源别只背答案翻一翻网上流传的“Redis 面试题”问得最多的是这些Redis 为什么快、缓存穿透和击穿怎么解决、分布式锁怎么实现、持久化怎么选、主从和集群的脑裂问题。这些问题并不难难的是你说答案的时候有没有“现场感”。比如“Redis 为什么快”标准答案是“单线程避免上下文切换 基于 IO 多路复用的事件循环 纯内存操作”但你要是再往深走一步“单线程为什么还能这么快IO 多路复用到底是什么”很多人的回答就开始含糊了。我自己的理解是Redis 把每个连接封装成一个文件事件交给内核去监听读写事件有事件到达才触发回调处理这本质上和 Nginx 的事件驱动模型类似是把“等待 IO”这件事从线程里解放出去了。你用“餐厅只有一个服务员但门口的铃一响服务员才出去接待而不是坐在门口死等每个客人”这个类比就可以跟小白讲清楚。再比如“Kubernetes 上能不能搭 Redis”这其实是一个信号题对方想看你有没有意识到在云原生场景下Redis 这类有状态应用对网络标识Pod IP、节点名的依赖很强StatefulSet 是唯一合理的选择。如果你能说出 StatefulSet 的稳定网络标识和 Redis Cluster 的槽位分配之间是什么关系面试官对你的印象会立刻不一样。6.2 日志、监控和常见错误每一个报错都别放过排查 Redis 问题的第一步是看日志。Docker 部署的实例用docker logs 容器名Linux 直接看日志文件的路径在 redis.conf 里的logfile配置项。我最常关注的日志信息有几类Background saving terminated by signal表示 BGSAVE 失败通常和内存或文件系统有关Possible nokey和Cant persist这类表示 RDB/AOF 写入出问题要优先检查磁盘空间df -hMISCONF Redis is configured to save RDB snapshots, but its currently unable to persist on disk这个经典的只读错误就是磁盘写不进去导致的。监控指标要盯四个connected_clients连接数used_memory内存占用keyspace_hits和keyspace_misses算命中率命中率长期低于 80% 说明缓存设计有问题rdb_last_bgsave_status和aof_last_write_status持久化状态。用redis-cli INFO stats | grep keyspace可以快速查命中率用SLOWLOG GET可以看慢查询结合实际业务分析是查还是不查。可视化工具连接不上的排查路径也很有套路基本按这个顺序来第一步ping通不通第二步 telnet 6379 通不通第三步看服务端有没有设置bind 127.0.0.1很多默认配置只监听本机外部当然连不上第四步看有没有requirepass认证第五步看云厂商安全组/防火墙有没有放行 6379。八成问题都出在bind和防火墙这两项。6.3 压测、优化和一把“性能底牌”最后聊聊性能Redis 本身吞吐很高但别忽略“客户端导致的问题”。在项目中用了KEYS *这种 O(N) 命令在阻塞事件循环的同时它可能让整个 Redis 卡顿到毫秒级超时。用SMEMBERS拉取一个巨大 Set 的全部成员它会撑爆网络和内存。这些替换方案都是现成的SCAN分批遍历 keySSCAN遍历 SetLRANGE注意限制数量。养成“避免 O(N) 命令”的习惯是所有 Redis 使用者必须过的一道坎。压测工具的选择上redis-benchmark是官方自带的最简方案但它模拟不了复杂业务流量真要压真实场景用redis-cli --latency看延迟分布、用INFO commandstats看每条命令的执行次数和耗时占比比盲目压 QPS 更有参考价值。我见过很多团队“压测 QPS 达标”但线上一紧张就告警观察下来基本都是没看延迟分布、没看命令耗时导致的性能优化要看“哪个命令最慢”而不是“系统最高支持多少 QPS”。我个人在实际操作中的体会是Redis 不是一个“学完就完了”的东西它和业务形态绑定得很深。同一个命令在缓存场景、计数场景、队列场景中的语义和坑完全不一样。你学它的方式决定了你后来踩坑的多少——如果只是背命令你会觉得它很简单如果你动手搭过集群、看过日志、压过延迟、亲手修过缓存穿透你才会真的理解“高性能中间件”这几个字背后藏着多少容易被忽略的工程细节。这篇笔记是我自己踩坑过程的复盘写出来算是给后来者省点时间尤其是那些第一次在项目里引入 Redis 的朋友愿你少走几步弯路。
阅读完成 · 觉得有帮助？
