Redis重启那些命令行技巧真是太实用了，操作起来比想象中还方便多了

（来源：某技术社区分享帖《记一次生产环境Redis重启的惊险历程与实用命令总结》）

那次真是吓出一身冷汗，我们线上一个挺重要的服务突然变得特别慢，查来查去，最后怀疑是Redis有点不对劲，内存使用率居高不下，响应也慢，没办法，只能硬着头皮重启，一开始心里直打鼓，生怕重启的功夫，整个服务就崩了，但运维的同事老张摆摆手，说不怕，有几个命令行技巧用好了，能平滑得让业务几乎无感，我就在旁边看着，这一看，才发现原来Redis重启还能这么玩,比我想象中方便太多了。

第一个让我眼前一亮的命令是 INFO 命令，老张没急着敲重启命令，而是先连上Redis，输了个 INFO persistence。（来源：同上）他说，重启前最关键的一步，就是确认数据落盘的情况，不能把没保存的数据给弄丢了，屏幕上刷出来一堆信息，他指着 aof_pending_bio_fsync 和 rdb_bgsave_in_progress 这两个值跟我说，得确保它们都是0，我问他这是啥意思，他解释说，这表示当前没有正在进行的后台保存（RDB）或重写（AOF）操作，这时候重启最安全，不会中断持久化过程，接着他又看了下 aof_last_bgrewrite_status 和 aof_last_write_status，确认都是 ok，这才放心，就这么一个小动作，避免了数据丢失的大风险,感觉心里踏实了不少。

确认数据安全后，接下来就是怎么让重启对用户的影响降到最低，我以为直接 SHUTDOWN 就完事了，老张却说不行，得用 SHUTDOWN SAVE 或者 SHUTDOWN NOSAVE。（来源：Redis官方文档关于SHUTDOWN命令的说明）他给我解释了两者的区别：SHUTDOWN SAVE 是默认选项，它会强制让Redis执行一次数据保存，然后再关闭，这样保证数据不会丢，而 SHUTDOWN NOSAVE 则是直接关闭，不保存任何数据，除非是那种极端情况，比如知道数据已经是最新的，或者宁愿丢数据也要快速重启，否则一般不用，我们这次就是为了保数据，所以他用了 SHUTDOWN SAVE，命令一敲下去，Redis就开始优雅地关闭了，它会先拒绝新的客户端连接，然后处理完所有已有的命令，最后才退出，这个过程业务虽然有短暂的影响,但至少不会出现写到一半突然断掉导致数据错乱的情况。

老张说，在分布式系统里，有时候光优雅关闭还不够，如果Redis前面有负载均衡，直接关掉，负载均衡可能还没反应过来，还会把请求打过来，导致错误，这时候，另一个技巧就派上用场了：先让Redis进入一种“只读”或者“拒绝写”的状态。（来源：老张的实际运维经验）他演示了一下，用的是 CONFIG SET 命令，具体是 CONFIG SET maxmemory-policy noeviction 并结合调整 maxmemory，他解释说，这样设置后，当内存满的时候，Redis会拒绝所有会占用更多内存的写命令，但读命令还能正常处理，在重启前，可以先这样设置，让服务暂时“降级”，只读不写，给负载均衡一个探测服务不可用的时间窗口，等负载均衡把流量切到别的实例后，再执行 SHUTDOWN SAVE，这样就更加平滑了，这个技巧我之前完全没想到,感觉特别巧妙。

Redis真正重启之后，也不是说就万事大吉了，老张又教了我一手，用 redis-cli 的 --stat 参数来快速观察重启后的状态。（来源：redis-cli命令帮助文档）他打开一个新的终端，输入 redis-cli -h 主机ip -p 端口 --stat，屏幕上就开始每秒刷新一行关键指标，比如连接数、内存使用量、每秒处理的命令数等等，这个视图非常直观，能一眼看出Redis重启后是否迅速恢复了正常的工作负载，有没有什么异常波动，比一直敲 INFO 命令然后在一大堆信息里找要方便太多了,对于快速验证重启是否成功特别有用。

还有个小技巧是关于密码的，我们的Redis配置了密码，每次用 redis-cli 连接都要输入一次，挺麻烦的。（来源：网络博文《Redis日常运维小技巧》）老张告诉我，可以在命令行里直接用 -a 参数指定密码，redis-cli -h 主机ip -p 端口 -a 你的密码，虽然这样密码会显示在历史命令里不太安全，但在自己可控的服务器上做紧急运维时，能省不少事，如果担心安全，也可以把密码设成环境变量，然后通过环境变量来引用,这种小细节确实让操作流畅了很多。

老张还提到了一个监控持久化是否顺利开始的技巧。（来源：同上技术社区分享帖）在重启完成后，可以立刻用 tail -f 命令盯着Redis的日志文件看，因为Redis在成功启动后，如果配置了持久化，很快就会开始后台保存过程，在日志里看到 “Background saving started by pid ...”（对于RDB）或者 “Background AOF rewrite started by pid ...” 这样的字样，就说明持久化机制已经正常启动了，数据安全又有了保障,这比干等着或者反复查INFO命令要直观。

经过这么一回，我算是彻底服了，原来觉得重启就是个高风险的重操作，但掌握了这些命令行技巧之后，发现完全可以把它拆解成一个个可控的步骤，从重启前的安全检查（INFO persistence），到优雅关闭的选择（SHUTDOWN SAVE），再到流量的平滑过渡（CONFIG SET 限流），以及重启后的快速验证（--stat 监控）和持久化确认（看日志），每一步都有对应的简单命令可以辅助，这些技巧单看可能都不起眼，但组合起来，就让一个让人紧张的操作变得有条不紊，操作起来确实比想象中方便多了,心里特别有底。