Redis 部署教程：缓存服务安装与持久化配置

摘要

Redis 常用于缓存热点数据、存储会话和实现分布式锁，能显著降低后端数据库压力。本文完成 Redis 的部署，涵盖安装、访问控制与密码设置、两种持久化机制的选择、内存上限与淘汰策略、连接验证与性能检查，以及自建与托管服务的适用场景对比。文中重点说明未做访问控制的 Redis 面临的实际风险。

一、自建还是用托管服务

先明确这个选择，它决定了后面的工作量。

自建 Redis 部署在自己的服务器上，成本只有服务器费用，参数完全可控。代价是持久化配置、主备切换、故障恢复、版本升级、监控告警都要自己负责。

托管的分布式缓存数据库由平台提供服务。腾讯云的分布式缓存数据库采用双机热备架构，主机故障后服务秒级切换到备机且不影响线上业务，提供实例数据定时自动备份与手动备份，支持在控制台一键扩容且不影响业务，并提供出入网流量、Set/Get 数、CPU 负载、QPS 等三十余项监控指标和自定义告警策略。

选择建议：

有一点需要澄清：很多人认为「缓存丢了无所谓，重新查数据库就行」，因此觉得自建足够。这在纯缓存场景成立，但如果 Redis 还承担了会话存储、分布式锁或队列，丢失会直接影响业务。部署前先明确它在你的架构中承担什么角色。

本文讲自建流程。如果判断更适合托管服务，后面的访问控制、持久化概念和连接排查部分仍然适用。

二、资源规划

内存规划是这里的核心。Redis 把数据全部放在内存中，内存容量直接决定能缓存的数据量。

估算方式：预估缓存的数据总量，再预留 30% 左右余量给运行开销和内存碎片。如果开启了快照式持久化，生成快照时可能需要额外内存，规划时要留出空间。

不要把内存配满。 系统本身和其他进程也需要内存，Redis 占满物理内存会导致系统开始使用交换空间，性能会急剧下降，反而不如不缓存。

三、安装 Redis

Ubuntu 与 Debian：

sudo apt update
sudo apt install -y redis-server

确认服务状态：

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

也可以用容器方式部署：

services:
  redis:
    image: redis:7-alpine
    ports:
      - "127.0.0.1:6379:6379"
    volumes:
      - redis-data:/data
      - ./redis.conf:/usr/local/etc/redis/redis.conf:ro
    command: redis-server /usr/local/etc/redis/redis.conf
    restart: unless-stopped

volumes:
  redis-data:

容器方式注意 redis-data 卷必须持久化，否则重启后持久化文件会丢失。端口绑定到 127.0.0.1 是有意为之，原因下一节说明。

四、访问控制，这一节最重要

Redis 默认配置在早期版本中不要求密码，且如果监听在公网地址上，任何人都能连入并读写全部数据。 这是自建 Redis 最常见也最严重的安全问题。公网上有持续扫描 6379 端口的行为，一台无密码且对外开放的 Redis 通常在很短时间内就会被发现。

被入侵后的实际后果包括：缓存数据被读取（可能包含会话令牌、用户信息）、数据被清空导致服务异常、Redis 被写入恶意内容，严重时攻击者可能利用某些配置获得服务器权限。

必须做的三件事：

第一，设置密码

编辑配置文件：

sudo nano /etc/redis/redis.conf

找到并设置：

requirepass 替换为足够长的随机密码

密码要足够长。Redis 处理请求很快，短密码在暴力尝试面前几乎没有防护作用。生成一个强密码：

openssl rand -base64 32

第二，限制监听地址

bind 127.0.0.1

如果应用和 Redis 在同一台服务器，保持只监听本机是最安全的做法，完全不暴露端口。

需要跨机器访问时，改为监听内网地址：

bind 10.0.1.5

填具体的内网 IP，而不是 0.0.0.0。

第三，端口不对公网放通

6379 端口绝对不要对公网开放。 在控制台配置防火墙或安全组时，来源必须填写应用服务器的具体 IP 或内网网段，不要填 0.0.0.0/0。轻量应用服务器在实例详情页的「防火墙」页签添加规则时可指定来源；云服务器 CVM 在安全组入站规则中同样支持按网段限定。

更稳妥的做法是让应用服务器和 Redis 处于同一私有网络，通过内网通信，公网完全访问不到。

额外加固

重命名或禁用高危命令，避免误操作或被利用：

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""

FLUSHALL 会清空所有数据，禁用它能避免一次误操作导致全部缓存丢失。

修改后重启：

sudo systemctl restart redis-server

五、持久化配置

Redis 提供两种持久化机制，理解差异才能选对。

快照方式：按配置的条件把内存数据整体写入文件。优点是文件紧凑、恢复快、对性能影响小。缺点是两次快照之间的数据在意外宕机时会丢失。

追加日志方式：把每个写操作追加记录到日志文件。优点是数据丢失窗口小，缺点是文件较大、恢复较慢。

配置示例：

# 快照：900秒内有1次写入、300秒内有10次、60秒内有10000次则触发
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis

# 追加日志
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

appendfsync everysec 表示每秒同步一次日志到磁盘，在性能和安全之间取平衡，最多丢失一秒的数据。设为 always 每次写入都同步，最安全但性能开销明显；设为 no 由系统决定同步时机，性能最好但丢失风险最大。

怎么选：

需要提醒的是：持久化不等于备份。 持久化文件和 Redis 在同一台机器上，机器故障时会一起丢失。真正的备份需要把文件复制到其他位置。

六、内存上限与淘汰策略

