说个真实经历。早些年我维护的一台 CentOS 7 机器，生产环境突然要上 Redis，当时图省事直接源码编译，结果 gcc 版本太低，make 报错搞了一下午，最后还因为编译参数漏了 jemalloc，上线半个月就开始出现延迟抖动。后来又新开了一台 Linux 机器，我老老实实走 yum 安装，从配 yum 源到服务跑起来，十五分钟不到就完事。这篇文章就从“yum 安装 redis”这件事说起，把为什么选 yum、yum 源怎么配、装完以后 systemd 怎么托管、配置文件动了哪些参数、会踩到哪些坑，以及装完必然后续会用到的数据类型、可视化工具、缓存治理思路，全部过一遍。
即便 CentOS 系已经改朝换代，这套思路对 Rocky Linux、AlmaLinux、openEuler 这些同样是 RPM 系的系统依然适用，无非是仓库地址和镜像源换个版本号而已。
1. 为什么选 yum 装 Redis，先把思路捋清楚
1.1 编译安装和 yum 安装，差别远不止时间
很多人一提到装 Redis 就默认“源码编译最稳”，因为网上教程十篇有八篇都是让你下载 tar.gz，然后 make && make install。这个想法不能说错，但对大多数使用场景来说，属于自己给自己找活干。
编译安装的本质是用源码在目标机器上构建一个独立的二进制体系。优点是想编译什么版本就编译什么版本，想带什么特性就带什么特性，比如你需要启用 Lua 模块、需要绑定特定的 jemalloc 版本、需要编译成调试模式，这些都是 yum 给不了的。但代价也很明显：你需要完整的编译工具链、需要解决依赖关系、需要自己处理 systemd 脚本和日志路径、需要手动指定安装目录，后面升级维护全部要靠手。
yum 安装的本质则是直接使用社区打好的 RPM 包，把二进制、配置文件、启动脚本、目录结构都按发行版的规范放到标准位置。你不需要关心编译器，不需要纠结依赖，一条命令装完，系统已经替你把方方面面都安排好了。这在多台机器批量部署的时候尤其舒服，因为每台机器装出来的路径、配置、启动方式完全一样，后期出问题也好排查，省掉一堆“为什么我那台机器找不到 redis-cli”的破事。
我见过太多新人栽在编译安装上。最常见的是 CentOS 7 自带 gcc 版本太老，Redis 新版源码需要更高的 C 标准支持，报错一个接一个。还有人在 make 时漏掉 MALLOC=jemalloc，导致内存分配策略不对，表面看跑得挺正常，遇到高并发就开始莫名其妙地卡。这些坑不是说解决不了，而是完全没必要自己跳一次。
1.2 yum 装 Redis 适合谁，哪些场景要绕道
先给结论：开发环境、测试环境、内部系统、中小规模服务，以及大多数以缓存为核心用途的场景，yum 安装完全够用。特别是当你用的系统本身就是 CentOS、Rocky、Alma、openEuler 这类 RPM 系，服务端包管理就是 yum/dnf，那用 yum 安装 Redis 是最符合系统生态的选择，升级卸载都走一套管理体系，不会留下乱七八糟的残留文件。
但有些场景我会建议你直接绕开 yum。
第一，你需要特定版本去做复现研究，比如线上用的是 7.0.14，你要在本地起一个一模一样的环境。这时候 rpm 源里的版本不一定正好对得上，与其跟仓库较劲，不如直接用官方 tarball 或者容器镜像。
第二，你要做大规模集群、主从、哨兵架构，而且对内核参数、编译优化、内存分配策略有严格要求，那 yum 装的“通用版”可能就不是最优解。这种场景我通常建议用 Docker 部署官方镜像，或者干脆源码编译定制版，包管理工具的便利性在这里反而变成了限制。
第三，极端追求性能的人。RPM 包的编译参数是发行版维护者定的，不一定针对你的 CPU 做了指令集优化。如果你跑的是计算密集型的 Redis 场景，基准测试跟编译版对比有明显差距，那就别嫌麻烦，老老实实编译。
yum 装 Redis 的真正价值在于“快速得到一个标准、干净、可维护的服务实例”。它不负责解决性能天花板，也不负责满足你的版本洁癖，它只负责让你从 0 到 1 这个环节不浪费时间。
2. 环境准备与 yum 源配置，最容易翻车的两步
2.1 动手之前，先摸清系统底细
我每次到一台新机器装东西，第一件事永远是确认系统版本和架构，而不是急着敲安装命令。很多人觉得这步多余，结果就是yum install redis的时候找不到包，或者能找到包但版本老得离谱，最后一脸懵。
操作很简单：
cat /etc/os-release uname -m yum repolist enabledcat /etc/os-release能告诉你系统是哪个发行版、哪个版本。不同版本的仓库地址差异会直接影响后续步骤。我遇到过 CentOS 7 和 CentOS 8 的机器，仓库配置文件名完全不同，照抄网上的配置几乎必挂。uname -m确认架构，现在大多数是 x86_64，但也有不少 aarch64 的 ARM 机器，尤其是国内政企和云厂商服务器，ARM 占比越来越高。如果你把 x86 的 rpm 地址硬塞给 ARM 机器，yum 会直接报架构不匹配。
我在 ARM64 机器上装 Redis 的经验是：优先找该发行版为 aarch64 构建的仓库，EPEL 和 Remi 这两个仓库在 ARM 上都有对应的包，但你需要确认自己的 release 版本号有没有打错。CentOS 7 的 aarch64 安装 EPEL 用的是同一个 rpm，但仓库内的包是否齐全还是要靠yum list实测。
yum repolist enabled这步能让你看到当前启用了哪些仓库。默认情况下 CentOS 的 base、extras、updates 仓库里通常没有 redis 这个包，或者只有很老的版本。你要做的就是确认这一点，然后决定要不要加新仓库。
2.2 把 EPEL 和 Remi 仓库加进来，别用错了包
Redis 在 RHEL 系默认仓库里常年处于“半缺席”状态，系统自带源里要么没有，要么版本老到没法看。这时候实操层面最常用的两个源是 EPEL 和 Remi。
EPEL 是 Extra Packages for Enterprise Linux，由 Fedora 社区维护，里面打包了大量企业 Linux 常用的软件，Redis 也有，但版本通常不算最新。Remi 仓库是个人开发者维护的 RPM 仓库，特点是非常勤快，很多软件都能第一时间更新到新版本，包括 PHP、Redis、Nginx 这些常用组件。我装 Redis 的默认套路是：EPEL 作为基础，Remi 作为版本升级通道。
配置 EPEL 很简单：
yum install -y epel-release它会帮你注册一个 epel.repo 文件。配置 Remi 需要下载对应系统版本的 rpm 安装包：
# CentOS/RHEL 7 yum install -y http://rpms.remirepo.net/enterprise/remi-release-7.rpm # CentOS/RHEL 8 yum install -y http://rpms.remirepo.net/enterprise/remi-release-8.rpm # Rocky/Alma 等发行版也可以用对应版本的 remi-release，具体情况看 Remi 官网装完以后，/etc/yum.repos.d/目录下会多出remi.repo、remi-safe.repo等文件。你不需要把它们全部启用，用的时候通过--enablerepo单独指定就行。这样可以避免 Remi 仓库里的其他软件包（比如 PHP、MySQL）把系统现有的依赖关系搅乱。
我踩过的坑是：有些人在配置 Remi 时直接修改整个仓库的enabled=1，结果 yum update 的时候把系统里一大批软件升级成了 Remi 版本，最后跟系统自带库的依赖冲突，一升级就崩。教训就是：第三方源平时保持 disabled 状态，需要哪个包用哪个包，这才是正确打开方式。
2.3 验证 yum 源到底通不通，别装到一半后悔
配置完仓库后，先跑两条命令确认源是否真的可用：
yum repolist enabled | grep -iE "epel|remi" yum --enablerepo=remi info redis第一条看仓库有没有被识别到，第二条直接查询 redis 在 Remi 源里的具体信息，包括版本号、大小、来源。如果第二条能正常输出，说明源通了，后面安装就是水到渠成的事。
在这里我特别提醒一下 GPG 密钥的问题。新装的第三方源在第一次使用时会要求导入 GPG 密钥，这样做的目的是验证 rpm 包确实来自对应的维护者，防止被篡改。如果系统弹出一个确认提示，直接选 yes 导入即可。有些教程会教你--nogpgcheck跳过校验，我不建议这么干，尤其在生产环境上。跳过校验等于把服务器安全交给别人，真出事的时候后悔都来不及。
另外一个高频问题是源地址不稳定。国内访问默认的 Remi 仓库地址有时会很慢甚至超时，这很正常，解决办法是把它替换成国内镜像源。比如把rpms.remirepo.net替换成国内的镜像域名，手法跟替换 CentOS 基础源是一样的。我一般会在/etc/yum.repos.d/remi.repo里把baseurl改成镜像地址，然后跑yum clean all && yum makecache重建缓存。注意别把 release 版本号写错，比如 7 系机器写 8 的路径，那直接就是 404。
3. 从安装到运行，一条龙实操记录
3.1 执行安装命令的正确姿势，省得后面再折腾
仓库配好以后，安装 Redis 的命令非常简单：
yum install -y redis --enablerepo=remi-y表示自动确认，避免中途停下来问你是否安装。--enablerepo=remi表示只从 Remi 仓库安装，防止 yum 在多个仓库之间摇摆不定选到旧版本。如果你的机器上 EPEL 里的版本已经足够你用，那直接yum install -y redis也能装，只不过版本会偏低。我给大多数内部项目用 Remi，因为稳定性和性能方面的改进在新版本里积累得更多。
装完以后先别急着启动,做两个验证：
rpm -qa | grep redis redis-server --version redis-cli --versionrpm -qa确认系统里确实多了 redis 相关的 rpm 包，redis-server --version能直接看到你装的是哪个版本。很多运维事故都是装完后才发现版本跟预期不一样，这一步能帮你提前校准预期。
这里要说一个细节：yum 安装 Redis 后，可执行文件、配置、数据目录是分开的。默认安装后：
- 可执行文件：
/usr/bin/redis-server、/usr/bin/redis-cli - 主配置文件：
/etc/redis.conf - 数据目录：
/var/lib/redis - 日志目录：
/var/log/redis/
这些路径跟编译安装默认的位置不一样，特别是如果你之前用过编译版，习惯性地去/usr/local/redis找配置，那肯定扑空。用 yum 装的好处恰恰就在这里，所有文件都规规矩矩躺在系统标准位置，管理起来特别顺手。
3.2 用 systemd 把 Redis 管起来，别再用裸进程
CentOS 7 以后的操作系统统一用 systemd 管理服务。yum 安装 Redis 时会自动帮你生成 systemd 单元文件，这意味着你可以用一套标准命令来控制 Redis 的启停和自启动。
systemctl enable --now redis这条命令一次性完成“设置开机自启”和“立即启动”两个动作。启动后看状态：
systemctl status redis如果一切正常，你会看到active (running)的状态，以及主进程 PID。这个过程里最常见的问题是用户不知道配置文件里有个daemonize参数。如果你手动把daemonize yes改了，systemd 就会判定服务没有准确运行，因为 Redis 进程提前进入后台，systemd 监控的前台进程反而退出了。
具体扯到哪里：systemd 希望服务以前台进程的方式运行，这样它才能准确监控存活状态。yum 包默认的配置文件里通常已经写好了合适的值，但如果你是从旧系统迁移配置，一定要检查daemonize的值，不要让 Redis 自己 fork 到后台。正确做法是让 systemd 管理进程生命周期，保持daemonize no，重启后你就不会再犯这个错了。
启动 Redis 后，你会看到日志文件/var/log/redis/redis.log和 systemd 日志同步存在。想看实时日志的话：
journalctl -u redis -f tail -f /var/log/redis/redis.log日志是非常重要的排障依据，对 Redis 不熟悉的人最容易忽略掉它。我之前排查过一次 Redis 频繁重启的问题，最后就是靠日志里反复出现的Can't save in background: fork: Cannot allocate memory定位到虚拟内存设置过小，根本不是程序问题。
3.3 配置文件里的几个关键参数，动手前必须弄懂
/etc/redis.conf是 Redis 的主战场，绝大多数运行时行为都能在这里控制。我不建议一上来就全盘照抄网上的“优化配置”，因为每台机器的内存、CPU、业务场景都不一样。我根据自己的经验挑几个最关键的参数拆开说。
bind 127.0.0.1 ::1 protected-mode yes port 6379这三个参数组合起来定义了 Redis 的“门禁”。默认情况下 bind 只允许本机访问，protected-mode 保护模式开着，这其实是安全姿势。如果业务需要让其他机器连上来，那就得把 bind 改成实际的内网 IP，或者干脆设成0.0.0.0，同时设置防火墙规则，别把 6379 端口裸奔到公网。
requirepass yourpassword这是 Redis 的密码设置。默认没密码的时候，任何能连上端口的客户端都能直接读写，极其危险。我见过不少公网服务器因为 Redis 没设密码被黑客用来挖矿的案例，原因就是默认端口开着、没密码、还能远程访问。设了 requirepass 之后，所有客户端操作都要先 AUTH，包括redis-cli也要用-a参数携带密码。这里提醒一句，命令行带密码会留在 shell 历史里，生产环境建议用REDISCLI_AUTH环境变量，或者直接进配置里改。
maxmemory 256mb maxmemory-policy allkeys-lru这两项决定 Redis 作为缓存的内存上限和超出后的淘汰策略。Redis 是内存数据库，不设 maxmemory 就等于任由它吃光整台服务器的内存。allkeys-lru表示用 LRU 算法淘汰最近最少使用的 key，这是缓存场景最常用的策略。如果你的 Redis 里有需要永久保存的数据，记得改用volatile-lru，它只淘汰设置了过期时间的 key，能保护那些需要常驻的内容。
appendonly yes appendfsync everysec这是持久化相关的配置。appendonly yes 开启 AOF 持久化，appendfsync everysec 表示每秒刷一次磁盘。这个配置组合能保证即使服务器宕机，最多损失一秒内的数据，对大多数业务来说性价比最高。你要是不开持久化，Redis 重启后所有数据全部消失，那就真的只是个纯缓存了。
3.4 用 redis-cli 确认服务真的在干活，顺手做个性能摸底
服务起来以后，用自带的客户端验证一下：
redis-cli ping redis-cli set hello world redis-cli get helloping返回 PONG 说明服务活着；set/get能正常读写说明流程通了。如果设了密码，写法要加-a参数：
redis-cli -a yourpassword --no-auth-warning ping--no-auth-warning是用来屏蔽掉“Using a password with '-a' option is insecure”这句警告的，不然每次操作都会刷一行刺眼的提示，纯噪音。
再进一步，可以用redis-cli info看一眼服务实时状态：
redis-cli info memory | grep used_memory_human redis-cli info stats | grep total_commands_processed redis-cli config get maxmemory快速确认内存占用、处理过的命令总数、maxmemory 配置是否生效。这些信息在最初验证阶段比跑复杂的性能测试更能说明问题。
如果想给 Redis 做个基准摸个底，redis-benchmark是自带工具，用法很简单：
redis-benchmark -n 100000 -c 100 -t set,get -q这条命令表示 100 个并发连接，执行 10 万次 set 和 get 操作，最后只看结果不刷过程输出。它测出来的是本机 Redis 的极限吞吐，通常每秒能到几万甚至十几万次请求，这也是很多人第一次感受到 Redis 性能优势的时刻。
4. 装好后必懂：Redis 数据类型与常用命令速览
4.1 Redis 五种基础数据类型，别只会用 String
安装只是起点。很多人装完 Redis 就只拿它当带过期时间的 KV 存储，String 走天下，白白浪费了 Redis 的很多能力。我在这里把五种基础数据类型过一遍，每种的适用场景直接给出来，你以后用的时候可以对号入座。
String是最简单的类型，能存字符串、数字、二进制流。典型场景是缓存序列化后的对象、计数器、分布式 ID。比如用户 Session、验证码、商品详情缓存都用它。命令上常用的有set/get/incr/decr/expire。要注意incr这类原子自增命令在多实例调用时非常有用，但如果你在分布式环境下用它做全局计数，由于 Redis 本身单线程执行，单机情况下没问题，集群分片情况下就要考虑用 Lua 脚本或额外加锁来保证一致性，这也是很多人在分享“redis incr 不准”时的讨论背景。
Hash适合存对象。一个 Hash 相当于一个字段少的 row，比如用户信息key=user:1001 field=name value=张三 field=age value=28。比起把整个对象序列化成一个 String，Hash 的好处是可以单独读写某个字段，不需要每次改一个字段就把整个对象拉出来重新序列化再写回去。命令有hset/hget/hgetall/hdel。
List是个双向链表，支持从头部或尾部压入弹出，典型场景是消息队列、最新文章列表、简单的发布订阅队列。比如把用户操作日志lpush到ops:log，再从尾部用rpop读出来，天然就是一个先进先出的队列。命令有lpush/rpush/lpop/rpop/lrange。
Set是无序去重集合，典型场景是点赞、收藏、标签、共同好友。sadd加成员，sismember判断是否在里面，sinter求交集，性能特别好。很多社交类系统用 Set 做“我关注的人”和“我的粉丝”两个集合，然后直接算交集得出“互相关注”。命令有sadd/spop/smembers/sinter/sunion。
ZSet（有序集合）是 Set 的升级版，给每个元素带一个 score 分数，自动按分数排序。最典型的场景就是排行榜：直播打赏榜、热卖商品榜、积分榜。往 ZSet 里zadd数据，用zrevrange取前 N 名，分数用zincrby实时累加。这玩意在传统关系数据库里做起来很麻烦，在 Redis 里就是一行命令的事。命令有zadd/zscore/zrevrange/zrangebyscore。
我判断一个开发者 Redis 能力达不达标，就看他能不能在正确场景用正确数据类型。String 打天下说明思维还停留在“内存缓存”这一层，把 Hash、List、Set、ZSet 用起来，业务代码的复杂度和数据库压力会明显下降。
4.2 高频命令和日常操作，手得熟起来
除了五种类型各自的核心命令，有几个跨类型的命令和技巧值得单独说。
expire key seconds和ttl key是生存期控制的两兄弟，几乎每个缓存 key 都会用到。expire设置过期时间，ttl查看剩余秒数，-1表示永久不过期，-2表示已经不存在了。常见的坑是缓存 key 设置过期时间时，新写入的 key 忘了重新设置 ttl，结果业务里有的 key 永远不失效，内存越涨越多。
scan是批量遍历 key 的推荐方式。我知道很多新手习惯用keys *去查找 key，这个命令在线上千万级 key 的环境下会阻塞 Redis，因为它是全量遍历且阻塞单线程。scan是游标式增量遍历，每次返回一部分 key，虽然不能保证完全精确，但对线上业务友好得多。
redis-cli --scan --pattern 'user:*' | head -20这条命令能安全地扫描前缀为user:的 key，非常适合排查线上数据。
redis-cli -r -i组合可以重复执行命令并指定间隔，比如每秒采样一次：
redis-cli -r 5 -i 1 info memory | grep used_memory_human这会每秒钟执行一次内存查询，连续执行 5 次，用来观察内存增长趋势非常直观。
还有rename给 key 改个名，object encoding key查看 key 内部的编码方式，dbsize看当前库有多少 key，这些都是日常排查经常用到的操作。
5. 常见问题与避坑实录，差不多都是这些梗
5.1 yum 源这条路上的坑，哪个都别再踩
yum 源的问题占我日常排障的很大比例。最常见的有三种。
第一种是No package redis available。这个基本就是仓库里根本没有 redis 包，要么是没配 EPEL/Remi，要么是 repo 文件写错了路径。解决思路就是先yum search redis看看有没有可用的包，没有就去配第三方源。
第二种是GPG key retrieval failed。这类报错是在安装 rpm 包时没法验证签名，通常是源里配置的密钥地址不对，或者密钥过期。最直接的办法是把仓库配置里的gpgkey=...指向正确地址，然后手动导入：
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-remi如果实在搞不定，临时用--nogpgcheck绕过去也不是不能用，但事后一定要把校验补上，长期带病运行是隐患。
第三种是国内网络访问海外源超时。Repo 地址在国外，yum 拉元数据等半天，最后 fetch 超时。这个真的不需要硬扛，把源换成国内镜像就行。操作思路：进入/etc/yum.repos.d/，把 remi 和 epel 的baseurl里的域名替换成镜像地址，改完之后yum clean all && yum makecache。这里特别提醒，系统自带的 base 源也要检查，CentOS 7 已停止维护后，官方源经常失效，得切换到 vault 源或者国内镜像，否则yum makecache会一直报错。还有 arm 架构机器，比如 openEuler 或者 CentOS 7 aarch64，不要拿着 x86 的源地址硬套，架构不匹配同样报错。
5.2 systemd 启动过程中的坑，服务起不来先查这些
Redis 启动失败带来的第一反应通常是看日志，方向是对的，但很多问题其实在更早的阶段就能定位。
端口被占用是排第一的问题。如果你之前用过编译版 Redis，或者 Docker 映射了 6379 端口，那 yum 装的新实例一定起不来，日志会报Could not create server TCP listening socket *:6379: bind: Address already in use。解决方法是ss -lntp | grep 6379找到占用进程，停掉旧的或者把配置文件里的 port 改掉。
权限问题是第二常见的坑。yum 安装的 Redis 默认以 redis 用户而不是 root 身份运行，如果你手改配置把dir /var/lib/redis指向了一个 redis 用户没有写权限的目录，那启动时就会失败，日志里能看到Can't open the append-only file: Permission denied之类的错误。正确做法是用chown redis:redis /your/dir把目录属主改成 redis，或者直接保持在系统默认路径下别乱动。
还有一个隐藏较深的问题跟/etc/redis.conf的supervised参数有关。这个参数告诉 Redis 它被某个进程管理工具监管。在 systemd 环境下应当保持为no或者合适的值，如果设置成了systemd，Redis 会尝试跟 systemd 做协议交互，反而可能造成启动异常。这个参数在不同版本里默认值不一定相同，装完以后打开配置看一眼心里踏实。
5.3 安全相关的坑，Redis 裸奔真的会出事
安全不是装完以后才想的事情，而是装的那一刻就要决定。Redis 默认设计是面向可信内网的，所以它本身没带多少安全机制，全凭部署者自己去补。
最大的坑就是没设密码加默认端口外网可访问。Redis 要是被公网直接访问，基本等于数据裸奔，还会被扫描器盯上用来挖矿脚本植入。前几年这类 Redis 挖矿事件高发，攻击手法就是扫描 6379 端口，连上后写一个 cron 任务，下载挖矿程序执行。我见过好几台服务器因为这被打成肉鸡，CPU 跑到 100%。
应对方案非常明确：把bind改成只能监听内网 IP，用防火墙限制端口访问，requirepass一定要设。三层遥相呼应，每一层断开了都能自救。另外不要用 root 用户长时间跑 Redis，默认 redis 用户就够了，越小权限越安全。如果业务需要 TLS 加密连接，那就要考虑额外配置或者用专有方案，这些需求通常就超出 yum 包的范围了。
6. 后路都铺好：缓存治理与可视化工具
6.1 可视化客户端怎么选，别被网上过时教程带偏
Redis 装好了，数据也跑起来了，大部分人接下来就会想要一个可视化界面来看数据。这里我踩过不少坑，也看别人踩过不少坑。
老的 Redis Desktop Manager（RDM）曾经是 Windows 上最流行的 Redis 客户端，但现在分叉严重，原版已经商业化并且某些版本要收费了。现在主流的选择是 Another Redis Desktop Manager，简称 ARDM，免费开源、跨平台，GitHub 上热度很高，我身边很多团队已经从 RDM 平移到 ARDM 了。它支持 Windows、macOS、Linux，UI 风格比较现代化，平时维护个 key、查看数据、跑个命令完全够用。
除了 ARDM，也可以用 JetBrains 家的 DataGrip，它有 Redis 支持但功能对纯 Redis 来说太重了。我自己在实际工作中是命令行为主，可视化工具主要是方便给不熟命令行的同事用。连接可视化工具时要注意几个小点：要填密码就填密码、端口别填错、默认库号 index 通常是 0、如果 Redis 只监听了本机，可视化工具连不上，需要先用 SSH 隧道或者临时把 bind 改成内网网卡地址。
也有很多人喜欢用 Docker 装一个 Redis 可视化管理后台的，那种 Web 面板确实方便，但我一般不建议在生产环境随便再加这种重量级组件，攻击面会变大，而且卸载的时候还可能残留配置。
6.2 缓存穿透、击穿与雪崩，缓存治理别只会 set get
装完 Redis 真正开始做业务以后，你会发现缓存不是“存进去读出来”这么简单。缓存治理是个正经话题，网上关于缓存穿透、击穿、雪崩的讨论铺天盖地，这里我用自己的话把三件事讲清楚。
缓存穿透：请求的 key 在缓存和数据库里都不存在，这种请求每次都直接打到数据库，比如用一个不存在的用户 ID 去查详情，Redis 里没有，数据库也没有，缓存形同虚设。常见解法有两种：一是把空结果也缓存起来，设置一个很短的过期时间，比如 60 秒，这样同一批恶意请求能被缓存拦住；二是用布隆过滤器，在请求进缓存前先判断这个 key 是否可能存在，不存在就直接返回，连数据库都不用碰。
缓存击穿：某个热点 key 同时在大量请求中被访问，这个 key 突然过期了，所有请求 одновременно 涌入数据库，数据库直接被打垮。解法就是互斥锁，或者叫分布式锁。在 key 过期时，只有一个请求能拿到锁去重建缓存，其他请求先等待或直接返回旧数据。Redis 实现分布式锁的手段有很多，最经典的是SET key value NX EX seconds命令，原子操作设置一个带过期时间的锁，用完再删除。这也是“redis 分布式锁”经常被提起的原因，本质上它是缓存击穿场景下最直接的兜底方案。
缓存雪崩：大量 key 在同一时间集体过期，数据库瞬间接到巨量请求。解法也很经典：设置过期时间时，在基础 TTL 上加入一个随机值，分散过期时间；或者采用多级缓存，把 Hot 数据在前端在布一层；再不然就用缓存集群，把流量分散到多台机器。
# 互斥锁写法示例 SET lock:user:1001 1 NX EX 10Redis 缓存治理说白了就是把“读缓存、读数据库、写缓存”这个流程设计得足够健壮，避免缓存拉胯的时候把底层数据库带崩。装一个 Redis 只是开始，设计好缓存策略才能算真正用上了 Redis。
回到 yum 安装这件事本身，我的实际体会是：装 Redis 永远不是终点，只是起点。yum 给了你一个快速、标准、可维护的基础环境，剩下的事情全看你怎么配置、怎么调用、怎么防坑。把这台机器上的 Redis 跑顺了，后面再往集群化、持久化优化、性能调优走，都是一步一步摸索出来的。
最后再分享一个跟这次安装直接相关的习惯：每次装完 Redis，我第一件事就是改配置设 requirepass 和 maxmemory，第二件事是确认 systemctl enable 开机自启，第三件事是把日志路径里那个默认 logfile 打开看一眼，确保日志真的在写。这三个动作看起来不痛不痒，但真的能帮你避免百分之八十的线上事故。
