linux上部署 Redis 7 前应确认哪些内存、持久化和端口设置

目标状态：先把 Redis 7 的上线边界定清楚

Redis 7 在 Linux 上部署前，至少要确认三类设置：内存配置、持久化策略、监听地址和访问端口。它们决定了 Redis 是否会占满服务器内存、宕机后能恢复多少数据，以及服务是否被不必要地暴露到外部网络。

建议上线前达到以下状态：

• 已设置 maxmemory，并明确内存淘汰策略。
• 已在 RDB、AOF 或两者结合之间做出选择。
• Redis 只监听业务需要的地址和端口。
• 防火墙或安全组只放行业务来源 IP。
• 修改前已备份配置文件，重启后能用命令验证结果。

下文以 Redis 7 单实例部署为例，不涉及 Redis Cluster 或复杂高可用架构。不同 Linux 发行版、安装方式和 Redis 小版本的配置路径可能不同，操作前应先确认实际配置文件位置。

环境检查：确认 Linux、Redis 和配置文件位置

在修改配置前，先确认 Redis 服务来源。通过包管理器安装、源码编译、容器运行的路径不一样，不能直接复制配置文件路径。

常见路径如下：

先执行以下命令确认版本、进程和监听情况：

redis-server --version
ps -ef | grep '[r]edis-server'
ss -lntp | grep redis

如果 Redis 已由 systemd 托管，可以查看服务文件，确认启动时使用的配置文件：

systemctl status redis
systemctl cat redis

Ubuntu 上服务名可能是 redis-server：

systemctl status redis-server
systemctl cat redis-server

修改前先备份配置文件。下面以 /etc/redis/redis.conf 为例，实际路径请替换为你的环境路径：

sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.bak.$(date +%F-%H%M%S)

阶段一：确认内存上限和淘汰策略

Redis 主要把数据放在内存中。Linux 上部署 Redis 7 时，如果不设置内存上限，Redis 可能持续占用内存，最终触发系统 OOM，导致 Redis 或其他进程被杀掉。

计算 Redis 可用内存

maxmemory 不建议直接设置为服务器总内存。应预留给系统、后台任务、日志、监控 Agent、业务进程，以及 Redis 持久化和复制时可能产生的额外内存。

一个简单的估算方式：

Redis maxmemory ≈ 服务器总内存 - 操作系统预留 - 其他业务进程内存 - 持久化/复制预留

例如一台 8GB 内存的 Linux 服务器，只运行 Redis 和少量监控组件：

• 操作系统和基础服务预留：1GB
• 监控、日志、管理进程预留：0.5GB
• RDB/AOF 重写或后续复制预留：1GB 到 1.5GB
• Redis maxmemory 可先设置为：5GB 到 6GB

如果该服务器还运行 Web、数据库、队列等进程，应按实际进程内存重新计算，不要照搬固定比例。

可以用以下命令查看当前内存情况：

free -h
vmstat 1 5
ps aux --sort=-%mem | head

设置 maxmemory

在 Redis 配置文件中加入或修改：

maxmemory 6gb

如果实例较小，也可以使用 mb：

maxmemory 1024mb

Redis 的内存统计可通过以下命令查看：

redis-cli INFO memory

重点关注：

• used_memory_human：Redis 已使用内存。
• used_memory_peak_human：历史峰值。
• maxmemory_human：当前内存上限。
• mem_fragmentation_ratio：内存碎片相关指标，不能只看单一数值判断故障。

选择淘汰策略

maxmemory-policy 决定 Redis 达到内存上限后如何处理新写入。常见策略如下：

大多数缓存型业务可以从 allkeys-lru 或 allkeys-lfu 开始。若 Redis 存储的是不能被自动淘汰的关键数据，建议使用 noeviction，但业务代码必须处理写入失败。

配置示例：

maxmemory-policy allkeys-lru

如果使用 volatile-* 策略，要确认业务写入 key 时确实设置了 TTL。否则 Redis 达到上限后可能没有可淘汰对象，仍然返回写入错误。

阶段二：选择 RDB 或 AOF 持久化策略

Redis 持久化不是“开或不开”这么简单。RDB、AOF 的恢复速度、数据丢失窗口和磁盘压力不同。部署前应根据业务能接受的数据丢失范围来选。

RDB：适合快照恢复，可能丢失最近写入

RDB 是周期性生成快照文件。优点是文件紧凑、恢复相对快；缺点是 Redis 异常退出时，可能丢失上一次快照后的数据。

Redis 7 配置示例：

dir /var/lib/redis
dbfilename dump.rdb

save 900 1
save 300 10
save 60 10000

含义是：

• 900 秒内至少 1 次变更，触发保存。
• 300 秒内至少 10 次变更，触发保存。
• 60 秒内至少 10000 次变更，触发保存。

如果只是把 Redis 当纯缓存，且可从数据库重建数据，可以保留较宽松的 RDB 策略，甚至根据业务评估关闭持久化。但不要在没有恢复方案的情况下关闭。

AOF：适合降低数据丢失窗口，磁盘压力更高

AOF 会记录写命令。相比 RDB，它通常能降低异常退出时的数据丢失窗口。常见配置是每秒刷盘一次：