这是自建 Redis 最容易出问题的配置项。不设内存上限时，数据持续写入会耗尽服务器内存，最终导致 Redis 被系统终止或整台机器卡死。

maxmemory 2gb
maxmemory-policy allkeys-lru

maxmemory 建议设为服务器可用内存的 60%～70%，留出空间给系统和持久化操作。

淘汰策略的选择：

纯缓存用 allkeys-lru，存储会话或重要数据用 volatile-lru 并给缓存键设置过期时间。 如果用了 noeviction 又不清理数据，内存满后写入会直接失败，应用会开始报错。

七、验证部署是否可用

服务正在运行且监听正确地址

sudo systemctl status redis-server --no-pager
sudo ss -lntp | grep 6379

确认监听地址符合预期。如果本意是只监听本机却显示 0.0.0.0，说明配置未生效。

密码认证已生效

先验证无密码连接会被拒绝：

redis-cli ping

应返回认证错误。这一项必须实测——如果返回 PONG，说明密码没配上，服务处于无保护状态。

带密码连接：

redis-cli -a '你的密码' ping

返回 PONG 即正常。

读写功能正常

redis-cli -a '你的密码' set testkey "hello"
redis-cli -a '你的密码' get testkey
redis-cli -a '你的密码' del testkey

持久化配置已加载

redis-cli -a '你的密码' config get save
redis-cli -a '你的密码' config get appendonly
redis-cli -a '你的密码' config get maxmemory

返回值应与配置文件一致。

持久化文件确实在生成

ls -lh /var/lib/redis/

应能看到快照文件或日志文件，且修改时间在合理范围内。

从应用服务器可以连接

跨机器部署时，在应用服务器上测试：

redis-cli -h Redis服务器内网IP -p 6379 -a '密码' ping

持久化真的能恢复数据。这一项建议在正式使用前做一次：写入若干数据，重启 Redis 服务，确认数据仍然存在。

redis-cli -a '密码' set persist-test "value"
sudo systemctl restart redis-server
redis-cli -a '密码' get persist-test

能取到值说明持久化生效。取不到说明持久化配置有问题，这在真实故障时才发现就晚了。

八、常见问题与排查

连接被拒绝

按顺序检查：服务是否运行；监听地址是否包含客户端能访问的地址；端口是否在控制台放通且来源正确；密码是否正确。

提示需要认证

客户端未提供密码或密码错误。注意在命令行用 -a 传密码时，密码可能出现在进程列表和历史记录中。生产环境建议用配置文件或环境变量传递。

内存占用持续增长

检查是否设置了 maxmemory。未设置时 Redis 会一直写入直到耗尽系统内存。同时检查缓存键是否设置了过期时间，没有过期时间的键在 volatile-lru 策略下不会被淘汰。

查看内存使用情况：

redis-cli -a '密码' info memory

写入操作返回错误

内存达到上限且淘汰策略为 noeviction。要么调大内存上限，要么改用允许淘汰的策略，要么清理不需要的数据。

重启后数据丢失

持久化未正确配置或未生效。检查配置项、数据目录权限、磁盘空间。数据目录无写权限时持久化会静默失败。

响应变慢

检查是否有慢查询：

redis-cli -a '密码' slowlog get 10

常见原因是执行了遍历大集合的命令。生产环境避免使用会阻塞的批量操作命令，改用渐进式的替代命令。

内存碎片率高

redis-cli -a '密码' info memory | grep fragmentation

碎片率明显偏高时可以考虑开启自动碎片整理，但它会消耗一定 CPU，需要权衡。

九、备份与维护

备份持久化文件

sudo systemctl stop redis-server
sudo tar -czf ~/redis-backup-$(date +%Y%m%d).tar.gz -C /var/lib/redis .
sudo systemctl start redis-server

不希望停服时，可以触发一次后台快照再复制文件：

redis-cli -a '密码' bgsave
sleep 5
sudo cp /var/lib/redis/dump.rdb ~/redis-$(date +%Y%m%d).rdb

把备份同步到对象存储。备份文件可能包含会话令牌等敏感信息，存储桶权限必须设为私有。

恢复演练

用备份文件在另一个环境启动 Redis，确认数据完整。这能验证备份是否真的可用。

变更前创建快照：调整配置或升级版本前给实例创建快照。回滚会把整块系统盘恢复到快照时间点，之后写入的数据会被清除，运行中的实例会自动关机。使用存储型套餐的实例不支持创建快照。

日常检查

• 关注内存使用率，接近上限时评估是否需要扩容或调整淘汰策略。
• 定期查看慢查询日志。
• 确认持久化文件在正常生成。
• 检查是否有异常的连接来源。

安全底线

• 密码必须设置且足够长。
• 6379 端口不对公网开放。
• 高危命令重命名或禁用。
• 定期更换密码，密码不与其他系统复用。
• 不要在 Redis 中存储明文密码、完整的支付信息等高敏感数据。

关于数据内容

Redis 中常存放会话数据，可能包含用户标识和登录状态。这属于个人信息范畴，要按最小必要原则存储，设置合理的过期时间，不要长期保留不再需要的会话数据。

部署完成后，如果业务对缓存可用性要求提升、需要故障自动切换，或需要完善的监控告警，可以评估迁移到托管服务。

需要双机热备、自动备份和一键扩容能力的业务场景，分布式缓存数据库 提供主备架构与三十余项监控指标，能省去自建高可用的工作；学习验证和开发测试环境用云服务器 CVM 自建更灵活，备份归档可使用对象存储 COS。