安装 Redis

你可能只是想跟着课程敲几条命令，结果还没见到 PONG，先在包管理器、容器、WSL 和配置文件之间绕了一圈。Redis 本身并不难装，真正容易让人困惑的是：同样叫“安装完成”，有人只下载了客户端，有人启动了一个前台进程，有人已经把服务、数据目录和开机启动都安排好了。

这一章不追求把所有平台都装一遍。我们要搭出一套你能解释清楚、能重复创建、出问题时也知道从哪里查的环境。完成后，你应该能回答五个问题：Redis 是怎么安装的，服务由谁启动，客户端连到哪里，配置和数据放在哪里，以及机器重启后会发生什么。

先选一条适合自己的安装路线

安装方式没有统一冠军。你只想在十分钟内体验命令，Docker 最省心；你在 Linux 服务器上长期运行，发行版软件包更容易交给 systemd 管理；你要修改编译选项，源码安装才有必要。先把目标说清楚，后面的命令会少很多。

如果你还拿不准，可以在下面选择自己的环境和目标。它给出的不是“唯一正确答案”，而是一条更少绕路的起点。

有一条边界要先立住：客户端和服务端不是一回事。redis-server 是保存数据、监听端口并执行命令的进程；redis-cli 只是向某个 Redis 服务发命令的终端工具。只安装 redis-cli，可以连接远程 Redis，但本机不会因此多出一个数据库服务。

动手前先确认四件事

很多“Redis 装不上”的问题，其实发生在安装之前：端口已经被占用、旧版本还在运行、CPU 架构选错，或者你在一个终端里启动服务，却在另一个网络环境里连接。花一分钟做预检，比装完再猜省事。

看清操作系统和处理器架构

Linux 可以这样确认：

cat /etc/os-release
uname -m

macOS 可以这样确认 Homebrew 前缀和芯片架构：

uname -m
brew --prefix

Windows 的 PowerShell、WSL 里的 Bash、Docker 容器里的 shell 是三个不同环境。一个常见误会是：在 WSL 里装了 redis-cli，然后在 PowerShell 里执行同名命令，结果提示找不到。命令装在哪里，就先在哪里验证。

检查 6379 端口有没有主人

Redis 默认监听 TCP 6379。Linux 上可以先看：

ss -ltnp | grep ':6379'

macOS 上可以用：

lsof -nP -iTCP:6379 -sTCP:LISTEN

没有输出通常表示端口空闲。已经有输出时，先确认那是不是你之前启动的 Redis，不要直接结束一个身份不明的进程。你也可以让练习实例改用 6380，但要记得客户端的端口也一起改。

分清四类文件

把 Redis 想成一家夜间营业的小店，会比较直观：

• 可执行文件是店员，例如 redis-server 和 redis-cli；
• 配置文件是营业规则，例如绑定地址、持久化方式和内存上限；
• 数据目录是仓库，RDB 与 AOF 文件会落在这里；
• 日志是值班记录，服务启动失败时先看它，而不是反复重装。

不同安装方式会把它们放到不同位置。后面每完成一种安装，我们都会立即把这四类位置查清楚。

决定这是练习环境还是长期服务

练习环境可以前台启动，关闭终端就停止，数据也可以随时清掉。长期服务则至少需要固定版本、专用运行用户、明确的配置与数据目录、自动重启、日志、安全边界和升级前备份。不要把“能在我的终端里跑”直接当成生产部署方案。

用 Docker 建一个可重复的练习环境

如果你只是想先学 Redis，我通常建议从 Docker 开始。它像一个透明收纳盒：Redis 进程在盒子里，端口是盒子上的接口，数据卷是盒子外单独保管的抽屉。容器可以扔掉重建，抽屉不一定跟着消失。

创建数据卷并启动容器

下面的命令做了几件有意为之的事：固定补丁版本；只把端口发布到本机回环地址；把 /data 交给命名卷；启用每秒刷盘策略的 AOF；让 Docker 在机器重启后恢复容器。

docker volume create redis-course-data
 
docker run -d \
  --name redis-course \
  --restart unless-stopped \
  -p 127.0.0.1:6379:6379 \
  -v redis-course-data:/data \
  redis:8.8.1 \
  redis-server --appendonly yes --appendfsync everysec