appendonly yes
appendfsync everysec

appendfsync 常见取值：

Redis 7 使用 AOF 时，可能采用多文件 AOF 机制，相关文件通常位于配置的 dir 下的 AOF 目录中。具体文件名和目录可通过当前版本配置与 INFO persistence 确认，不建议只凭旧版本经验判断。

检查持久化状态：

redis-cli INFO persistence

重点关注：

• rdb_last_bgsave_status
• aof_enabled
• aof_last_bgrewrite_status
• aof_last_write_status

如何选择

如果 Redis 用作普通缓存，源数据在数据库中，允许丢失缓存内容，可以选择 RDB 或关闭持久化，但要确保缓存重建不会压垮后端数据库。

如果 Redis 承载会话、限流状态、临时订单状态等业务数据，建议至少开启 AOF，并使用：

appendonly yes
appendfsync everysec

如果希望兼顾恢复速度和较小数据丢失窗口，可以同时开启 RDB 和 AOF。需要注意，持久化会带来磁盘写入和后台重写开销，磁盘空间和 I/O 必须提前确认。

查看磁盘空间：

df -h
du -sh /var/lib/redis 2>/dev/null

如果 Redis 数据目录所在分区空间不足，AOF 重写或 RDB 保存可能失败。上线前应确保数据目录有足够余量，不要和系统根分区挤在一起后完全不监控。

阶段三：限制监听地址和访问端口

Redis 默认端口是 6379。部署前要确认它只对必要网络开放。不要把 Redis 直接暴露在公网地址上，也不要只依赖弱密码保护。

配置 bind 和 protected-mode

如果 Redis 只给本机应用使用，建议只监听本地回环地址：

bind 127.0.0.1 ::1
protected-mode yes
port 6379

如果需要被同一内网中的应用访问，应绑定内网 IP，而不是 0.0.0.0：

bind 127.0.0.1 10.0.0.10
protected-mode yes
port 6379

其中 10.0.0.10 应替换为服务器实际内网地址。

查看本机地址：

ip addr

如果确实需要修改 Redis 端口，可以设置：

port 6380

改端口不能替代访问控制。端口变化只能减少误扫和冲突，不能视为安全措施。

设置认证或 ACL

Redis 6 以后支持 ACL。简单场景下，可以先使用 requirepass，但更细粒度的生产环境建议评估 ACL 用户和权限范围。

基础认证示例：

requirepass use-a-long-random-password-here

使用密码连接：

redis-cli -h 127.0.0.1 -p 6379 -a 'use-a-long-random-password-here' PING

命令行直接带密码可能被 shell 历史或进程列表记录。更谨慎的方式是进入 redis-cli 后执行 AUTH，或通过受控的环境变量和配置管理工具传递。

防火墙只允许业务来源

如果使用 UFW，先确认当前规则，避免误断 SSH：

sudo ufw status numbered

只允许指定业务服务器访问 Redis 端口的示例：

sudo ufw allow from 10.0.0.20 to any port 6379 proto tcp
sudo ufw deny 6379/tcp
sudo ufw status numbered

如果使用 firewalld：

sudo firewall-cmd --state
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.20" port protocol="tcp" port="6379" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port protocol="tcp" port="6379" drop'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

防火墙规则应结合云平台安全组一起检查。Linux 本机放行但安全组未放行，客户端仍然连不上；安全组放行但 Redis 绑定了 127.0.0.1，远程也无法连接。

阶段四：调整 Linux 内核相关基础项

Redis 启动时可能提示内核参数警告。上线前建议检查，但不要盲目修改生产服务器。

overcommit_memory

Redis 后台保存 RDB 或 AOF 重写时会 fork 子进程。Linux 内存分配策略过于保守时，可能导致后台保存失败。Redis 官方通常建议设置：

cat /proc/sys/vm/overcommit_memory

临时设置：

sudo sysctl vm.overcommit_memory=1

持久化设置可写入单独配置文件：

echo 'vm.overcommit_memory = 1' | sudo tee /etc/sysctl.d/99-redis.conf
sudo sysctl --system

Transparent Huge Pages

THP 可能影响 Redis 延迟稳定性。查看当前状态：

cat /sys/kernel/mm/transparent_hugepage/enabled

临时关闭：

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

持久化关闭方式与发行版和启动方式有关，可通过 systemd 服务、grub 参数或专用脚本实现。这里不建议直接给出通用覆盖命令，以免影响同机其他业务。生产环境应先确认服务器是否只运行 Redis，以及是否有统一的系统基线管理。

阶段五：应用配置并验证结果

修改 Redis 配置后，先检查配置文件是否存在明显语法问题。Redis 没有像 Nginx 那样统一的 -t 测试入口，但可以用指定配置启动到前台进行谨慎验证。生产环境不要在同一端口重复启动实例。

如果是维护窗口内操作，可以重启服务：

sudo systemctl restart redis
sudo systemctl status redis --no-pager

Ubuntu 可能是：

sudo systemctl restart redis-server
sudo systemctl status redis-server --no-pager

查看监听地址和端口：

ss -lntp | grep redis

