企业官网建设流程全解析

1. CentOS 8 此刻装 Redis，第一步不是敲命令

先说一个很现实的场景：很多朋友拿到 CentOS 8 之后，第一件事就是执行dnf install redis，结果终端无情地回了一句No match for argument: redis，甚至直接报仓库源错误。这时候千万别急着怀疑自己的命令拼错了，大概率是源出了问题。

CentOS 8 官方在 2021 年底就已经停止维护了，社区仓库陆续迁移到了vault.centos.org存档目录，国内不少镜像站也把原本的BaseOS、AppStream、Extras仓库移到了存档路径。你本机的 yum 源配置还指着老地址，自然找不到包。所以在这台系统上装任何软件，第一步都是先检查 yum/dnf 源还通不通。

本篇文章会完整覆盖 CentOS 8 环境下安装 Redis 和卸载 Redis 的全部操作，包括镜像源修复、几种安装方式的选型、生产环境配置调整、连接验证、卸载残留清理以及我实际部署中踩过的高频坑。适合刚刚接触 Linux 的运维新手，也适合需要在旧版本系统上快速交付 Redis 环境的开发、测试同学。

1.1 先确认系统版本和源状态

不管装什么软件，我都习惯先看系统底细：

cat /etc/centos-release

如果显示的是CentOS Linux release 8.x.2111这类版本号，那基本就是标准 CentOS 8。接着检查 dnf 仓库列表：

dnf repolist

正常情况下你会看到类似下面这样的三行仓库名：AppStream、BaseOS、Extras。如果执行之后没有任何仓库显示，或者提示更新元数据失败、Errors during downloading metadata之类的报错，那基本可以确定源已经失效了。

另一种常见情况是：执行dnf install redis时无报错，但提示找不到包。这是因为 CentOS 8 内置的 AppStream 仓库里确实有 redis 包，只不过仓库源路径已经变了，元数据没有拉取到新位置。处理器和 ARM 架构等不同平台的地址还不一样，所以最好的办法是直接整套替换成新的可用源。

1.2 镜像源替换的完整操作

我推荐的方案是切换到阿里云镜像、腾讯云镜像或者直接改走vault.centos.org存档源。这里以阿里云镜像为例，操作非常简单，全程只需要三组命令。

先备份原有源：

mkdir -p /etc/yum.repos.d/backup mv /etc/yum.repos.d/CentOS-*.repo /etc/yum.repos.d/backup/

然后下载阿里云提供的 CentOS 8 存档源配置：

curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo

清一下缓存并重新生成元数据：

dnf clean all dnf makecache

Centos-vault-8.5.2111.repo这个文件里的地址都指向阿里云的存档目录，对已经 EOL 的 CentOS 8 照样有效。等dnf makecache跑完，你会发现仓库列表能正常拉取到了。这时候再执行：

dnf list redis --showduplicates

就能看到仓库里可用的 redis 版本。CentOS 8 自带的 AppStream 仓库默认提供 Redis 5.0，如果你对版本要求不高，这就是最省事的路径。

1.3 版本选择：yum 自带版本与源码新版的差距

先把版本逻辑讲明白，后面选安装方式时你心里才有底。

• CentOS 8 AppStream 仓库自带的是 Redis 5.0，对比当下新版本少了多部分数据结构增强、性能优化和命令功能更新，但胜在稳定、无兼容性包袱，如果你只是做缓存、队列这类基础场景，完全够用。
• Redis 6 引入了多线程 IO、ACL 访问控制、新版协议 RESP3、过期键主动回收优化等特性，是不少线上团队目前的主力版本。
• Redis 7 在 6 的基础上继续优化了内存效率、复制机制、AOF 相关行为，新功能更多，但如果你刚入门，其实不需要太纠结，等部署完再慢慢体验不迟。

在 CentOS 8 上想装 Redis 6 或 7，通常有三条路：源码编译安装、用第三方的 Remi 仓库、用 Docker 容器跑镜像。QQ 群里经常有人说“编译麻烦，直接拉个官方源装不香吗”，但在已经 EOL 的 CentOS 8 上，第三方仓库的兼容性有时候反而会带来新麻烦。所以我自己更倾向于源码编译和 Docker 两条路，原因后面展开说。

2. 三种安装方式，哪种最适合你的服务器

安装 Redis 其实不复杂，复杂的是不知道选择哪条路。我在这个章节给出三套方法，分别说清楚适用场景、操作步骤和注意事项。你可以根据自己是生产服务器、测试机、还是容器化环境来选择。

2.1 方式一：dnf 一条命令装完

适用于：仅做本地测试、对版本不敏感、希望最快速度把 Redis 跑起来的场景。

