说个真实经历。早些年我维护的一台 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 时漏掉 MALLOCjemalloc导致内存分配策略不对表面看跑得挺正常遇到高并发就开始莫名其妙地卡。这些坑不是说解决不了而是完全没必要自己跳一次。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 时直接修改整个仓库的enabled1结果 yum update 的时候把系统里一大批软件升级成了 Remi 版本最后跟系统自带库的依赖冲突一升级就崩。教训就是第三方源平时保持 disabled 状态需要哪个包用哪个包这才是正确打开方式。2.3 验证 yum 源到底通不通别装到一半后悔配置完仓库后先跑两条命令确认源是否真的可用yum repolist enabled | grep -iE epel|remi yum --enablereporemi 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 --enablereporemi-y表示自动确认避免中途停下来问你是否安装。--enablereporemi表示只从 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 频繁重启的问题最后就是靠日志里反复出现的Cant 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比如用户信息keyuser:1001 fieldname value张三 fieldage value28。比起把整个对象序列化成一个 StringHash 的好处是可以单独读写某个字段不需要每次改一个字段就把整个对象拉出来重新序列化再写回去。命令有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 用户没有写权限的目录那启动时就会失败日志里能看到Cant open the append-only file: Permission denied之类的错误。正确做法是用chown redis:redis /your/dir把目录属主改成 redis或者直接保持在系统默认路径下别乱动。还有一个隐藏较深的问题跟/etc/redis.conf的supervised参数有关。这个参数告诉 Redis 它被某个进程管理工具监管。在 systemd 环境下应当保持为no或者合适的值如果设置成了systemdRedis 会尝试跟 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 ManagerRDM曾经是 Windows 上最流行的 Redis 客户端但现在分叉严重原版已经商业化并且某些版本要收费了。现在主流的选择是 Another Redis Desktop Manager简称 ARDM免费开源、跨平台GitHub 上热度很高我身边很多团队已经从 RDM 平移到 ARDM 了。它支持 Windows、macOS、LinuxUI 风格比较现代化平时维护个 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 打开看一眼确保日志真的在写。这三个动作看起来不痛不痒但真的能帮你避免百分之八十的线上事故。