混过后端开发的人基本都绕不开 Redis。作为目前使用范围最广的内存数据库Redis 几乎成了互联网项目的标配缓存、分布式锁、排行榜、限流、消息队列它都能掺一脚。这篇文章我就按自己从入门到上手、再到踩坑的经历把 Redis 基础相关的核心内容完整串一遍——安装部署、数据类型、持久化策略、主从哨兵集群、可视化客户端、缓存治理、分布式锁再到 Java 项目里 RedisTemplate 最常报错的几个问题一次讲清楚。适合刚接触 Redis 的初学者也适合想系统性查漏补缺的开发者。我在早期刚接触 Redis 的时候其实走了一些弯路。一开始只会get、set后来才发现 Redis 的威力远不止缓存这么简单真正值钱的是它的数据结构、持久化机制和高可用方案。这篇文章与其说是教程不如说是我把自己这些年用 Redis 的心得整理成了一份可复用的笔记希望能帮你少踩几个坑。1. Redis 到底能干什么为什么大家都在用1.1 先从本质说起它就是一个内存里的字典用一句最直白的话来概括Redis 就是一个运行在内存里的键值对数据库。它把所有数据都放在内存里读写所以速度极快单节点轻松支撑十万级 QPS比传统关系型数据库动不动就要走磁盘 IO 快了几个数量级。但 Redis 和普通缓存组件不一样的地方在于它不止是key-value这么简单。它的 value 支持多种数据结构字符串、哈希、列表、集合、有序集合以及后面版本加的位图、HyperLogLog、地理坐标等。这让它从一个“缓存仓库”升级成了一个“数据结构服务器”你可以直接在上面完成计数、排行榜、去重、消息队列等逻辑不用再自己写一堆业务代码去拼凑。我经常跟新手打一个比方如果把 MySQL 比作一个仓库货物都整整齐齐放在货架上查询要找半天那 Redis 就是手边的工作台最常用的东西摊在台面上伸手就能拿到。仓库再大工作台也不能省。1.2 哪些场景真正适合用 Redis很多人一遇到性能问题就想到 Redis但并不是所有数据都适合放进去。按照我的实际使用经验下面这几类是最常见的缓存会话与热点数据用户登录态、验证码、首页推荐列表这类读多写少、允许短时间不一致的数据放 Redis 里能显著减轻数据库压力。计数器与限流点赞数、访问量、库存扣减Redis 的INCR、DECR是原子操作天然适合做计数滑动窗口限流也可以用ZSET 时间戳实现。排行榜ZSET的分数排序能力完全可以支撑实时榜单需求我做过一个日活十万的活动页排行榜接口用 Redis 做后 P99 延迟稳定在 5ms 以内。分布式锁多个服务实例争抢同一份资源时以 Redis 为底层实现的锁是最主流的方案之一。消息队列的轻量替代用LIST的阻塞弹出BRPOP可以实现一个简单的生产者-消费者队列虽然比不上 Kafka 这些专业消息中间件但在小规模场景下足够用。如果你只是把 Redis 当缓存值和数据库里的数据完全一致那说明你只发挥了它三成功力。理解它能承载哪些业务逻辑才算真正入了门。2. 环境搭建Windows、Linux、Docker 三条路都给你捋清楚2.1 Windows 下安装 Redis 的两种常见姿势Redis 官方其实不直接支持 Windows但开发学习阶段很多人用的都是 Windows 电脑所以社区里有移植版微软也维护过一段时间。目前最常见的做法是去 Redis 官网或者 GitHub 上的 redis-windows 项目下载免安装包解压之后直接运行redis-server.exe。我个人的建议是如果只是本地写 demo、调试代码直接下载 Windows 版绿色包就行省事但要真正部署到服务器一定用 Linux 环境别拿 Windows 版扛线上流量性能和稳定性都差点意思。还有一个更干净的方式就是通过 WSL 在 Windows 里跑 Linux 子系统然后按 Linux 的方式安装编译 Redis。这个方案对 Windows 用户来说比绿色包更贴近生产环境缺点是需要额外装一层 WSL小项目图省事的话没必要。无论你选哪种方式启动 Redis 后都要注意默认端口是 6379默认没有密码。开发环境无所谓但如果你的 Redis 网络可达公网后面第七章我会专门讲安全加固这一步非常关键。2.2 Linux 下编译安装 Redis 7.0生产环境我一般都是用编译安装的方式部署 Redis这样版本可控、参数可调也方便后续升级。以目前使用较多的 Redis 7.0 系列为例步骤很简单# 安装编译依赖 yum install -y gcc make tcl # 下载源码包并解压 wget https://download.redis.io/releases/redis-7.0.12.tar.gz tar -zxvf redis-7.0.12.tar.gz cd redis-7.0.12 # 编译安装 make make install编译完成后redis-server、redis-cli这些可执行文件会被安装到/usr/local/bin下直接用就行。接下来是配置文件Redis 根目录下自带一份redis.conf我的习惯是单独复制一份到/etc/redis/下面再改mkdir -p /etc/redis cp redis.conf /etc/redis/redis.conf然后修改这几个核心参数# 让 Redis 在后台运行 daemonize yes # 设置访问密码生产环境必配 requirepass 你的强密码 # 允许访问的网段默认只允许本机 bind 0.0.0.0 # 日志文件路径 logfile /var/log/redis/redis.log改完后启动redis-server /etc/redis/redis.conf用redis-cli ping试一下返回PONG就说明服务起来了。2.3 Docker 跑 Redis镜像方式为什么更省心如果服务器上已经装了 Docker我更推荐直接以容器方式运行 Redis尤其是做集群或主从实验时容器的好处立竿见影环境隔离、扩展方便、起停秒级完成。# 拉取官方镜像 docker pull redis:7.0 # 启动一个带密码的 Redis 容器 docker run -d --name redis-dev \ -p 6379:6379 \ -v /data/redis:/data \ redis:7.0 \ redis-server --appendonly yes --requirepass 你的密码这里我习惯把数据目录挂载出来防止容器重建后数据丢失。跑主从也很简单再起一个容器通过--slaveof或者配置文件中指定主节点地址即可docker run -d --name redis-slave \ -p 6380:6379 \ redis:7.0 \ redis-server --slaveof 172.17.0.2 6379 --requirepass 你的密码Docker 方式最大的价值是适合练手和测试比如我要验证主从切换、哨兵故障转移一般直接在本机拉三个容器模拟比找三台服务器方便太多。3. 五大数据类型实操从命令到场景全搞懂Redis 的类型是最值得花时间弄明白的基础知识面试必问日常开发也离不开。我按使用频率逐个说。3.1 String最基础也最常用的类型String 是 Redis 里最简单的类型value 可以是一个字符串、整数或者浮点数最大能存 512MB。常用命令包括SET、GET、SETNX、INCR、DECR、EXPIRE。核心用法我在项目里最常用的是# 设置键值对并带上过期时间缓存中最常用 SET user:1001 {name:tom,age:18} EX 300 # 只有键不存在时才设置分布式锁和防重复提交都靠它 SETNX lock:order:10001 1 # 原子自增点赞计数、库存扣减就是它 INCR article:view:9527特别注意INCR操作是原子的。哪怕有十个并发请求同时执行Redis 也会按顺序一个个加不会出现丢掉更新的问题。这就是为什么很多计数场景宁愿用 Redis 也不用数据库的行锁。3.2 Hash、List、Set、Zset 各自的地盘Hash适合存对象本身。比如用户信息有多个字段用 String 整个序列化虽然简单但要改其中某个字段就得整个覆盖Hash 却能单独操作一个字段HSET user:1001 name tom age 18 HGET user:1001 name HINCRBY user:1001 age 1List底层是链表适合做消息队列或最新列表。LPUSH从左边推入BRPOP阻塞地弹出右侧元素天然就是一个生产者消费者模型。做简单的站内信、异步通知队列完全够用。Set是无序去重集合适合做标签系统、好友关系、抽奖去重。比如两个集合的交并差运算直接用SINTERSTORE一行命令搞定不用在代码里写循环。Zset是最复杂也最强的一种类型每个成员带一个分数。排行榜、延迟队列、滑动窗口限流都靠它# 给用户增加积分 ZINCRBY rank:game:2024 10 user_888 # 取前 10 名 ZREVRANGE rank:game:2024 0 9 WITHSCORES3.3 序列化问题为什么存进去的是对象读出来是乱码这是新手最容易懵的地方。Redis 本身只能存字符串和二进制数据Java 里一个User对象要存进去必须先转成字节数组或 JSON 字符串这个过程就是序列化。常见的序列化方案有 JdkSerializationRedisSerializer默认、Jackson2JsonRedisSerializer、FastJson2RedisSerializer、Gson 等。我遇到很多同学说“我用 StringRedisTemplate 存进去的是 JSON但用 RedisTemplate 读出来带一串前缀乱码”。这其实是模板默认的序列化器不同导致的StringRedisTemplate 直接用字符串RedisTemplate 默认用 JDK 序列化在 key 或 value 前会带二进制类型描述符。解决办法是统一两者的序列化器最简单的做法是设置 RedisTemplate 的 key 和 hash key 用 StringRedisSerializervalue 用 Jackson 或 Gson。具体配置我在第八章会给出完整代码。4. 持久化不能只开默认RDB 和 AOF 得这么配Redis 是内存数据库如果只跑在内存里进程一挂数据就全没了。所以持久化是高可用和灾备的基石。Redis 提供了两种持久化方式RDB 快照和 AOF 日志。4.1 RDB 快照是怎么回事RDB 是 Redis 默认开启的持久化方式简单说就是每隔一段时间把内存里的全量数据生成一个二进制快照文件 dump.rdb 写到磁盘上。触发时机由配置文件里的save决定save 900 1 # 900 秒内至少改 1 个键则触发 save 300 10 # 300 秒内至少改 10 个键则触发 save 60 10000 # 60 秒内至少改 10000 个键则触发RDB 的特点是文件紧凑、恢复快非常适合做全量备份和灾难恢复。但缺点也明显就是可能丢失最后一次快照之后写入的数据。如果业务对数据丢失非常敏感光靠 RDB 肯定不够。4.2 AOF 日志与重写机制AOF 记录的是每一条写命令以追加的方式写入日志文件。相当于把每次操作都记下来重启时重放这些命令来恢复数据。和 RDB 相比AOF 的数据安全性更高可以做到最多丢失一秒的数据。AOF 有三种同步策略配置项含义数据安全性appendfsync always每写一条命令就同步磁盘极高性能最低appendfsync everysec每秒同步一次较高推荐appendfsync no交给操作系统决定何时同步最低性能最好开启方式是在配置文件中加一行appendonly yes appendfilename appendonly.aof appendfsync everysec随着运行时间变长AOF 文件会越来越大所以 Redis 提供了 AOF 重写机制通过bgrewriteaof命令或自动触发条件把历史命令压缩成最小集。7.0 版本把 AOF 拆成了基础文件和增量文件重写时不会阻塞主进程整体更稳定。4.3 实际项目中怎么选我的判断标准很简单能接受分钟级丢失、追求恢复速度、对磁盘占用敏感的用 RDB 足够数据不能丢、能接受一定性能开销的用 AOF生产环境我一般两者都开RDB 负责快速恢复和全量备份AOF 负责补全最近一秒的增量。还有一个容易忽略的点无论哪种持久化都只解决宕机恢复的问题解决不了误操作问题。比如线上执行了一个FLUSHALL持久化文件里照样把这个命令记下来了恢复完数据还是没了。所以运维上必须配合定期备份异地保存我处理过的几次事故都是靠“前一天凌晨的 RDB 备份”救回来的。5. 主从、哨兵、集群从单机到高可用的路单机 Redis 再快也有上限而且一旦挂掉所有依赖它的服务都会断。所以到了生产阶段怎么把 Redis 从单点变成高可用集群是必须掌握的进阶内容。5.1 主从复制Docker 一条命令就能玩主从复制是最基础的高可用形态。一个主节点负责写多个从节点同步数据并负责读既实现了读写分离又给数据加了一层副本。配置方式特别简单从节点加上一行即可replicaof 主节点IP 6379从节点默认是只读的所有写操作必须打到主节点上。主从同步的核心机制是第一次全量同步之后增量同步。主节点会把写命令放到一个叫 repl_backlog 的缓冲区里从节点消费如果从节点断开太久、缓冲区被覆盖了就会退化成全量同步这也是主从架构里最需要监控的点。我测试主从时喜欢用 Docker原因很简单一条命令起一个节点要模拟断网就docker stop要测新增从节点就再docker run一个非常方便。5.2 哨兵模式是怎么做到自动故障转移的主从复制本身不会自动切换主节点挂了从节点依然只读整个系统就瘫痪了。哨兵Sentinel就是来解决这个问题的它负责监控主从节点的健康状态一旦主节点不可用就在从节点里选一个提升为新主节点并通知客户端新的主节点地址。哨兵本身也需要部署多个节点一般至少三个防止哨兵自己成为单点。它的投票选主机制比较有意思哨兵发现主节点疑似挂掉后会发起投票达到法定数量后才判断主节点真正宕机然后在从节点中按照优先级、复制偏移量等因素选出新主节点。这个机制面试里常被问到核心就是几个问题怎么判断宕机、怎么选新主、客户端怎么感知。真正上手配一遍哨兵后这些问题基本就都通了。5.3 集群模式解决更大规模的数据存储主从和哨兵解决了高可用但解决不了容量问题。如果数据量超过单机内存就需要用 Redis Cluster。集群把数据按哈希槽16384 个槽分散到多个主节点上每个主节点还可以配从节点进行高可用保护。客户端访问某个 key 时会通过CRC16(key) % 16384计算出槽位然后定位到对应的节点。如果请求发到了错误的节点Redis 会返回MOVED重定向指令由客户端重新请求正确节点。所以集群并不支持跨节点多 key 事务这一点在设计 key 时要提前规划好尽量让相关操作的 key 落在同一节点上或使用 hash tag 来控制槽位分布。集群搭建比主从复杂一些建议先用 Redis 官方提供的redis-cli --cluster create命令在一台机器上模拟把通信机制搞懂后再上多机环境。6. 可视化客户端和连接工具怎么选6.1 Redis Desktop Manager 还是 Redis 官方推荐很多新人一上来就用命令行结果看到十几条命令就懵了。可视化客户端确实能帮你直观看到数据结构和 key 分布降低上手门槛。目前社区里主流的工具就那几个曾经最出名的是 Redis Desktop Manager简称 RDM但新版越来越“商业化”免费版功能受限好多人在找替代品。后来我转向了 Another Redis Desktop ManagerARDM开源、跨平台、免费界面和功能都不输 RDM还能直接查看 JSON 格式化后的 value、执行命令、按前缀筛选 key日常开发完全够用。命令行工具redis-cli也要会用因为服务器上没法总是装图形界面排查问题基本靠它。6.2 连接配置里的几个关键细节用可视化工具连接 Redis 时有几个细节特别容易踩坑云服务器上的 Redis 无法连接先确认是否开启了公网访问再检查防火墙和安全组是否放行 6379 端口还要确认配置文件里bind是否允许对应网段访问。密码认证问题工具提示NOAUTH Authentication required说明服务端设置了密码连接配置里必须填上requirepass中设置的密码。保护模式Redis 默认开启了protected-mode yes当没有设置密码且绑定了公网地址时Redis 会拒绝连接。本地测试建议先设置密码别去关保护模式。6.3 排查 Redis 连接问题的一般思路如果出现连不上的情况我一般按这个顺序排查确认进程是否在运行ps -ef | grep redis确认端口是否监听ss -tnlp | grep 6379确认客户端网络是否通telnet 服务器IP 6379确认是否触发认证执行redis-cli -a 密码 ping确认 Redis 日志日志文件是最直接的排错入口看有没有Bind失败、拒绝连接等关键字很多问题其实都不是 Redis 本身挂了而是网络和防火墙层面的原因。别一上来就重启服务先把这些基础项排查完。7. 缓存治理与分布式锁面试常考、实战常用的核心玩法7.1 缓存穿透、击穿、雪崩到底是什么这几个概念面试基本必问实际生产也经常遇到值得一次说清楚。缓存穿透请求查询的数据在缓存和数据库中都不存在导致每次请求都直接打到数据库上。这等于缓存失效了数据库压力会暴涨。解决方法有缓存空值即使查不到也缓存一个 null设置较短过期时间和使用布隆过滤器先过滤掉一定不存在的 key。缓存击穿某个热点 key 在缓存过期的瞬间大量请求同时穿透到数据库把数据库打爆。解决思路是热点数据不设置过期时间或者用互斥锁保证只有一个请求去回源数据库其他请求等待缓存重建完成。缓存雪崩大量 key 在同一时间到期或者整个缓存节点宕机导致请求全部打到数据库。针对大量 key 同时过期的问题可以在设置过期时间时加一个随机值来打散针对节点宕机问题就要用主从哨兵/集群架构来保证高可用。这三种情况名称很接近我记口诀的方式是穿透是“查了个不存在的数据”击穿是“一个热点 key 突然失效”雪崩是“大量 key 同时失效或节点挂了”。7.2 手写一个靠谱的 Redis 分布式锁分布式锁是微服务场景下的高频需求。用 Redis 实现分布式锁的核心命令是SET key value NX EX 过期时间SET lock:order:10001 token_abc NX EX 10NX保证只有在 key 不存在时才设置成功EX设置过期时间防止进程持有锁后崩溃导致死锁。加锁成功即拿到锁用完再删除if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end注意释放锁时必须校验 value 是自己设置的标识否则可能把别人刚获取到的锁误删掉。这段逻辑一般用 Lua 脚本实现保证判断和删除是原子操作。这里我要特别提醒一点如果追求极端可靠性单机 Redis 实现的分布式锁在节点故障时依然有风险比如主节点刚写入锁还没同步到从节点就挂了从节点顶上后另一个线程又加锁成功锁就“失效”了。生产级场景建议用 Redisson 库它默认实现了 RedLock 相关的增强逻辑能规避大部分问题。7.3 未授权访问漏洞安全配置一定要做Redis 默认无密码、绑定0.0.0.0一旦暴露到公网极容易被陌生人扫描并写入恶意数据甚至可能通过备份文件的方式被进一步利用。这类漏洞还经常出现在各类安全报告中主要原因不是 Redis 本身不安全而是部署人员没有配置访问控制。想要避免 Redis 成为突破口这四步一定要做设置强密码requirepass配置项开启认证限制访问来源bind只允许内网 IP 访问公网不要暴露关闭危险命令通过rename-command把FLUSHALL、FLUSHDB、KEYS等危险命令改名或禁用开启保护模式protected-mode yes保持默认开启。我在真实项目中见过一次线上 Redis 被入侵后被人写了定时任务挖矿CPU 直接打满。事后复盘就是绑定了公网地址且没设密码教训非常深刻。安全配置不是可选项是必选项。8. Java 项目中的 Redis 实操RedisTemplate 高频报错排查8.1 increment() 报 “not integer or out of range” 的原因这是很多人都会踩的一个坑。比如往 Redis 里存了一个值然后又用increment()给它加一结果报错ERR value is not an integer or out of range问题几乎都出在这个 key 的 value 不是整数格式。比如 value 是字符串abc或者之前用 JSON 序列化写成10带引号甚至是对象序列化后的一串二进制字节。INCR命令要求值必须能被解析成 64 位有符号整数否则就会报这个错。我自己的排查习惯是先redis-cli连上去用GET看一下这个 key 的真实值GET counter:order:10001如果是10这种明显带着 JSON 双引号的值那问题就清楚了写入时用了 JSON 序列化读取后用increment()自然失败。解决方案通常有两个要么在写入计数器时用整型直接写不要经过 JSON 序列化要么使用 StringRedisTemplate 操作计数器它默认不会做额外的类型包装更符合INCR的使用场景。还有一个隐含问题是 set 的时候用了带过期时间的方法值已经过期没了重新写入时又被序列化成字符串然后紧接着increment()失败。这种情况要检查业务代码里写入和自增是否用了同一个模板序列化配置是否一致。8.2 RedisTemplate 序列化配置我在项目里维护了一个通用的 RedisConfig核心就是自定义 RedisTemplate 的序列化方式Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); // 使用 GenericJackson2JsonRedisSerializer 处理 value GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); // key 和 hash key 使用 String 序列化方便可读 StringRedisSerializer stringSerializer new StringRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }这个配置的好处是 key 在可视化工具里读起来正常value 是 JSON 字符串日志和排查都很直观。注意GenericJackson2JsonRedisSerializer会往 JSON 里写入class类型信息这样才能在反序列化时正确还原对象代价是存的数据稍微多一点。如果你只想存 String 类型最简单的做法是直接用StringRedisTemplate它的 key 和 value 都是 String没有序列化歧义最省心。8.3 Java 使用 Redis 高频问题速查表报错/现象常见原因解决办法connection refused网络不通、端口未监听、防火墙拦截按 6.3 顺序排查NOAUTH Authentication required服务端设置了密码客户端未携带连接配置补上密码value is not an integer值的格式不是整数检查写入时的序列化方式数据乱码key/value 序列化器不一致统一使用 String 和 JSON 序列化缓存和数据库不一致没有做好更新策略采用 Cache Aside Pattern先更新库再删缓存内存暴涨key 没设过期时间或过期键清理不及时排查大 key、加过期时间、合理配置 maxmemory-policy8.4 一条命令实现库存扣减顺带分享一个我在秒杀场景里常用的 Java 写法。用increment(-1)做库存扣减不仅能保证原子性还能防止超卖// 库存扣减返回值小于 0 说明库存不足 Long stock stringRedisTemplate.opsForValue().increment(stock:sku:10001, -1); if (stock null || stock 0) { // 扣减失败回补库存 stringRedisTemplate.opsForValue().increment(stock:sku:10001, 1); throw new RuntimeException(库存不足); }扣减和回补都是原子操作逻辑简单性能也高。不过要注意这个方案要求库存数值不能被 JSON 序列化成字符串纯 Integer 存进去走同一条模板才不会踩 8.1 里说的坑。9. 常见问题与排查技巧实录9.1 Redis 启动失败日志怎么定位启动失败最典型的是日志里有Cant open the log file或Cant open the append only file一般是日志目录或持久化文件目录的权限问题。还有一种是端口被占用了错误信息会明确提示Address already in use。我的排查习惯是先看配置文件里的 logfile 路径把日志打开再启动一次。只要日志能正常输出绝大多数启动失败的问题都能直接定位到redis-server /etc/redis/redis.conf tail -f /var/log/redis/redis.log还有一个容易踩的坑是配置文件里有隐藏字符比如在 Windows 下编辑过 conf 文件再传到 Linux多了\r回车符Redis 解析配置时会报语法错误。解决办法是用sed -i s/\r$// redis.conf清理一下。9.2 Key 没设置过期时间内存越涨越高怎么办公司里遇到过几次线上事故最后追溯都是业务代码写 key 时忘了设置过期时间Redis 内存被缓慢打满。定位方法是按 key 前缀或类型统计redis-cli --bigkeys这个命令会扫描所有 key按大小列出大 key能快速找出异常数据。如果确认是某些 key 被无脑写入处理方式分两步业务代码里补上EXPIRE设置过期时间线上可以先通过SCANEXPIRE批量修复注意不要用KEYS *那会阻塞 Redis 主进程生产环境非常危险。9.3 Redis 响应变慢通常不是 Redis 的问题很多人一遇到 Redis 慢就想着加内存、加配置其实大多数情况问题出在客户端或业务侧。常见的慢原因有使用KEYS *扫描大量 key主线程被阻塞存了大 value比如一个几 MB 的字符串读写耗时明显上升频繁建立连接没有使用连接池网络握手开销拉低了吞吐慢查询日志没开问题无迹可寻。排查慢操作首先开慢查询日志slowlog-log-slower-than 10000 slowlog-max-len 128然后重启 Redis或执行CONFIG SET动态开启再用SLOWLOG GET查看最近执行的慢命令。定位到具体命令后再对应优化。这个方法比我盲目调参有效十倍。在排查过几轮线上问题之后我最大的感受是Redis 本身够稳定真正带来麻烦的往往是使用姿势。序列化配置不一致、过期时间没设置、没加连接池、大 key 不清理这些都是非常隐蔽的“慢性病”。把基础吃透把配置做规范再把排查思路理顺Redis 这个工具用起来会顺手非常多。最后再分享一个小技巧每次上线前检查一遍 config 文件里有没有把maxmemory、maxmemory-policy、appendonly、requirepass这几项统一配置好很多夜间告警就能提前避免。