切换完源之后，直接执行：

dnf install -y redis systemctl enable --now redis

systectl enable --now的意思是一边设置开机自启，一边立刻启动服务。装完以后查看状态：

systemctl status redis

如果显示active (running)，说明服务已经正常运行了。接着可以用：

redis-cli ping

看到PONG返回，安装就成功了。整个过程确实不到一分钟。

这里有个容易被忽略的细节：CentOS 8 用 systemd 管理 redis 服务时，配置文件里的daemonize默认是no，也就是 Redis 以前台进程的方式运行，真正负责后台守护的是 systemd。这个机制本身没问题，你不需要改成yes，改了你反而会发现 systemd 和 redis 的进程管理出现冲突，导致服务状态显示异常。

2.2 方式二：源码编译，版本自己说了算

适用于：生产环境、需要指定 Redis 版本、希望目录可控、后续卸载也清爽的场景。

编译安装的核心就几步：装编译工具、下载源码、make、make install。先安装依赖：

dnf install -y gcc gcc-c++ make tar

如果机器上没有安装下载工具，顺手装一个wget：

dnf install -y wget

下载官方源码包。以 Redis 7.0.14 为例：

cd /usr/local/src wget https://download.redis.io/releases/redis-7.0.14.tar.gz tar zxvf redis-7.0.14.tar.gz cd redis-7.0.14

进入目录后直接编译：

make

编译过程会生成很多编译中间文件，耐心等一会儿。编译完成后再安装到指定目录：

make install PREFIX=/usr/local/redis

PREFIX参数决定了 redis 二进制文件最终被安装到哪个目录。这里我刻意指定为/usr/local/redis，后面卸载时只要删除这个目录就行，不容易误删系统文件。

安装完成后，执行：

/usr/local/redis/bin/redis-server --version

能看到版本号就代表编译安装成功。此时你可以使用绝对路径来启动，也可以把redis-server、redis-cli等命令做一个软链接到/usr/local/bin目录，省去每次打绝对路径的麻烦：

ln -s /usr/local/redis/bin/redis-server /usr/local/bin/ ln -s /usr/local/redis/bin/redis-cli /usr/local/bin/

不过软链接这步可做可不做，看个人习惯。

编译安装的另一个好处是自带redis-benchmark、redis-check-rdb、redis-check-aof这些测试和修复工具，不需要额外安装。对生产环境做压测或排查持久化文件问题时很有帮助。

2.3 方式三：Docker 容器化部署

适用于：机器上已经搭建好 Docker 环境、希望隔离部署、快速切换版本的场景。

Redis 官方提供了 Docker 镜像，拉取和启动都很直接：

docker pull redis:7.0 docker run -d --name redis-test -p 6379:6379 redis:7.0 --requirepass "yourpassword"

注意最后面这个--requirepass是直接追加给 redis server 的启动参数，效果等同于在配置文件里设置requirepass。这种方式适合快速测试，但如果你要挂载数据目录、调整更多配置，用-v挂载配置文件会更专业：

docker run -d --name redis-test -p 6379:6379 \ -v /etc/redis/redis.conf:/etc/redis/redis.conf \ redis:7.0 redis-server /etc/redis/redis.conf

容器方式的好处是和宿主机环境天然隔离，不受 CentOS 8 版本影响，随便跑什么镜像。但生产环境一定要记得挂载数据卷，否则容器一删，RDB 快照和 AOF 日志全部没掉。

综合来看，三张方法的对比我放在下面：

个人建议：如果是公司生产服务器，不要偷懒，老老实实编译安装，目录规划和卸载路径都清晰，出了问题也好排查。如果只是开发机快速验证，dnf 或者 Docker 都行。

3. 装完别急着用，先把这几项配置改了

不管是哪条安装路径，Redis 安装完成后都存在一个同样的问题：默认配置对生产环境来说太“裸”了。守护进程模式、日志位置、网络绑定、密码、持久化策略、内存上限，这些如果不改，早晚会踩到坑。

编辑 Redis 配置文件。dnf 安装和编译安装的配置文件位置略有不同：

• dnf 安装通常位于/etc/redis.conf
• 源码编译安装时，源码包里的redis.conf在redis-7.0.14/目录内，需要你自己复制到统一配置目录，比如/usr/local/redis/conf/redis.conf

目录不一样没关系，内容逻辑完全相同。

3.1 守护进程模式与日志路径

找到配置里的daemonize：

daemonize yes