期望结果示例：

LISTEN 0 511 127.0.0.1:6379 0.0.0.0:* users:(("redis-server",pid=1234,fd=6))

如果绑定内网 IP，应看到对应内网地址，而不是公网地址或 0.0.0.0:6379。

验证认证和基本读写：

redis-cli -h 127.0.0.1 -p 6379

进入后执行：

AUTH use-a-long-random-password-here
PING
SET deploy_check ok EX 60
GET deploy_check

返回 PONG 和 ok 说明基础访问正常。

验证内存配置：

redis-cli -a 'use-a-long-random-password-here' CONFIG GET maxmemory
redis-cli -a 'use-a-long-random-password-here' CONFIG GET maxmemory-policy
redis-cli -a 'use-a-long-random-password-here' INFO memory

验证持久化配置：

redis-cli -a 'use-a-long-random-password-here' CONFIG GET appendonly
redis-cli -a 'use-a-long-random-password-here' CONFIG GET appendfsync
redis-cli -a 'use-a-long-random-password-here' INFO persistence

注意：CONFIG GET 返回的是当前运行实例配置，不一定代表配置文件已经正确保存。上线检查时应同时核对配置文件和运行状态，避免临时修改重启后丢失。

上线检查清单：把配置和结果对应起来

上线前可以按下面顺序核对，减少遗漏。

如果 Redis 部署在云服务器上，还要检查安全组入站规则。安全组、本机防火墙、Redis bind 三者都要匹配，缺一项都可能导致连接失败或暴露面过大。

常见错误和处理方向

maxmemory 未设置，系统内存被 Redis 占满

现象通常是服务器内存持续上升，系统日志出现 OOM 记录，Redis 或其他业务进程异常退出。

检查：

redis-cli INFO memory
dmesg -T | grep -i 'out of memory\|killed process'

处理方向：

• 设置合理的 maxmemory。
• 根据业务选择 maxmemory-policy。
• 检查是否存在大量无 TTL 的缓存 key。
• 观察业务是否能处理淘汰或写入失败。

使用 volatile 策略但 key 没有过期时间

如果配置为 volatile-lru、volatile-ttl 等策略，但业务写入 key 时没有设置 TTL，达到内存上限后 Redis 可能无法淘汰数据。

检查 key 是否有 TTL：

redis-cli TTL your_key

返回：

• -1：key 存在，但没有过期时间。
• -2：key 不存在。
• 大于等于 0：剩余过期秒数。

处理方向是统一业务写入规范，缓存类 key 使用 SET key value EX seconds 或等价写法。

AOF 开启后磁盘写满

AOF 会增加磁盘写入和空间占用。如果数据目录与系统根分区共用，磁盘写满可能影响系统服务。

检查：

df -h
redis-cli INFO persistence

处理方向：

• 清理无关文件前先确认文件归属，不要直接删除 Redis AOF 或 RDB 文件。
• 调整 Redis 数据目录到空间更充足的分区。
• 检查 AOF 重写是否失败。
• 必要时在维护窗口内执行安全的 AOF 重写操作，并持续观察磁盘空间。

Redis 监听了 0.0.0.0

0.0.0.0:6379 表示 Redis 在所有网卡上监听。如果云安全组或本机防火墙配置不严，可能导致外部可访问。

检查：

ss -lntp | grep 6379

处理方向：

• 修改 bind 为 127.0.0.1 或指定内网 IP。
• 保持 protected-mode yes。
• 配置认证或 ACL。
• 用安全组和本机防火墙限制来源 IP。

修改了配置文件但重启后不生效

常见原因是改错配置文件，或者 systemd 服务启动时使用了另一个路径。

检查：

systemctl cat redis
ps -ef | grep '[r]edis-server'
redis-cli CONFIG GET dir

处理方向：

• 以 systemd 服务文件中的启动参数为准。
• 修改正确的配置文件。
• 重启服务后再次用 CONFIG GET 和 INFO 验证。

回滚：保留可恢复路径，不在故障中临时猜配置

上线修改前的备份文件就是第一层回滚手段。若重启后 Redis 无法启动，先查看服务日志：

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

Ubuntu 服务名可能是：

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

如果确认是配置变更导致，可以恢复备份：

sudo cp /etc/redis/redis.conf.bak.YYYY-MM-DD-HHMMSS /etc/redis/redis.conf
sudo systemctl restart redis

请将备份文件名替换为实际文件名。恢复后继续验证：

systemctl status redis --no-pager
ss -lntp | grep redis
redis-cli INFO memory
redis-cli INFO persistence

如果问题与端口访问有关，不要急于放开所有来源。应先从本机连接、内网连接、防火墙、安全组逐层检查。临时开放公网端口只会扩大风险，不能作为常规排障方式。

后续优化可以按顺序推进：先稳定单实例的内存上限、持久化和端口访问，再接入监控告警；确认慢查询、命中率、淘汰次数和持久化失败告警后，再评估主从复制、哨兵或更复杂的 Redis 架构。Redis 7 的具体配置项可能随发行包和小版本存在差异，生产变更前应以当前服务器上的配置文件、redis-server --version 和官方文档为准。