这里的 127.0.0.1:6379:6379 与常见的 6379:6379 只差一段地址，安全含义却不同。前者只接受本机连接；后者通常把端口发布到宿主机的所有网络接口。学习环境没有理由顺手把数据库开放给同一网络里的其他机器。

确认容器状态：

docker ps --filter name=redis-course
docker logs --tail 50 redis-course

容器内已经带有 redis-cli，所以即使宿主机没有安装客户端，也能验证：

docker exec redis-course redis-cli PING

看到 PONG，说明容器里的客户端成功走到服务端并收到响应。它还不能证明宿主机端口映射正确，所以如果本机装有 redis-cli，再补一次外部验证：

redis-cli -h 127.0.0.1 -p 6379 PING

验证数据卷真的独立于容器

先写入一条只用于本章的测试数据：

docker exec redis-course redis-cli SET course:install:check ready
docker exec redis-course redis-cli GET course:install:check

然后停止并删除容器，再用同一个数据卷创建回来：

docker stop redis-course
docker rm redis-course
 
docker run -d \
  --name redis-course \
  --restart unless-stopped \
  -p 127.0.0.1:6379:6379 \
  -v redis-course-data:/data \
  redis:8.8.1 \
  redis-server --appendonly yes --appendfsync everysec
 
docker exec redis-course redis-cli GET course:install:check

如果仍返回 ready，你验证了两件事：AOF 确实写到了 /data，命名卷也没有随着容器删除。反过来，执行 docker volume rm redis-course-data 才会删除这份数据；除非你明确想清空练习环境，否则不要把它当成普通清理命令。

让应用和 Redis 留在容器网络里

当应用本身也运行在 Docker 中，通常不必把 6379 发布到宿主机。创建一个用户自定义网络，让应用用容器名 redis-course 连接即可：

下面是一种替代启动方式，不是接着上一段重复执行。Docker 不允许同时存在两个名为 redis-course 的容器；如果你已经完成上面的练习，可以先理解思路，等需要重建环境时再采用这一版。

docker network create redis-course-net
 
docker run -d \
  --name redis-course \
  --network redis-course-net \
  -v redis-course-data:/data \
  redis:8.8.1 \
  redis-server --appendonly yes

这种方式缩小了暴露面，也更接近多容器项目的真实结构。代价是宿主机上的 redis-cli 无法再直接连 127.0.0.1:6379，你需要从同一 Docker 网络里的客户端或 docker exec 访问。

在 Ubuntu 或 Debian 上交给包管理器

Linux 服务器上最稳妥的第一选择通常是软件包。它不只复制二进制文件，还会安排配置目录、数据目录、服务单元和日志入口。以后升级、卸载或检查文件归属，也有包管理器可以对账。

添加软件源并安装

先安装添加软件源需要的工具，再把 Redis 软件源的签名密钥放到独立 keyring：

sudo apt-get update
sudo apt-get install -y lsb-release curl gpg
 
curl -fsSL https://packages.redis.io/gpg \
  | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
 
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
 
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/redis.list
 
sudo apt-get update
apt-cache policy redis
sudo apt-get install -y redis

apt-cache policy redis 是一个很有用的停顿点。它会显示候选版本和来源，让你在安装前发现“仍然从系统旧仓库取包”或“软件源代号不匹配”之类的问题。

安装后，软件包一般会启动并启用 redis-server 服务。不要凭感觉判断，直接检查：

sudo systemctl enable --now redis-server
systemctl status redis-server --no-pager
redis-server --version
redis-cli --version
redis-cli PING

如果状态不是 active (running)，先看日志：

journalctl -u redis-server -n 100 --no-pager

找到真实配置、数据和服务定义

Ubuntu 与 Debian 软件包常把主配置放在 /etc/redis/redis.conf，数据放在 /var/lib/redis。不要只记住教程里的路径，应该让当前机器自己回答：

systemctl cat redis-server
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename
redis-cli CONFIG GET appenddirname
redis-cli INFO server | grep '^config_file:'

修改配置前先保留带日期的副本：

sudo cp -a /etc/redis/redis.conf \
  "/etc/redis/redis.conf.before-course-$(date +%Y%m%d-%H%M%S)"

改完后重启并立刻检查服务和日志：

sudo systemctl restart redis-server
systemctl is-active redis-server
redis-cli PING
journalctl -u redis-server -n 50 --no-pager