前面刚说过，如果用 systemd 管理服务，这里保持no是正常的。但如果你是自己手动执行redis-server /path/to/redis.conf来启动，就必须改成yes，否则关闭终端窗口 Redis 就跟着退出了。这种根据启动方式决定配置的做法，是很多人容易踩的坑。

接着看日志配置：

logfile "/var/log/redis/redis.log"

默认情况下logfile是空的，日志直接输出到标准输出。手动启动时就是终端刷日志，一旦关掉窗口日志也消失了。最好显式指定一个日志路径，方便排查问题。修改后记得创建目录并确认 redis 账户有写权限。

数据持久化目录也顺手改掉：

dir /var/lib/redis

3.2 网络安全三件套：bind、保护模式与密码

Redis 的默认配置在安全方面比较保守，但保守的姿势不代表绝对安全，远程连接时常出现各种尴尬。

先看bind：

bind 127.0.0.1 -::1

这个配置表示 Redis 只监听本地回环地址，外部机器连不上。如果你需要远程访问，有两种做法：

1. 把本机局域网 IP 或0.0.0.0填进去：

   bind 0.0.0.0

2. 直接注释掉 bind 行，不限制网络接口，结合protected-mode保护。

第一种更直观，第二种要配合好保护模式。

再来看protected-mode：

protected-mode yes

protected-mode yes的含义是：当 Redis 没有设置密码、且没有通过bind明确限定可访问网段时，只允许本机链路（loopback）访问，拒绝一切来自其他机器的外部连接。这个机制对新手非常友好，但也会造成“明明配置了远程连接，却始终连不上”的疑惑。

所以标准做法是：远程连接两个前提必须同时满足——设置密码，并且bind 0.0.0.0或注释 bind 行。

最后设置密码：

requirepass "改成你自己的强密码"

注意密码不要弱智，比如123456这种就别往生产上放了。

如果你用了 Redis 6 以上的版本，还想用 ACL 做细粒度用户权限管理，可以在配置文件底部加用户：

user default on nopass ~* +@all user app_user on >app_password ~cache:* +@read +@write

ACL 的完整规则比较复杂，这里不展开，先说结论：默认情况下default用户通常需要配合requirepass使用，如果你主动创建了新用户，记得给相应命令类别授权，否则会出现认证通过但命令被拒绝的奇怪现象。

3.3 持久化策略：RDB 与 AOF 的选择

Redis 有两种持久化方式：RDB 快照和 AOF 日志。

RDB 是按时间间隔生成内存数据快照，恢复速度快，但可能丢最后一段数据。默认配置有类似这样的触发条件：

save 900 1 save 300 10 save 60 10000

意思是 900 秒内至少有 1 个键变化就执行快照、300 秒内至少 10 个键变化就执行快照，以此类推。

AOF 是追加写日志，每执行一条写命令就记录一条，数据完整性更高，但文件体积更大，恢复速度相对慢一点。

两种没有绝对好坏，生产环境更稳妥的组合是两者同时开启：

appendonly yes appendfsync everysec

appendfsync everysec表示每秒刷一次 AOF 日志到磁盘，性能和可靠性比较平衡，一般推荐这个值。如果你的业务对数据完整性的要求极苛刻，可以改成always，但写入性能会下降明显。

3.4 内存上限与淘汰策略

如果不设置maxmemory，Redis 会一直用内存直到操作系统 OOM，进程直接被系统杀掉，这在生产环境非常致命。

按服务器真实内存适当分配：

maxmemory 512mb

当内存达到上限后，Redis 会根据maxmemory-policy决定谁先被淘汰。常用策略：

如果只是做缓存，allkeys-lru是默认的第一选择。如果数据还承担了一部分持久化责任，那尽量用volatile-*系列，避免把不过期的业务数据淘汰掉。

4. 验证安装：从 redis-cli 到图形化客户端

配置文件改完之后，重启 Redis 让配置生效：

systemctl restart redis

如果是手动启动的编译安装版本：

redis-server /usr/local/redis/conf/redis.conf

4.1 本地验证三板斧

第一板斧，确认服务进程在跑：

systemctl status redis

第二板斧，本地直接用 redis-cli 连接并输出PONG：

redis-cli ping

如果没设置密码，直接返回PONG。设置了密码的话需要先认证：

redis-cli -a 你的密码 ping

执行后终端大概率会出现一行警告Using a password with '-a' option on the command line interface may not be safe，这是 Redis 在提醒你命令行输入密码会被记录到 shell history 里，不用太慌，本地测试这么操作没问题。正式脚本或者生产环境，建议改用环境变量方式：

export REDISCLI_AUTH="你的密码" redis-cli ping

这样就不会出现明文密码告警。

第三板斧，看看内存和 key 数量是否正常：

