★ FEATURED ARTICLE 1. 从一台服务器说起为什么先从“简单操作”开始前阵子帮同事处理一台测试服务器的临时任务机器上装着一个 Redis密码没人记得清楚配置文件被改得乱七八糟数据动不动就丢。当时脑子里冒出来的第一个念头就是如果一开始就有人把“linux redis简单操作”这几个关键动作做扎实后面根本不会踩这么多坑。这篇内容不是那种几十页的《Redis 从入门到精通》而是把我实际用过、验证过、也踩过坑的操作整理了一遍。适合刚接触 Linux 和 Redis 的读者也适合那些已经装了 Redis 但只敢用 ping、set、get 的同学。我会从安装前的准备讲起一直讲到配置、常用命令、持久化备份最后给出一份问题排查清单。看完之后你应该能在一台全新的 Linux 机器上自己完成 Redis 的部署、安全加固、日常操作和基础备份不会遇到问题时只能到处百度。先交代一下我的工作环境日常主要接触 Debian 系和 RedHat 系服务器Redis 版本跨度从 5.x 到 7.x 都有。命令本身差异不大配置文件里的关键参数也基本一致所以下面大部分内容换到主流发行版上都能直接用。个别差异点我会单独标出来。2. 启动之前配置文件里的几个关键决定很多人习惯装完 Redis 之后直接systemctl start redis然后就开始 set、get。这在本地虚拟机里玩玩没问题一旦放到真实的服务器上第一步就错了。Redis 默认配置考虑的是“能跑起来”而不是“跑得安全、跑得稳”。我处理过好几次线上事故根因都是默认配置下端口直接暴露又没设密码被人扫到后写了一些乱七八糟的 key。2.1 第一个必须改的参数protected-modeRedis 从 3.2 版本开始默认开启 protected-mode它的作用是当 Redis 没有显式配置 bind 地址又没有设置 requirepass 时只允许本机回环地址 127.0.0.1 访问。这是一个保命设计。但问题是很多人修改配置时会把 protected-mode 手动改成 no理由往往是“客户端连不上”。连不上的真正原因通常是 bind 配置不对而不是 protected-mode 挡住了请求。我建议绝大部分场景下保持 protected-mode yes然后用 bind 明确指定监听地址# 只监听本机回环地址 bind 127.0.0.1 # 监听本机回环和内网地址注意生产环境不要直接写 0.0.0.0 bind 127.0.0.1 192.0.2.10这里有个常见误区bind 后面跟的地址是“ Redis 允许外来连接访问的本地接口地址”不是“允许访问的客户端来源地址”。如果你写bind 0.0.0.0意味着所有网络接口都可以访问配合空密码那差不多等于裸奔。安全一点的思路是先用 bind 限制到具体网卡 IP再通过防火墙控制来源 IP 范围。2.2 永远不要跳过 requirepass设置密码这件事现在的 Redis 默认配置已经不推荐用requirepass明文写在配置文件里了更推荐用user方式创建独立账号。但对大多数内部系统来说requirepass仍然是最简单、最容易维护的方案。我习惯把所有实例统一用一个强密码写入配置文件requirepass 请替换成随机生成的长密码注意设置 requirepass 之后连接时必须先认证不然连ping都会报NOAUTH Authentication required。很多人就是在这一步卡住然后以为 Redis 坏了。我自己常用的认证方式有三种# 方式一连接时直接带密码 redis-cli -h 127.0.0.1 -p 6379 -a 你的密码 # 方式二先连接再认证 redis-cli -h 127.0.0.1 -p 6379 auth 你的密码 # 方式三通过环境变量传递密码避免出现在 shell 历史里 export REDISCLI_AUTH你的密码 redis-cli -h 127.0.0.1第三种方式我比较推荐因为-a参数会被ps命令直接看到等于把密码暴露给了同一个机器上能执行 ps 的用户。REDISCLI_AUTH 也不是完全保险至少不会出现在进程列表里那么显眼。个人实践里最省心的还是让应用通过配置中心或者环境变量统一管理密码不要在命令行里裸传。2.3 禁用危险命令给自己留条后路Redis 里有些命令在生产环境属于“雷区”比如FLUSHALL、FLUSHDB、KEYS、CONFIG、EVAL。不是说完全不能用而是不能放任任何连上 Redis 的人都能用。我习惯在配置里直接禁用或者重命名rename-command FLUSHALL rename-command FLUSHDB rename-command KEYS rename-command CONFIG 重命名为空字符串表示彻底禁用。但这会带来一个问题如果以后你自己想用同样用不了。更灵活的做法是把 KEYS 重命名为一个不那么显眼的内部名字或者干脆只用SCAN代替。关于 SCAN 后面会专门提到。另外提醒一句改完配置一定要重启或执行CONFIG REWRITE并且重启前先redis-cli config get requirepass之类的命令确认当前配置能正常读取。我见过有人改完配置没保存一个重启把刚才的密码设置全丢了。3. 入门必会redis-cli 下的高频操作Redis 本身是一个数据结构服务器但大多数人的第一需求其实是“缓存”。日常操作翻来覆去就是连接、读写、设置过期时间、查看状态。我把这些高频操作压缩成了一套“肌肉记忆流程”每次排查问题都会先走一遍。3.1 连接、认证、切换库连接命令前面已经写过。这里补充几点端口默认 6379如果是自定义端口必须用-p指定。Redis 默认有 16 个逻辑库编号 0 到 15用SELECT切换# 切换到 2 号库 select 2 # 查看当前库有多少个 key dbsize不同业务尽量不要混在同一个 Redis 实例的不同库里虽然 Redis 支持多库但运维和排查时心智负担会变大。我见过某公司的项目把 session、缓存、队列分别放在 0、1、2 三个库里结果线上排查时经常搞错业务对应哪个库。更推荐的做法是不同用途拆成不同 Redis 实例或者至少用 key 前缀区分例如order:12345、session:abcdef。3.2 String、Hash、List 的实战用法String 是最常用的缓存序列化后的 JSON 对象、计数器、分布式锁都用它。基本操作set user:1001 {name:test} get user:1001 # 设置同时带过期时间单位秒 set user:1001 {name:test} ex 3600 # 做计数器 incr page_view incrby page_view 10过期时间我建议在写数据时就指定而不是写入之后再单独执行EXPIRE。因为万一两次命令之间服务崩溃key 就成了永不过期的脏数据。即使要用 EXPIRE也要确认返回值。返回 1 表示设置成功返回 0 表示 key 本身不存在。Hash 适合存储对象属性修改某一个字段时不用整个字符串读写hset user:1001 name 张三 age 30 hgetall user:1001 hget user:1001 name hincrby user:1001 age 1用 Hash 保存用户信息比 String 拼接 JSON 方便很多也更容易做部分更新。缺点是客户端要理解 Hash 结构适合内部系统直接操作。List 一般用于简单队列比如异步任务列表lpush task_queue {job:1} rpop task_queue llen task_queueLPUSH从左边推入RPOP从右边取出这样形成 FIFO 队列。需要注意List 的阻塞版本BRPOP更适合消费者循环避免空轮询。示例brpop task_queue 5这个命令表示从队列右边取一个数据5 秒内如果没有数据就超时返回。不要把超时设成 00 表示永久阻塞。3.3 过期时间与键管理查看 key 剩余过期时间ttl user:1001返回 -1 表示永久有效-2 表示 key 已不存在。这是排查看数据“为什么消失”时最常用的一对返回值。查找 key 不能用 KEYS因为它会阻塞 Redis 主线程。正确姿势是用 SCAN 游标遍历scan 0 match user:* count 100第一次执行时游标填 0返回的结果里有新的游标值和一批 key。如果返回的游标不是 0就继续用这个游标迭代直到游标回到 0。整个过程不阻塞适合线上使用。删除 key 用DEL批量删除没有原生命令我一般这么写redis-cli --scan --pattern user:* | xargs redis-cli del这个方案有个坑当 key 数量很大时xargs可能产生多条命令但每条命令的参数数量有限制。实际测试我习惯分批操作或者用脚本通过 SCAN 一次性收集后再分批 DEL。4. 数据安全持久化和备份恢复实操“Redis 重启后数据全没了”——这句话我在各种群里见过无数次。大多数情况不是 Redis 的 bug而是根本没搞懂 RDB 和 AOF 的区别或者配置没生效。4.1 RDB 与 AOF 的选择逻辑RDB 是内存快照把某个时间点的全量数据写入磁盘文件默认文件名 dump.rdb。优点是恢复速度快、文件紧凑缺点是两次快照之间的数据可能丢失。AOF 是追加写日志把每次写命令记录到文件里。恢复时重放日志就能还原数据。优点是丢失数据少缺点是文件大、恢复慢。对大部分场景我给出的建议是混合模式aof-use-rdb-preamble yesRedis 同时启用 RDB 和 AOFAOF 文件开头放一个 RDB 快照后面追加增量修改。这样重启时加载速度比纯 AOF 快数据安全性也更好。配置文件里需要关心的几个参数参数我常用的配置说明savesave 900 1、save 300 10、save 60 10000默认快照触发频率生产环境建议保留appendonlyyes开启 AOFappendfsynceverysec每秒刷盘性能与安全的折中auto-aof-rewrite-percentage100AOF 文件超过上次重写 100% 时触发重写auto-aof-rewrite-min-size64mbAOF 至少达到 64MB 才重写不建议把appendfsync改成 always虽然理论上最安全但写性能会明显下降。everysec 丢数据窗口最多一秒绝大多数业务都能接受。如果你连一秒都不能接受应该优先考虑更强的 infrastructure而不是纠结 Redis 这个参数。4.2 一次完整的备份与恢复流程我自己的备份习惯是用BGSAVE生成 RDB 快照再把 dump.rdb 复制走。注意SAVE命令会阻塞 Redis线上千万不要手动执行除非你明确知道当前流量很低。备份命令流程# 触发后台快照 redis-cli -a 你的密码 bgsave # 确认执行成功返回 Background saving started # 查看 RDB 文件信息 redis-cli -a 你的密码 info persistenceinfo persistence 输出片段里重点看rdb_last_bgsave_status返回 ok 才表示快照成功。然后找到 RDB 文件位置# 在配置文件中查看 dir 参数 redis-cli -a 你的密码 config get dir默认 RDB 文件名是 dump.rdb直接复制cp /var/lib/redis/dump.rdb /backup/redis/$(date %F).rdb恢复流程更需要注意顺序先停 Redis再把备份文件复制回数据目录最后启动。如果 Redis 正在运行时就覆盖 dump.rdb内存里的数据会在下一次保存时把文件重新覆盖等于白恢复。systemctl stop redis cp /backup/redis/2025-01-01.rdb /var/lib/redis/dump.rdb chown redis:redis /var/lib/redis/dump.rdb systemctl start redis启动后马上验证 key 数量是否吻合不要等业务发现异常。4.3 备份中的常见误区第一个误区以为 RDB 文件可以直接在另一台 Redis 版本更高的机器上加载。Redis 对 RDB 格式有向前兼容要求但大版本跨越太大仍然可能加载失败。我建议备份恢复时尽量使用相同大版本的 Redis非要跨版本就先在一台临时机器上测试。第二个误区AOF 文件损坏后不知道怎么办。如果 Redis 启动时报Bad file format reading可以用redis-check-aof工具修复。注意这个操作会截断损坏部分理论上丢失最后一部分增量数据。redis-check-aof --fix appendonly.aof第三个误区不做定时备份。很多团队只配置了 RDB 和 AOF以为这就叫“备份”。实际上 AOF 文件被误删或磁盘损坏时Redis 本身无能为力。至少要有一个异地或不同目录的定时任务配合监控检查备份文件大小是否正常。5. 遇到问题别慌问题速查与踩坑记录我把日常排查过的高频问题整理成了一份清单碰到问题时按图索骥比盲目查日志快得多。5.1 连接类故障排查连接不上时我会按顺序检查这几个命令telnet 127.0.0.1 6379先确认端口通不通。端口通但redis-cli还是报 Connection refused多半是 Redis 只在别的 IP 上监听。然后检查 bind 配置和防火墙。最容易被忽略的是云服务器安全组和 iptables。配置层面 Redis 设置了 bind 内网 IP但外部访问仍然依赖防火墙放行。这个顺序经常让人绕圈子明明配置没问题就是连不上结果发现是安全组忘了加规则。还有一类连接超时问题常见原因是 Redis 所在的机器负载太高或者网络线路质量差。用redis-cli --latency可以测一下客户端到服务器的时延连续按 CtrlC 退出如果看到明显的 spike就要检查是网络问题还是 Redis 慢命令。5.2 数据异常问题排查key 突然消失先看 TTL 和内存淘汰。# 查看 redis 是否设置了最大内存 config get maxmemory # 查看淘汰策略 config get maxmemory-policy如果maxmemory设了值而maxmemory-policy是noevictionRedis 在内存满了之后写命令直接报 OOM 错误。如果策略是allkeys-lru那么任何 key 都可能被淘汰不光是设置了过期时间的 key。这是一个经典的生产事故缓存 key 全消失原因是 DB 数据量太大Redis 内存满了按 LRU 策略把热 key 也挤掉了。解决方式通常是拆分业务、扩大内存、或者换用更精确的淘汰策略。写入报READONLY You cant write against a read only replica说明你连到了从节点。从节点默认只读如果业务不能接受临时只读需要检查应用连接的地址是不是主节点。不要直接改replica-read-only no那只是掩盖问题。5.3 内存与性能观察入门不用装额外的监控软件Redis 自身就能提供很多信息。INFO命令输出一堆指标我重点看这几个# 内存 used_memory_human used_memory_peak_human maxmemory_human # 命中率 keyspace_hits keyspace_misses # 连接 connected_clients blocked_clients命中率计算keyspace_hits / (keyspace_hits keyspace_misses)。命中率偏低说明缓存设计有问题大量请求没打到缓存可能都在穿透到数据库。连接数突然飙高时先看connected_clients和blocked_clients如果 blocked 很高通常是客户端用了阻塞命令比如 BRPOP或者长时间持有连接。可以临时调低timeout参数断开空闲连接但会影响长连接应用。慢命令排查slowlog get 10生产环境建议设置slowlog-log-slower-than 10000单位微秒10ms一旦出现慢命令重点看是不是KEYS、HGETALL、大集合操作。优化手段无非是改 SCAN、拆分 key、减少单次取数据量。6. 写在最后的几条个人心得聊了这么多最后再说几句我自己的习惯也许能帮你减少踩坑次数。新装 Redis 时不要把全部信任交给默认配置。生产可用的最小配置可以这么起步bind 指定内网 IP、requirepass 设置强密码、protected-mode 保持 yes、rename-command 禁用高危命令、appendonly 打开。这套配置我放在一个模板里每次部署都是从这个模板改而不是每次从头敲。磁盘空间紧张时Redis 频繁写 RDB 会失败。如果info persistence里rdb_last_bgsave_status是 err先看磁盘还有多少剩余空间。我还碰到过一次 dump.rdb 权限不对导致 BGSAVE 一直失败排查了好久才想起来是手工复制文件时把属主改了。复制 RDB 文件后一定要执行chown redis:redis或者直接用install -o redis -g redis。连接不上时在自己没有确认防火墙、bind、requirepass、端口监听四个环节之前不要轻易改 protected-mode。它往往是挡住外部扫描的第一道防线关掉容易再想保护起来就麻烦了。根据我个人实践Redis 的日常操作并不复杂难的从来不是命令本身而是对配置文件和数据生命周期的敬畏。写操作之前先想清楚数据丢了能不能接受能接受就大胆用不能接受就提前开持久化、做好备份、写好恢复演练。把这个习惯养成之后使用 Redis 的心态会稳定很多。
阅读完成 · 觉得有帮助？