Redis 允许用 CONFIG SET 在线调整一部分参数，但内存里的变化不会天然写回配置文件。你可以显式修改配置文件，或在确认写入目标正确后使用 CONFIG REWRITE。如果忘了这一步，服务重启后配置就会“神奇地恢复原样”。

Rocky Linux 与 AlmaLinux 的思路相同

RPM 系发行版的命令不同，但判断顺序没有变化：添加官方软件源、导入签名密钥、安装、交给 systemd、再用 redis-cli 验证。仓库文件要和系统大版本匹配，例如 Rocky Linux 9 不应照抄 Rocky Linux 8 的地址。

[Redis]
name=Redis
baseurl=http://packages.redis.io/rpm/rockylinux9
enabled=1
gpgcheck=1

curl -fsSL https://packages.redis.io/gpg -o /tmp/redis-repository.key
sudo rpm --import /tmp/redis-repository.key
sudo dnf install -y redis
sudo systemctl enable --now redis
redis-cli PING

不同包的服务名可能是 redis 或 redis-server。如果 systemctl status redis 提示单元不存在，先查包实际安装了什么，不要盲猜：

rpm -ql redis | grep -E 'systemd|service|redis\.conf'
systemctl list-unit-files | grep redis

源码编译只在你知道为什么时使用

源码安装不是“更专业的安装”，它只是把更多责任交给你。你需要特定编译选项、要调试 Redis 本身，或发行版没有所需版本时，它很合适；普通服务器部署则通常不值得为此放弃软件包的服务管理和升级记录。

sudo apt-get update
sudo apt-get install -y build-essential tcl pkg-config libssl-dev curl
 
curl -fLO https://download.redis.io/redis-stable.tar.gz
tar -xzf redis-stable.tar.gz
cd redis-stable
 
make -j"$(nproc)"
make test
sudo make install

如果要编译 TLS 支持，使用 make BUILD_TLS=yes，并确保系统已有 OpenSSL 开发库。make install 默认只是把程序放进 /usr/local/bin，不会自动给你创建 redis 用户、systemd 单元、配置目录、数据目录和日志轮转。也就是说，下面这句成立：

redis-server --version

并不代表下面这句也一定成立：

systemctl status redis-server

在 macOS 上用 Homebrew cask

macOS 开发者容易凭旧经验执行 brew install redis 和 brew services start redis。Redis Open Source 8.x 当前推荐的是 Redis 自己的 Homebrew tap 与 cask，而且这个 cask 不接入 brew services。这不是你命令拼错了，而是安装形态发生了变化。

检查旧安装，再安装当前 cask

先看看系统里是否已有同名程序，避免 PATH 指向旧版本：

command -v redis-server
redis-server --version 2>/dev/null || true
brew list --versions redis 2>/dev/null || true

如果确认旧的 Homebrew formula 不再需要，再用 brew uninstall redis 移除。不要未经检查就删除旧配置或数据；它们可能仍是你回退时唯一能用的副本。

安装当前 cask：

brew tap redis/redis
brew install --cask redis

确认 Redis 的二进制目录已经在 PATH 中：

echo "$PATH"
command -v redis-server
command -v redis-cli

Apple 芯片的 Homebrew 通常位于 /opt/homebrew，Intel Mac 通常位于 /usr/local。使用 $(brew --prefix) 比在脚本里写死其中一个路径更稳。

启动、验证与停止

用安装附带的配置启动：

redis-server "$(brew --prefix)/etc/redis.conf"
redis-cli PING

检查当前配置文件和数据目录：

redis-cli INFO server | grep '^config_file:'
redis-cli CONFIG GET dir

需要停止时，让 Redis 自己执行有序关闭：

redis-cli SHUTDOWN

有序关闭会按当前持久化策略处理数据，比直接杀进程更容易解释。若 SHUTDOWN 后终端显示连接关闭，这是预期结果，因为服务端已经退出。

在 Windows 上选择 Docker 或 WSL2

Redis 的主要运行环境仍是类 Unix 系统。Windows 上最省事的路线不是找一个多年未维护的原生移植包，而是让 Redis 运行在官方支持更充分的 Linux 环境中。这里有两个靠谱选择，它们解决的是不同问题。

只想运行 Redis：用 Docker Desktop

确保 Docker Desktop 使用 Linux 容器，然后在 PowerShell 执行与前文相同的容器命令：

docker volume create redis-course-data
 
