看看 Redis 现在到底咋样，服务有没有正常跑着，状态得先确认清楚

（信息主要来源于Redis官方网站的文档、监控博客文章以及常见的运维实践经验。）

看看 Redis 现在到底咋样，服务有没有正常跑着，状态得先确认清楚，这事儿不能靠猜，得动手检查，最直接、最不会骗人的方法，就是用 Redis 自己提供的命令行工具进去瞧一瞧，你打开服务器的终端，输入 redis-cli 这个命令，就能连接到本机默认的 Redis 服务了，如果连接成功，命令行提示符会变成一个以 Redis 服务器地址开头的样子，0.0.1:6379>，这说明至少网络连通和基础服务是起来的,第一步算是有个好的开始。

光能连上还不够，谁知道它是不是在“假死”状态呢？所以接下来得让它干点活儿，试试它的“心跳”，在刚才那个命令行里，你输入 PING 然后按回车，Redis 精神抖擞，它会立刻回复你一个 PONG，这就好比你去拍一个睡着的人，他“嗯”了一声，说明他活着，而且意识清醒，这个 PING-PONG 就是和 Redis 之间最简单的健康检查对话。

确认了它还“活着”之后，就得看看它的“身体状况”了，也就是各种详细的指标，这时候要用到一个非常强大的命令：INFO，单单输入 INFO 会吐出一大堆信息，容易看花眼，所以一般我们会看具体的部分，输入 INFO server，这里能看到 Redis 的版本号、运行了多长时间（uptime，这个很重要，如果时间很短可能是刚重启过，需要注意）、进程号等等，特别是运行时间，一个稳定运行的 Redis 服务，其运行时间应该是很长的，如果频繁变短，那可能就是有问题,比如经常崩溃或者被人为重启。

然后要看内存情况，输入 INFO memory，这里有一大堆数字，但你主要关注两个：used_memory_human 和 used_memory_peak_human，这两个值会用人性化的单位（M 表示兆字节，G 表示千兆字节）告诉你当前用了多少内存，以及历史上最高用到过多少内存，你得确保当前用的内存别太接近你给 Redis 设置的上限（如果没设置上限，就得小心它可能把系统内存吃光），同时看看峰值内存是不是有过突然的飙升,这可能意味着有过突发的大流量或者某个大键被写入了。

接下来很关键的是看持久化，也就是 Redis 有没有把数据好好地存到硬盘上，防止断电后数据全丢，输入 INFO persistence，这里你要看 rdb_last_save_time，它告诉你最后一次成功创建快照（一种全量备份）的时间戳，你可以换算一下看看是不是最近发生的，确保备份是新的，如果是用了 AOF（一种记录所有写操作的日志），要关注 aof_last_bgrewrite_status 和 aof_last_write_status，它们的值应该是 ok，表示最近的日志重写和写入操作都成功了，如果这里不是 ok，那说明持久化可能出了故障,数据有丢失的风险。

光看静态信息也不行，得看看它现在“忙不忙”，输入 INFO stats，这里要看 instantaneous_ops_per_sec，这个值表示每秒处理的操作数，能让你感受一下当前实时流量压力大不大，同时可以看看 total_connections_received 和 rejected_connections，前者是历史总连接数，后者是被拒绝的连接数，如果被拒绝的连接数一直在涨，说明可能达到了最大客户端连接数上限,有客户端连不进来了。

还有一个简单的命令能快速看几个核心指标，redis-cli --stat，这个命令会每隔一秒刷新一次屏幕，显示客户端连接数、内存使用、以及每秒操作数等关键信息，像一个简单的实时监控仪表盘,非常适合快速瞥一眼服务的当前负荷。

除了自己动手敲命令，如果公司有监控系统（Prometheus 配上 Grafana 这种图表工具），那会更方便，运维同学通常会把上面提到的这些 Redis 指标（内存使用、连接数、操作数、持久化状态等）自动采集到监控系统里，做成一个个图表大盘，你只需要打开那个网页，就能看到 Redis 服务过去几个小时、几天的性能曲线和状态变化，一眼就能看出有没有异常波动，比如内存使用曲线是不是有持续上涨的趋势，CPU 使用率有没有突然的尖峰,这比手动检查要全面和高效得多。

有时候服务出问题不是 Redis 本身不行了，而是网络链路有问题，你可能需要在 Redis 服务器上，用 redis-cli 连上之后，故意设一个带过期时间的键，SET test_network "hello" EX 10，然后立刻在应用程序所在的机器上尝试用 redis-cli 去获取这个键，如果本机能通，应用服务器不通，或者延迟特别高，那问题就出在网络层面或者防火墙规则上，而不是 Redis 服务的罪过。

确认 Redis 状态就是一个由浅入深的过程：先 PING 通，证明它活着；再用 INFO 命令看看它的详细体检报告，重点关注内存、持久化和实时操作数；有条件的话借助监控大盘看历史趋势；最后别忘了排除网络问题，把这些点都过一遍，你心里对“Redis 现在到底咋样”基本上就有个很清楚的底了。