场景

redis提供了info指令，可以帮助用户查询redis服务运行期间内部的参数以及实时信息，根据这些信息可以帮助用户诊断问题或查看服务负载、内存压力等维度方面的信息。

info指令显示的信息繁多，分为9大块，每块都有非常多的参数，9大块如下：

1. Server：服务器运行的环境参数。
2. Clients：客户端相关信息。
3. Memory：服务器运行内存统计数据。
4. Persistence：持久化信息。
5. Stats：通用统计数据。
6. Replication：主从复制相关信息。
7. CPU：CPU使用情况。
8. Cluster：集群信息。
9. KeySpace：键值对统计数量信息。

info可以一次性获取所有的信息，也可以按照模块获取信息。

输入info获取所有信息

127.0.0.1:6379> info
# Server
redis_version:6.2.3
redis_git_sha1:00000000
redis_git_dirty:0
......

输入info memory获取内存相关信息

127.0.0.1:6379> info memory
# Memory
used_memory:1976168
used_memory_human:1.88M
used_memory_rss:8441856
used_memory_rss_human:8.05M
used_memory_peak:4990200
......

输入info replication获取主从复制相关信息

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_failover_state:no-failover

每条执行多少次指令

redis-cli info stats | grep ops

instantaneous_ops_per_sec:12

instantaneous_ops_per_sec(每秒瞬时运行次数)的值为12，意味着客户端每秒会发送12条指令到服务端执行，如果ops过高，可以通过monitor指令观察哪些key被访问的比较频繁，

monitor实时显示redis正在执行的指令，如果ops很高，那么控制就会瞬时输出很多的指令，可以通过ctrl+c中断输出。

root@f5cd3ecb4cd8:/data# redis-cli monitor
OK
1640764159.129379 [0 127.0.0.1:34272] "COMMAND"
1640764160.890701 [0 127.0.0.1:34272] "set" "hello" "1"

有多少客户端在连接

root@f5cd3ecb4cd8:/data# redis-cli info clients | grep connected_clients

connected_clients:4

connected_clients 表示目前有 4 个客户端正在与服务器建立连接，如果发现存在意料之外的连接数量，可以通过 client list 指令列出所有的客户端链接地址，确认链接源头。

root@f5cd3ecb4cd8:/data# redis-cli info stats | grep reject

rejected_connections:0

通过 rejected_connections 可以看到因为超出最大连接数限制而被拒绝连接的客户端连接次数，如果这个数字很大，可能是因为服务器的最大连接数设置的较低，可能需要调整 maxclient 参数。

占用了多少内存

通过 info memory 可以查看redis的占用内存信息。

root@f5cd3ecb4cd8:/data# redis-cli info memory | grep used | grep human

used_memory_human:1.90M # 内存分配器从操作系统分配的内存总量

used_memory_rss_human:8.05M # 操作系统(top命令)看到的内存占用

used_memory_peak_human:4.76M # Redis内存消耗的峰值

used_memory_lua_human:37.00K # lua脚本引擎占用的内存大小

如果内存占用过大，并且业务上没有可优化的空间，则需要考虑服务集群化，分摊每个服务的压力。

复制积压缓冲区有多大

root@f5cd3ecb4cd8:/data# redis-cli info replication | grep backlog

repl_backlog_active:0

repl_backlog_size:1048576 #积压缓冲区大小

repl_backlog_first_byte_offset:0

repl_backlog_histlen:0

复制积压缓冲区(buffer)的大小会影响到主从增量同步的效率，如果从节点因为网络或其他原因临时断开了对主节点的复制，这段时间的指令被存在buffer中，当从节点恢复后，可以继续通过buffer中继续同步数据，以此追赶主节点的数据，

由于buffer是环形的，如果buffer容量太小，或者从节点断开时间太长，此时buffer中的数据都会被新的数据覆盖，这时候从节点就会进入全量同步模式，将会很耗费CPU和网络资源，

积压缓冲区是共享的，不会因为从节点过多而线性增长，在实际应用中，如果实例的修改指令很频繁，就将buffer的的大小调大一些，如果比较空闲就调小一些。

sync_parial_err 表示主从增量同步失败的次数，通过该值来决定是否需要拓大积压缓冲区，如果失败的次数比较多，说明需要拓大缓冲区的大小，避免全量同步。