docker run -d `
  --name redis-course `
  --restart unless-stopped `
  -p 127.0.0.1:6379:6379 `
  -v redis-course-data:/data `
  redis:8.8.1 `
  redis-server --appendonly yes --appendfsync everysec
 
docker exec redis-course redis-cli PING

PowerShell 的续行符是反引号，不是 Bash 的反斜杠。复制多行命令时，反引号后面不能再留空格。嫌它容易出错，就把 docker run 写成一行执行。

Windows 应用可以连接 127.0.0.1:6379。服务、配置和数据仍在 Linux 容器语境中：查日志用 docker logs redis-course，不是去 Windows 事件查看器里找 Redis 服务。

应用也在 Linux 工具链里：用 WSL2

以管理员身份打开 PowerShell：

wsl --install
wsl --list --verbose

首次进入 Ubuntu 后创建 Linux 用户，然后在 WSL 的 Bash 中走 Ubuntu/Debian 的 APT 安装流程。安装与验证命令都在同一个 WSL 终端执行：

sudo apt-get update
sudo apt-get install -y lsb-release curl gpg
 
curl -fsSL https://packages.redis.io/gpg \
  | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
 
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
 
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/redis.list
 
sudo apt-get update
sudo apt-get install -y redis
sudo systemctl enable --now redis-server
redis-cli PING

现代 WSL2 可以使用 systemd。如果 systemctl 明确提示当前发行版未启用 systemd，先更新 WSL 并检查 /etc/wsl.conf，不要把服务反复装卸。临时学习也可以在 WSL 终端里前台运行 redis-server /etc/redis/redis.conf，但关闭该会话前要知道服务是否还会继续。

我建议把应用和 Redis 放在同一侧：应用在 WSL 中开发，就在 WSL 内用 127.0.0.1 访问 Redis；应用是 Windows 原生进程，Docker 的端口映射通常更直观。跨 Windows 与 WSL 边界连接时，网络转发行为会受 WSL 版本和网络模式影响，别为了省一个容器而把 bind 直接改成 0.0.0.0。

不把非官方原生端口当默认答案

Windows 上存在 Redis 兼容产品和历史移植版本，但它们的发布节奏、命令覆盖、许可证和运维方式可能与 Redis Open Source 不同。除非你的项目明确选定了某个产品，否则本课程用 Docker 或 WSL2，可以减少“教程命令在我的版本不存在”的额外变量。

用一条证据链验收安装

PING 很重要，但它只是体检中的一项。一个真正可用的环境至少要通过：二进制版本、服务状态、端口、协议往返、读写、持久化状态和重启后数据七层检查。

先确认你调用的是哪个版本

command -v redis-server
command -v redis-cli
redis-server --version
redis-cli --version

一台机器可以同时存在系统包、Homebrew、源码和容器中的 Redis。版本不对时，先查 PATH 和进程来源，不要继续改配置。Linux 服务的可执行文件可以从 systemctl cat redis-server 的 ExecStart 中看到；容器版本则用下面的命令查看：

docker exec redis-course redis-server --version
docker inspect redis-course --format '{{.Config.Image}}'

再确认网络与协议

redis-cli -h 127.0.0.1 -p 6379 PING

结果可以这样读：

• PONG：TCP 连接、Redis 协议和服务端命令处理都通了；
• Connection refused：目标地址上没有进程监听，或端口映射没有建立；
• 超时：更像防火墙、路由或绑定地址问题；
• NOAUTH：网络已通，但实例要求认证；
• WRONGPASS：已经走到认证阶段，用户名或密码不匹配。

需要认证时，尽量不要把密码直接写进带 -a 的命令，因为它可能出现在 shell 历史和进程参数中。短时验证可以使用环境变量，并在完成后清理：

read -rsp "Redis 密码：" REDISCLI_AUTH
echo
export REDISCLI_AUTH
redis-cli --user course -h 127.0.0.1 -p 6379 PING
unset REDISCLI_AUTH

read -s 让 Bash 不回显输入内容，REDISCLI_AUTH 也避免密码出现在 redis-cli 的命令行参数中；它仍只是本次 shell 的短时做法。CI 与生产环境应改用团队的密钥管理方式。不要为了让示例立刻成功，把真实密码硬编码进仓库脚本。

做一次有清理动作的读写往返

redis-cli SET course:install:probe "可以读写"
redis-cli GET course:install:probe
redis-cli DEL course:install:probe

