1. 为什么我在项目里优先选了 Redis 而不是其他缓存简单说Redis 是我见过的把“快”和“稳”平衡得最好的中间件。官方数据读速度能到十万级 QPS单线程模型下命令天然没有并发竞争问题数据结构又丰富String、List、Hash、Set、ZSet 直接覆盖了缓存、计数、排行榜、分布式锁这些高频场景。做 Linux 环境下的后端服务时Redis 往往是第一波被引入的组件。这个项目我只用三台 Linux 服务器就搭起了一套开发环境后来又逐步演进到主从、哨兵、集群三个层面最后产出的是一套能扛日常流量波动的企业级部署方案。整篇内容会分五个部分走先讲 Linux 环境搭建和常见坑再看数据结构底层原理然后聊持久化接着是分布式锁和缓存一致性这类硬核应用最后补上故障排查和性能调优。不管你是刚把 Redis 装好却不知道从哪下手的初学者还是已经在生产上踩过command timed out、大 key、热 key 这些坑的运维或后端开发这篇都可以给你一条相对完整的参考路径。2. Linux 环境下搭建 Redis 的完整步骤与踩坑记录2.1 为什么选 Linux 环境而不是直接用 Windows 版企业里的 Redis 绝大多数跑在 Linux 服务器上Windows 版虽然有社区维护但功能跟进慢官方文档也很少以 Windows 为主线。我见过有同事在 Windows 上本地调试没问题一部署到 Linux 生产环境就遇到maxmemory配置、文件句柄限制、内核参数等一堆差异所以趁早切到 Linux 才是正路。Linux 下装 Redis 主要有几条路线安装方式优点缺点适用场景源码编译安装完全可控版本精确需要编译依赖生产环境、定制化需求apt/yum 包管理安装快依赖自动处理版本偏旧开发测试环境Docker 容器化隔离干净环境一致性好额外维护容器层微服务、CI/CD 环境这次项目用的是源码编译因为 Redis 6.x 里的多线程 IO 能力、RESP3 协议、ACL 权限控制都是从源码级别更好理解的而且生产上我们经常需要修改编译参数做定制。2.2 源码编译安装的完整操作步骤先准备好基础依赖CentOS 系的执行yum install -y gcc gcc-c make tclUbuntu/debian 系的执行apt update apt install -y build-essential tcl然后下载指定版本源码包wget https://download.redis.io/releases/redis-6.2.14.tar.gz tar xzf redis-6.2.14.tar.gz cd redis-6.2.14编译的时候有个容易踩坑的点很多教程直接写make但如果你用的是低版本 gcc编译到一半会报zmalloc.h:50:31: fatal error: jemalloc/jemalloc.h: No such file or directory。原因是 Redis 在 Linux 下默认用 jemalloc 内存分配器但系统的头文件路径里没有它。解决办法是make MALLOClibc或者先清理再编译make distclean make我第一次做的时候傻乎乎地直接重装 gcc折腾了好久才发现是 jemalloc 的问题。所以建议在编译前直接确认gcc --version不低于 4.8然后执行make make install PREFIX/usr/local/redis安装完后redis-server --version能打印版本号说明装好了。2.3 配置文件里必须改的五个参数源码包里的redis.conf可以直接拷到数据目录我这里说几个不管在哪个环境下都要优先检查的配置因为默认值真的不适合生产。bind 0.0.0.0 port 6379 daemonize yes requirepass YourStrongPassword maxmemory 4gbbind 0.0.0.0默认只监听 127.0.0.1你远程连不上daemonize yes后台守护进程方式运行不然关闭终端 Redis 就退了requirepass不设密码等于裸奔内网也不是绝对安全的maxmemory我不建议生产环境用默认的无限内存一旦数据量上来就会触发系统 OOM设置一个合理上限配好淘汰策略才稳妥。启动方式/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf用redis-cli -a YourStrongPassword ping验证返回PONG。这里补一句经验之谈密码不要直接写在命令行参数里因为会被 shell history 记录下来。一般用redis-cli -a也会在进程列表里暴露参数生产上更推荐用REDISCLI_AUTH环境变量来管理。2.4 可视化管理工具的选择命令行用多了就会发现一些日常巡检用redis-cli很费眼睛尤其是看 key 分布和内存占用。我自己的结论是Another Redis Desktop Manager是目前跨平台最好用的开源连接工具界面干净支持 Linux 和 Windows。直连时要注意连接配置里的Use SSL默认是关闭的密码填对但连不上很可能是 SSH 隧道配置没关它会把连接当成跳板去转。生产环境我反而不建议直接用 GUI 工具因为长时间挂着连接会占用 Redis 的连接数而且有些危险操作比如FLUSHALL图形界面点起来太顺手。GUI 适合开发调试生产请尽量用命令行且限定权限。3. Redis 核心数据结构与其底层原理3.1 五种基础类型不是你想得那么“基础”几乎所有人第一天学 Redis 都会背五种数据类型String、List、Hash、Set、ZSet。但是真正到了排序、去重、范围查找这种场景你会发现底层编码方式决定了它的性能边界。Redis 对每种数据类型都做了“小数据用紧凑结构、大数据用高效结构”的优化这是它区别于普通 key-value 的地方。比如String底层可能是 int、embstr、raw 三种编码整数用 int 会直接存数值短字符串用 embstr 减少内存碎片List数据量小时用压缩列表 ziplist超过阈值后转成双向链表 linkedlist在 Redis 7 里又换成了 quicklist 的变体Hash同样先用 ziplist字段多之后转成字典 hashtableSet纯整数集合用 intset否则转成哈希表ZSet小规模用 ziplist量大之后换成跳表 skiplist。你可以用OBJECT ENCODING key来查看实际状态。我举一个具体例子redis-cli HSET user:1001 name Tom redis-cli OBJECT ENCODING user:1001 # 输出 ziplist 或 listpack视版本而定当这个 Hash 的字段数量超过配置阈值后再执行OBJECT ENCODING就会看到变成hashtable。理解这一点非常重要因为大量小 Hash 在 ziplist 编码下内存优势明显如果提前预估到数据规模可以在配置里调高 ziplist 阈值来优化内存。3.2 String、List 和 Hash 的适用场景与反例String 不只是存一个值那么简单SETNX、INCR、SETEX这些原子命令是分布式锁、计数器、限流的基础。我见过有人用 String 存 JSON 数组然后要改里面的一个字段就得把整个 JSON 读出来反序列化再写回去这种操作有严重的竞态问题正确的选择是拆成 Hash 存储。List 适合做消息队列的雏形LPUSHBRPOP是阻塞队列的极简形态。不过要注意BRPOP的超时设置和空转连接问题连接池里的连接如果长期阻塞会让服务端的连接数看着很异常。如果想省心上生产我建议直接换 Stream 或 Kafka。Hash 是 Redis 里我最喜欢的一个结构因为它天然能把对象属性拆开获取单字段非常快比如用户基础信息、商品详情缓存一个 key 一个对象比 String 序列化整包更灵活也方便做部分更新和过期管理。3.3 一组容易忽略但也很好用的高级类型Redis 5 之后引入了 Stream用于消息队列场景自带消费者组、ACK 回执、Pending 列表项目里用它做异步任务分发比 List 方案至少少写几百行逻辑。另外 BIT 相关的命令SETBIT、GETBIT、BITCOUNT在做用户签到、活跃统计时效率极高百万用户一年也就几 MB 内存。HyperLogLog 做 UV 去重统计误差在 1% 左右内存固定 12KB比 Set 省太多。我在项目里遇到过这样的对比场景运营要实时统计某活动页的 UV直接用 Set 存 userId一天下来几千万个 key 耗掉几个 GB换成PFADD之后记录同一个活动 id 下的所有用户内存占用降到 KB 级统计误差对业务来说完全可以接受。4. Redis 持久化原理与数据安全边界4.1 RDB 快照和 AOF 日志两条腿走路才稳持久化是 Redis 的“基础安全感”。默认配置会开启 RDB 快照它会 fork 子进程把内存数据写到磁盘的 dump.rdb 文件里。RDB 恢复快适合做数据备份但它有丢数据的窗口如果在上一次快照之后发生了宕机这段时间的写入就丢了。AOF 日志则记录每一次写命令类似 MySQL 的 binlog重启时重放日志来恢复数据。AOF 有三种刷盘策略appendfsync always每次写命令都刷盘最安全但性能最低appendfsync everysec每秒刷一次最多丢一秒数据性能折中生产常用appendfsync no交给操作系统决定刷盘时机性能最好但最不安全。我的取舍是生产环境两者都开。RDB 负责快速恢复和冷备AOF 负责兜底最近一秒的写入。有的团队为了极致性能只开 RDB结果零点崩了一次丢了半小时的数据这种事故不是 Redis 的责任是配置策略没想清楚。4.2 混合持久化是我比较推荐的模式Redis 4 之后引入了混合持久化将 RDB 的历史数据段和 AOF 的增量操作段合成一个文件。它解决的痛点是 AOF 文件过大导致重启重放太慢的问题重启时先加载 RDB 部分再补放少量 AOF 增量比纯 AOF 重放快得多。对应配置是aof-use-rdb-preamble yes实测下来对一个 10 GB 的数据集纯 AOF 重放可能要两分多钟混合模式可以在几十秒内完成效果很直观。4.3 这里有几个数据安全的常见误区要纠正我在排查线上问题的时候发现很多人把SAVE命令和BGSAVE混着用。SAVE是同步阻塞的大实例用SAVE会造成秒级甚至分钟级的停顿所以生产环境禁用SAVE要手动触发快照就用BGSAVE。还有个小细节AOF 重写机制BGREWRITEAOF是异步在子进程里做的但触发时机受auto-aof-rewrite-min-size和auto-aof-rewrite-percentage控制。默认 64MB 和 100% 增长比例对大多数场景来说够用但如果你的业务写多读少AOF 文件增长速度会让你频繁重写。建议根据数据增长速率调高阈值比如auto-aof-rewrite-percentage 150 auto-aof-rewrite-min-size 1gb5. 企业级应用实战分布式锁、缓存穿透与一致性5.1 Redis 分布式锁的正确实现方式分布式锁是 Redis 最经典的场景之一。它的核心原理是利用SET命令的原子性加上过期时间保证同一时刻只有一个客户端能拿到锁。网上很多旧资料还在教SETNXEXPIRE两步操作这其实有锁永远不过期的隐患如果进程在两步之间崩溃锁就变成僵尸锁了。正确写法是单条命令完成加锁与过期SET lock:order:1001 requestId NX PX 30000这里requestId必须是全局唯一的通常是 UUID 或业务流水号它在释放锁时用来校验是不是自己加的锁防止把自己的锁解掉了别人的。释放锁时不能只调DEL要用 Lua 脚本保证原子性if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 endJava 取 Redis 分享一个直接可用的实现思路用 Spring Boot Lettuce 时可以借助DefaultRedisScriptLong封装上面的 Lua 脚本。我自己在生产里直接用 Redisson 的RLock做自动续期比手写脚本更省心看门狗机制会每 10 秒自动续期 30 秒的锁生命周期避免业务超时还没执行完锁就过期的问题。这里有一个很现实的坑分布式锁的过期时间到底设多少。设短了慢业务没执行完锁就提前释放了其他线程就能进来设长了万一持有锁的线程卡死会把后续所有请求堵住。我的做法是不设固定阈值而是在业务里把耗时最长的数据库查询和远程调用统计出来锁的过期时间设置为最大值的三倍以上同时加一个续期任务兜底。5.2 彻底搞懂缓存穿透、击穿、雪崩的应对策略这三个概念在面试里是常见题目在实战里也是三种不同形态的事故。缓存穿透是查询一个不存在的 key缓存和数据库都没有请求直接打到数据库。应对策略有两个层面一是把空结果也缓存起来设置一个短过期时间比如 60 秒避免同样请求反复打 DB二是使用布隆过滤器把所有可能存在的主键加入布隆查询前先判断是否可能存在不存在直接返回。布隆过滤器有误判率但没有漏判用在小数据量时效果很好。具体在项目里的 Java 伪代码思路String cached redis.get(key); if (cached ! null) { return cached; } // 布隆过滤器判断 if (!bloomFilter.mightContain(key)) { return null; } // 缓存没命中查数据库 Object value db.query(key); redis.set(key, JSON.toJSONString(value), 300);缓存击穿是某个热点 key 过期瞬间大量请求同时去重建缓存。对应解法是互斥锁分布式锁的变体保证同时只有一个线程去查 DB其他线程等待等锁释放后直接读新缓存。另一种更优雅的思路是“逻辑过期”缓存里不设置 TTL而是存储一个过期时间戳读取时发现逻辑过期后异步重建这样不会因为缓存失效而阻塞用户请求。老手推荐逻辑过期代码写起来更简单但业务上必须接受“短暂读旧数据”的可能性。缓存雪崩是大量 key 同时过期或者 Redis 服务整体不可用造成的连锁反应。预防手段比处理手段更重要设置过期时间时加随机扰动比如基础 TTL 加 1~300 秒的随机偏移让过期压力分散开。5.3 缓存与数据库的一致性方案取舍缓存一致性是高并发系统里绕不开的难题。业界最常用的方案是 Cache Aside Pattern也就是先更新数据库再删除缓存。因为删除缓存是幂等的即使删失败也只是多一次缓存未命中不会产生脏数据。如果先删缓存再更新数据库那么在更新数据库的间隙另一个请求会读到旧数据并回填缓存导致缓存里长期存着旧值。我经历过一个线上案例用户修改头像后页面十分钟内还是旧头像排查发现是“先删缓存再更新 DB”的时序问题。后来改成“先更新 DB 再删缓存”配合延迟双删彻底解决。所谓延迟双删是删完缓存后过几百毫秒再删一次但这不是银弹还得结合业务容忍度来看。对于强一致要求我的经验是不要把宝全压在 Cache 上数据库 binlog 监听、消息队列异步刷新缓存是更稳妥的方向只是复杂度会增加不少。6. 主从、哨兵与集群的演进和选型6.1 主从复制最快搭建与原理单台 Redis 节点挂了服务就瘫这是不能接受的。主从复制是第一步一个主节点配一个或多个从节点主节点负责写操作从节点同步数据并对外提供读能力。它的原理基于PSYNC命令核心流程是从节点发送同步请求主节点在后台生成 RDB 快照并发送给从节点同时把期间的写命令记录在复制缓冲区里快照发完后继续把增量命令发给从节点。Linux 环境下手动演示也很简单从节点的配置文件里加一行replicaof 192.168.1.10 6379或者直接命令行redis-cli -p 6379 -a password replicaof 192.168.1.10 6379然后看同步状态redis-cli -p 6380 info replication输出里有role:slave和master_link_status:up就说明同步正常。我在实战里遇到的比较多的问题是从节点数据落后主节点通常网络分区或是主节点复制缓冲区太小导致全量重同步解决办法是调大repl-backlog-size默认只有 1MB业务写入频繁时很容易撑满。主从模式有一个明显短板主节点挂了之后需要人工把某个从节点提升为主节点。中间这段时间客户端会一直写失败生产上是不可接受的所以才有哨兵。6.2 Docker Compose 快速体验主从复制如果只想本地快速验证主从效果用 Docker Compose 是最省事的。下面是一个可用的配置version: 3.8 services: redis-master: image: redis:7.0 container_name: redis-master ports: - 6379:6379 command: [redis-server, --requirepass, masterpass] redis-slave: image: redis:7.0 container_name: redis-slave ports: - 6380:6379 command: [redis-server, --slaveof, redis-master, 6379, --masterauth, masterpass, --requirepass, masterpass]启动后进入 master 容器写入一个 key再到 slave 容器读取能查到说明主从通了。这个配置里两个容器挂同一个 Docker 网络服务名可以直接互相解析比配 IP 更灵活。6.3 哨兵模式怎么做到故障自动切换哨兵其实是独立于 Redis 数据处理之外的一组进程它负责监控主从节点的状态。它和 ZooKeeper 有点像多个哨兵之间通过投票决定主节点是否客观下线然后从从节点中选举出一个新主节点并把其他从节点重新指向新主。部署哨兵最少要三个节点因为需要过半数的哨兵达成一致才能判定故障。核心配置sentinel monitor mymaster 192.168.1.10 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 150002表示至少两个哨兵同意判定主节点故障才会触发切换。我实际测试中主节点 kill 掉之后哨兵大约在 7 秒左右完成切换这个时间取决于down-after-milliseconds和网络延迟。哨兵模式解决了高可用问题但还有一个局限单主节点的写能力有天花板如果你想横向扩展写性能就必须上 Redis Cluster。6.4 Redis Cluster 集群的原理与搭建途径Redis Cluster 通过哈希槽Hash Slot机制把数据分布到多个主节点上。整个集群有 16384 个哈希槽每个 key 用CRC16(key) % 16384计算属于哪个槽再由槽分配到具体节点。客户端要使用集群模式连接因为当你访问到错误的节点时它会先返回MOVED或ASK重定向指令。搭建集群建议直接用官方脚本或者用redis-cli --cluster create命令redis-cli -a password --cluster create \ 192.168.1.11:6379 192.168.1.12:6379 192.168.1.13:6379 \ 192.168.1.14:6379 192.168.1.15:6379 192.168.1.16:6379 \ --cluster-replicas 13 主 3 从是常用的最小高可用集群每个主节点带一个从节点。--cluster-replicas 1的意思是每个主节点配一个副本。集群模式下有几个和单机模式完全不同的点新手经常栽跟头MGET一次取多个 key 不再保证跨节点原子性除非这些 key 在同一个哈希槽因此项目里要用 Hash Tag 来强制归槽例如{user:1001}:profile和{user:1001}:orders用同一个user:1001作为标签不允许跨槽操作的多 key 命令比如SUNIONSTORE、RENAME大 key 在集群内迁移时会有阻塞风险因为迁移过程中涉及 key 的序列化传输。如果你的数据量还没到单机几十 GB 以上其实主从 哨兵是更简单的选择。集群是为了解决容量和写扩展的切勿为了“集群听起来高级”就上它后面运维复杂度会成倍增加。7. 常见故障排查技巧与性能调优实录7.1 连接报错command timed out的完整排查思路这个词热度很高我猜不少人被它折腾过。报错原文一般是Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException如果你用的是 Spring Boot Lettuce大概率是请求排队到超时了而不是 Redis 真的“慢”。我遇到过的真实案例是客户端的连接池太小默认空闲校验间隔过长Redis 处理能力没问题但连接全部被慢查询占满新请求等到超时才执行。排查步骤建议按下面的顺序来先看 Redis 服务端状态redis-cli INFO stats里看instantaneous_ops_per_sec和latest_fork_usec确认服务是否出现长时间 fork执行SLOWLOG GET 10查看是否有慢查询命令重点排查KEYS *、HGETALL大 Hash、SMEMBERS大 Set看客户端配置Lettuce的commandTimeout默认 10 秒connectTimeout默认 10 秒在高并发大流量下这两个时间可能不够但更关键的还是连接池和线程池的参数是否匹配检查网络延迟ping和redis-benchmark对比常规表现。我最后的解决方案是连接池最大连接数从默认的8调到了50最小空闲连接从0调到10同时把命令超时时间从 10 秒降到 3 秒——缩短超时时间听起来反直觉但它的作用是快速失败避免请求堆积让故障面更小。7.2 大 key 与热 key 的定位方法大 key 是指单个 key 的数据量过大比如一个大 Hash 几十万字段一个 Set 几百万成员。它的危害是全方位的读写耗时高占住 Redis 单线程、删除时阻塞服务、迁移时拖慢集群。定位大 key 我会用下面这些命令组合redis-cli -a password --bigkeys--bigkeys会扫描整个实例并输出每种数据类型的最大 key适合做一轮粗筛。更精细的定位可以抽样看单个 key 的STRLEN、HLEN、SCARD、ZCARD。热 key 是指流量非常集中的 key比如销量榜第一的商品、爆款文章的内容。它的问题在单线程模型下尤为突出一个热 key 就能把 Redis 的单核 CPU 打到 100%。常见手段是多级缓存本地 Caffeine Redis给热 key 减负或者把同一个 key 的内容复制到多个分片 key 上让请求均匀分摊比如goods:1001:0、goods:1001:1。我实操里比较喜欢用的热 key 检测工具是 Redis 官方的redis-cli --hotkeys但它依赖maxmemory-policy为 LRU 相关策略才会启用如果没有开启就需要在客户端侧统计访问频率。7.3 性能调优关键内核参数很多性能问题其实不是 Redis 自身的问题而是 Linux 内核参数没调好。两个最有代表性的一是transparent_hugepageRedis 官方明确建议关闭。它默认开启时内存页从 4KB 变成 2MBfork 子进程做持久化时复制页表的成本会暴增造成延迟毛刺。关闭方式echo never /sys/kernel/mm/transparent_hugepage/enabled但这是临时设置重启失效要去/etc/rc.local或 systemd 里加持久化配置。二是文件描述符限制默认ulimit -n是 1024连接数稍微一多就到瓶颈。改为ulimit -n 65535还要把 Redis 配置文件里的maxclients同步调大到30000以上并保持timeout设置为一个合理值比如 300 秒让空闲连接自动断开防止连接数虚高。7.4 运维常用的监控命令与指标这里是我现在每次排查问题都会先看的一些命令直接汇总成表命令核心指标判定经验INFO statstotal_net_input_bytes/rejected_connections拒绝连接数大于 0 基本是maxclients不够INFO memoryused_memory/mem_fragmentation_ratiofragmentation 长期大于 1.5 说明内存碎片严重考虑重启或调大内存页INFO replicationmaster_link_status、master_repl_offset主从偏移量差距持续走高说明同步延迟INFO clientsconnected_clients、blocked_clientsblocked 长期不为 0 要查 BRPOP 和分布式锁SLOWLOG GET 10耗时超过阈值的命令排查慢查询重点看是否有KEYS *内存碎片这块多说一句Redis 内存碎片率高通常不止是数据删除导致的还和maxmemory-policy的淘汰方式以及 jemalloc 的分配行为有关。我之前在一个流量波动巨大的系统里看到碎片率到 1.8最后是重启实例释放碎片但这在集群模式里涉及数据迁移风险较高要谨慎操作。8. 连招从命令行到面试题的一次系统梳理8.1 这些命令我每天都会用到几个除了教科书里的GET/SET真正干活时最常用的其实这几个SCAN cursor [MATCH pattern] [COUNT count]遍历 key 的合规姿势生产禁用KEYS *TYPE keyOBJECT ENCODING key快速判断类型和编码排查不同数据类型是否走到预期编码EXPIRE key seconds/TTL key管理过期时间INFO memory看内存和碎片率MONITOR调试阶段看实时命令流生产慎用因为会显著消耗性能。SCAN命令有个好习惯是分批遍历每批 COUNT 设成 1000 左右避免一次性返回太多造成网络阻塞。MATCH它在遍历过程中做匹配不代表返回的一定是匹配结果要客户端再过滤一次。8.2 常见面试题怎么从原理角度回答围绕 Redis 的面试题网上能搜到很多但能吸引面试官的通常是“你会带着原理去讲”Redis 为什么快纯内存操作、单线程避免上下文切换和锁竞争、IO 多路复用Linux epoll、高效的数据结构编码持久化选型RDB 与 AOF 的对比混合持久化的存在以及各自适用的数据安全等级缓存一致性Cache Aside、延迟双删、binlog 异步通知这些手段的演进以及各自的取舍分布式锁SETNX的演进史、看门狗续期、RedLock 的争议集群原理哈希槽分配、Gossip 协议、主从故障迁移流程。这些问题的考察本质是你能不能从“用工具”升级到“理解工具的内部逻辑”而这篇里的持久化、数据结构编码、集群原理正好覆盖了这些点。8.3 关于 Linux 与 Redis 的结合我自己的学习路径建议如果你是从零开始我建议按这样的顺序走装一台 Ubuntu 或 CentOS 虚拟机学习常用命令比如ls、cd、grep、tail、systemctl、crontab源码编译安装 Redis跑通redis-server和redis-cli亲手配置一遍 2.3 节里的五个参数用INFO和SLOWLOG观察 Redis 状态结合top、free、vmstat这些 Linux 命令做联动分析逐步搭建主从、哨兵、集群理解每个模式解决的问题找一个真实项目业务把分布式锁、缓存穿透防护和消息队列场景都应用一遍。Linux 的知识点比较杂但和 Redis 相关的其实就是进程管理、网络配置、内存管理、文件系统这几块。不要一开始就去啃内核先用得上再慢慢深入。我在实际排查中感触最深的一点是Redis 的大部分故障根源都不在 Redis 本身而在客户端超时参数、Linux 内核配置、连接池过小这些“外围因素”。所以建议你遇到问题先把 Redis 自身的慢查询、内存、连接数这三项查清楚再去翻应用配置顺序不要反。这个项目的完整路线延续下来我从只会ping的初学者到能独立搭建一套高可用集群并在故障中快速定位走了不少弯路希望这份踩过的坑能帮你缩短这个过程。