redis-cli info memory redis-cli dbsize

info memory会输出内存分配器、峰值内存、碎片率等关键参数。dbsize返回当前数据库 key 数量，刚装完应该是0。

4.2 远程图形化管理工具怎么连

远程连接是安装被验证后的另一个高频诉求。很多同学喜欢用图形化客户端，我用过的两款比较多：

• Redis Desktop Manager，老牌工具，后来商业化了，免费版功能受限比较明显。
• Another Redis Desktop Manager，一个开源替代品，颜值在线、功能免费，订阅和命令监控等基础功能好用了不少。

连接之前，服务器端必须确认：

1. Redis 配置文件里的bind已经允许外部访问；
2. protected-mode设置为no，或者已经设置了密码；
3. 防火墙放行 6379 端口；
4. 云服务器安全组同样放行 6379 端口。

防火墙命令：

firewall-cmd --permanent --add-port=6379/tcp firewall-cmd --reload

然后去图形化工具里填主机 IP、端口 6379、密码，点连接即可。如果连不上，优先检查上面四步，这四条是远程连接失败的九成原因。

5. 卸载 Redis 的三种场景与完整清理流程

卸载的事很多人不重视，觉得把包删了就行。实际上一套 Redis 环境落地之后，残留的配置文件、数据文件、日志文件、系统用户、开机自启服务可能散布在多个目录里。如果不清理，重新部署的时候很容易出现端口被占、配置残留导致诡异行为的情况。

按照安装方式，卸载步骤也分三种。

5.1 场景一：dnf/yum 安装的卸载

先停服务、禁用开机自启：

systemctl stop redis systemctl disable redis

接着卸载软件包：

dnf remove -y redis

但dnf remove只删除软件包本身，数据目录、日志目录、配置文件一般都会保留。这是 Linux 包管理器的设计逻辑，卸载软件不等于删除用户数据。你需要手动检查这些位置：

ls -l /etc/redis.conf ls -l /var/lib/redis ls -l /var/log/redis

如果确认没有需要保留的数据，直接删除：

rm -rf /etc/redis.conf rm -rf /var/lib/redis rm -rf /var/log/redis

有些版本还会创建独立的redis系统用户，你也可以一并清理掉：

userdel redis

5.2 场景二：源码编译安装的卸载

编译安装因为没有经过系统包管理器，不提供集中的卸载命令，得手动清理。但正因目录都是自己定的，清理起来反而比包管理更清爽。

先停掉进程：

pkill redis-server

删除安装目录，也就是当时PREFIX指定的目录：

rm -rf /usr/local/redis

如果之前做了软链接到/usr/local/bin，也要手动清除：

rm -f /usr/local/bin/redis-server rm -f /usr/local/bin/redis-cli rm -f /usr/local/bin/redis-benchmark rm -f /usr/local/bin/redis-check-rdb rm -f /usr/local/bin/redis-check-aof

源码包留在/usr/local/src下的redis-7.0.14目录也可以一并删掉。配置目录、数据目录参考上文手动删除即可。

5.3 场景三：容器方式移除

容器卸载最需要注意的反而不是容器本身，而是数据卷。

docker stop redis-test docker rm redis-test

删除镜像：

docker rmi redis:7.0

如果之前用-v挂载了宿主机目录作为数据卷，那个目录里的 dump.rdb、appendonly.aof 不会随着容器删除而消失，需要你确认是否需要保留后手动删除。

5.4 卸载后的残留清理清单

不管哪种方式，卸载之后我都建议跑一遍下面的检查命令，确保系统里没有 redis 残留痕迹：

which redis-server which redis-cli ps aux | grep redis ss -lntp | grep 6379 find /etc -name "*redis*" 2>/dev/null find /var/log -name "*redis*" 2>/dev/null find /var/lib -name "*redis*" 2>/dev/null

如果以上命令都干干净净没有输出，说明卸载彻底了。特别注意ss -lntp | grep 6379，如果发现端口仍在监听，说明还有 redis-server 进程没有杀掉，继续排查进程来源。

6. 实测中高频踩坑记录

虽然安装、卸载看起来不难，实际操作中我确实踩过不少坑，有些坑甚至藏得很深。把高频的几个记录下来，你遇到同样问题时可以直接按图索骥。

6.1 镜像源仓库报错的完整排查

这是 CentOS 8 装 redis 最典型的问题。常见报错有：

• No match for argument: redis
• Errors during downloading metadata for repository 'appstream': Status: 404
• Cannot prepare internal mirrorlist: No URLs in mirrorlist

排查链路如下：

第一步，确认系统版本：

cat /etc/redhat-release