SET 返回 OK、GET 返回刚写入的中文、DEL 返回 1，才是一组完整的最小读写验证。使用带课程前缀的临时键，并在最后删除，比随手写一个叫 test 的键更不容易污染共享实例。

查看服务端自述

redis-cli INFO server
redis-cli INFO persistence
redis-cli INFO memory

先关注少数几个字段：

下面的体检台可以把常见错误按“现象—证据—下一步”串起来。排错时一次只验证一层，远比连续重装更快。

把安全边界和服务化一起装好

Redis 默认端口很有辨识度，扫描器也认识它。一个常见事故路径是：为了让另一台机器连进来，把 bind 改成 0.0.0.0；遇到保护模式阻止连接，又顺手关闭 protected-mode；最后以为加一个简单密码就安全了。每一步都像在解决当前错误，连起来却是在把数据库交给不受信任的网络。

从网络隔离开始

单机开发环境优先保持：

bind 127.0.0.1 ::1
protected-mode yes
port 6379

生产环境中，只有应用服务器、运维通道和必要的 Redis 节点应能访问 Redis。通过私有网络、安全组或主机防火墙限制来源；不要让浏览器、移动端或公网用户直接连数据库。应用服务应该夹在用户与 Redis 之间，校验输入并控制能执行的业务动作。

认证是第二道门，不是围墙的替代品。Redis 6 之后优先使用具名 ACL 用户，为应用限制键模式和命令类别。管理账号与应用账号分开，避免给普通应用开放 CONFIG、ACL、FLUSHALL 等管理或高破坏性命令。凭据要来自密钥管理系统，不写进 Git，也不出现在可被其他用户读取的进程参数里。

跨主机传输敏感数据时，还要考虑 TLS 或受保护的专用网络。只设置密码但明文传输，不能防止有网络监听能力的人看到认证信息和业务数据。

不用 root 身份运行 Redis

软件包通常已经创建专用的 redis 系统用户。检查服务实际身份：

systemctl show redis-server -p User -p Group -p ExecStart
ps -o user,group,pid,command -C redis-server

数据目录、配置和日志应该只给需要的身份相应权限。不要图省事执行 chmod -R 777；它会掩盖真正的属主问题，并把持久化文件交给不相关用户修改。

给内存和持久化一个明确策略

开发机上可以设置保守的内存上限，避免一次实验挤满整台电脑。但淘汰策略不是随便抄一个 allkeys-lru 就结束了：如果 Redis 保存的是不能丢的任务状态，自动淘汰键可能比写入失败更危险。

maxmemory 512mb
maxmemory-policy noeviction
appendonly yes
appendfsync everysec

noeviction 会在达到上限后拒绝新增写入，让问题暴露出来；纯缓存场景才常选择 allkeys-lru 或其他淘汰策略。appendfsync everysec 在性能和最多约一秒写入损失之间做折中，它不是“绝不丢数据”的承诺。

用交互检查器观察暴露面

升级前先知道数据住在哪里

安装方式决定了升级动作，但升级的核心不是“换一个二进制”，而是让新进程继续使用正确的配置和数据，并且能在验证失败时停下来。

记录升级前基线

redis-cli INFO server | grep -E '^redis_version:|^config_file:'
redis-cli INFO persistence
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appenddirname

同时记录安装来源：

command -v redis-server
dpkg -S "$(command -v redis-server)" 2>/dev/null || true
rpm -qf "$(command -v redis-server)" 2>/dev/null || true
docker inspect redis-course --format '{{.Config.Image}}' 2>/dev/null || true

这些信息决定你应该用 apt、dnf、Homebrew、重新编译，还是重建容器。混用升级方式，最容易出现“客户端已经是新版本，systemd 启动的还是旧二进制”。

生成快照并复制到独立位置

小型练习实例可以直接执行 SAVE；数据量较大的实例通常用 BGSAVE，因为同步保存会阻塞命令处理。无论选哪种，都要检查结果，而不是看到命令返回就算备份完成。

redis-cli BGSAVE
redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|rdb_last_bgsave_status|rdb_last_save_time'

等后台保存完成后，把 RDB、AOF 目录和配置复制到 Redis 数据目录之外，并检查副本权限与大小。只在原数据目录里留一份 dump.rdb 不叫备份：磁盘、误删除和错误挂载仍会一起带走它。

在受控环境演练升级

升级前至少验证四件事：目标版本是否支持当前升级路径；模块与客户端是否兼容；旧配置项是否被移除或改义；新的持久化文件能否正确加载。Docker 很适合拿备份副本演练，但不要把生产数据卷直接挂给试验容器写入。

包管理器升级时，先查看候选版本和配置文件差异，再安排维护窗口：

apt-cache policy redis
sudo apt-get install redis
redis-cli INFO server | grep '^redis_version:'
redis-cli INFO persistence

Docker 升级的思路是拉取明确的新标签，用同一份配置和经过备份的数据卷重建容器，再重复验收链。先保留旧镜像和创建参数，不要急着清理；但也不要想当然地把新版本写过的持久化文件交回旧版本，回退前要确认数据格式兼容性。

对于不能停机的生产系统，单实例原地升级通常不够。更常见的做法是先升级副本，检查同步和数据，再切换角色并处理原主节点。那已经属于复制、Sentinel 或 Cluster 的运维范围，本章先把单实例的备份、演练和验证习惯建立起来。

出问题时按现象缩小范围

安装失败时最浪费时间的动作是“再装一遍看看”。更有效的方法是把链路拆开：shell 能否找到命令，服务是否活着，端口是否监听，网络是否可达，认证是否通过，数据目录是否可写。每个现象都有更接近根因的证据。

提示命令不存在

command -v redis-server
command -v redis-cli
echo "$PATH"

如果服务来自 Docker，本机没有 redis-cli 完全正常，使用 docker exec redis-course redis-cli。如果刚装完 Homebrew cask，检查 $(brew --prefix)/bin 是否进入 PATH。不要因为只缺客户端，就再启动第二个 Redis 服务。

连接被拒绝或超时

先确认地址和端口，再看监听者：

redis-cli -h 127.0.0.1 -p 6379 PING
ss -ltnp | grep ':6379'
systemctl status redis-server --no-pager

容器环境补查端口映射和日志：

docker ps -a --filter name=redis-course
docker port redis-course
docker logs --tail 100 redis-course

“拒绝连接”通常说明目标机器明确表示端口无人监听；“超时”则更像数据包被防火墙丢弃或走错网络。把两者混成一个“Redis 连不上”，会让排查方向反复横跳。

启动后立刻退出

Linux 软件包先读 journald：

journalctl -u redis-server -b -n 120 --no-pager

常见线索包括端口占用、配置行无法解析、数据目录无权限、磁盘已满、AOF 或 RDB 无法读取。对应的只读检查是：

ss -ltnp | grep ':6379'
df -h
df -i
namei -l /var/lib/redis

容器则看 docker logs 和退出码：

docker inspect redis-course --format '退出码={{.State.ExitCode}} 错误={{.State.Error}}'
docker logs --tail 100 redis-course

出现 NOAUTH 或 WRONGPASS

这两个错误反而证明网络层已经通了。NOAUTH 表示没提供凭据；WRONGPASS 表示用户名、密码或用户状态不匹配。核对客户端连接字符串、ACL 用户名和密钥来源，不要通过关闭认证来让测试变绿。

写入时报持久化或磁盘错误

redis-cli INFO persistence
redis-cli CONFIG GET dir
redis-cli CONFIG GET appendonly
df -h

如果日志指出 RDB/AOF 保存失败，先检查磁盘空间、inode、目录属主和只读挂载。直接关闭“保存失败时停止写入”的保护，只会把清晰故障变成悄悄丢失持久化能力。

Linux 启动日志出现内核告警

Redis 可能提示内存 overcommit 或透明大页设置不理想。这些不是靠重装 Redis 解决的。先记录当前值和宿主机用途，再按运维规范调整；共享服务器上的内核参数会影响其他进程，不应只为了消掉一行警告就随手修改。

sysctl vm.overcommit_memory
cat /sys/kernel/mm/transparent_hugepage/enabled

用三个问题确认你真的装明白了

最后做一次小练习：不用看前文，写下你当前环境的安装来源、服务启动者、监听地址、配置文件、数据目录、日志入口和升级方式。

接下来学习 Redis 命令时，我们会默认你已经有一套通过验收的环境。保留本章的测试前缀和检查顺序：先确认连接到的是预期实例，再开始写数据。这一个小习惯，能避开很多“命令明明正确，结果却不对”的低级事故。