第二步，检查源配置文件内容：

cat /etc/yum.repos.d/CentOS-*.repo

看baseurl是否还在指向mirror.centos.org。如果是，基本就是源失效了。

第三步，按本文第一章的方式替换成阿里云存档源或者直接修改 baseurl 指向vault.centos.org：

sed -i 's/mirror.centos.org/vault.centos.org/g' /etc/yum.repos.d/CentOS-*.repo sed -i 's/^#baseurl/baseurl/g' /etc/yum.repos.d/CentOS-*.repo sed -i 's/^mirrorlist=/#mirrorlist=/g' /etc/yum.repos.d/CentOS-*.repo

这三条 sed 命令的作用是：把源地址统一改为 vault 存档地址，启用原本注释的 baseurl 行，注释掉已失效的 mirrorlist 行。执行完再dnf clean all && dnf makecache。

这一步做完，大部分源报错都能解决。

6.2 编译时报错缺 make 或缺 gcc

编译安装 Redis 时，有的机器上执行make直接报：

make: gcc: Command not found

或者：

make: ** No targets specified and no makefile found.

前者说明没装 gcc，后者往往是你没有执行cd redis-7.0.14就启动了make，或者解压后目录没切换进去。

解决办法很简单，先在源码目录执行make distclean，把上次编译产生的中间文件清干净，然后重新检查依赖：

dnf install -y gcc gcc-c++ make make

6.3 连接被拒绝：bind 与 protected-mode 的坑

本机用 redis-cli 连没问题，但开发机、笔记本上的图形客户端就是连不上，大概率是 bind 和 protected-mode 的问题。

排查链路：

ss -lntp | grep 6379

看看监听的地址是127.0.0.1:6379还是*:6379或0.0.0.0:6379。如果只有127.0.0.1，那就是 bind 限制了。修改bind 0.0.0.0之后重启 Redis。

如果监听已经是0.0.0.0，还是连不上，再确认是否设置 requirepass，并检查 protected-mode。有时候你在配置文件里设置了 requirepass，又设置 protected-mode yes，某些老版本客户端认证流程不标准，也会出现连接被拒。

防火墙和安全组的检查前面说过了，这里不重复。

6.4 端口被占用的定位方式

卸载后想重新装 Redis，结果启动时报Address already in use，说明 6379 端口还在被某个进程占用。

用这条命令找出占用进程：

ss -lntp | grep 6379

如果显示的是旧的 redis-server 进程，用kill加上进程 PID 结束它：

kill -9 进程PID

如果不是 redis 进程占用，那就说明有其他程序也在用 6379，需要评估是换端口还是处理原有进程。注意kill -9属于强杀，生产环境使用前确认一下进程是否可以安全退出。

7. 后面还能做什么：从单机 Redis 到主从环境

装好、卸载好之后，还有两件事是顺理成章的延伸，一是配置主从复制，二是把数据备份机制建立起来，这些在高并发业务里都会用到。

7.1 最小化的主从配置思路

Redis 主从复制在配置层面其实非常简单。假设两台机器，A 是主节点，B 是从节点，从节点配置文件里加两行：

replicaof 主节点IP 6379 masterauth 主节点密码

然后在从节点启动 Redis，它就会自动从主节点同步全量数据，之后持续接受增量同步。

主节点只需要设置：

requirepass 主节点密码

重启主从节点后，在从节点上执行：

redis-cli info replication

如果看到role:slave（或新版本里的role:replica）以及master_link_status:up，说明主从已经搭建成功。这个玩法在单机应用跑通之后，可以很自然地延伸到读写分离场景。

7.2 数据备份与迁移小建议

很多人的 Redis 备份方式只是“把 dump.rdb 拷一份”，这也不错，但更稳妥的是使用 Redis 自身的同步机制。

手动触发一次 RDB 快照：

redis-cli BGSAVE

BGSAVE是后台异步生成快照，不会阻塞主进程。然后去配置的dir目录下找到 dump.rdb 备份起来。

如果要把数据迁移到另一台机器，最省事的是用redis-cli --rdb直接导出：

redis-cli -a 密码 --rdb /tmp/dump_export.rdb

生成的 rdb 文件拿到目标机器上启动即可。这只是迁移手段之一，如果数据量大，更推荐主从复制做全量同步，然后切换主节点，这样能尽量缩短业务中断时间。

我在实际项目中见过太多“装完就跑”的状态，线上 Redis 连密码都没有，数据也没做持久化，一旦机器重启整个缓存数据归零。如果你读完这篇打算在生产环境动手，至少把章节 3 里的网络安全三件套和持久化配置先落实，再考虑别的花活。