redis的info命令透露的信息还是蛮多的，需要重点掌握
- 聚合操作获取slave信息，建立连接进行操作
@Autowired
private Jedis jedis;
private void getSlaveInfo(boolean first) {
String host = null;
String port = null;
String info = jedis.info();
for (String str : info.split("\n")) {
if (str.contains("slave0")) {
for (String ss : str.split(",")) {
if (ss.contains("ip")) {
host = ss.substring(ss.indexOf("=") + 1);
}
if (ss.contains("port")) {
port = ss.substring(ss.indexOf("=") + 1);
}
}
}
}
}
- 碎片整理
内存碎片会降低 Redis 的内存使用率，我们可以通过执行 INFO 命令，得到这个实例的内存碎片率：
# Memory
used_memory:5709194824
used_memory_human:5.32G
used_memory_rss:8264855552
used_memory_rss_human:7.70G
...
mem_fragmentation_ratio:1.45
这个内存碎片率是怎么计算的？
很简单，mem_fragmentation_ratio = used_memory_rss / used_memory。
其中 used_memory 表示 Redis 存储数据的内存大小，而 used_memory_rss 表示操作系统实际分配给 Redis 进程的大小。
如果 mem_fragmentation_ratio > 1.5，说明内存碎片率已经超过了 50%，这时我们就需要采取一些措施来降低内存碎片了。
解决的方案一般如下：
- 如果你使用的是 Redis 4.0 以下版本，只能通过重启实例来解决
- 如果你使用的是 Redis 4.0 版本，它正好提供了自动碎片整理的功能，可以通过配置开启碎片自动整理
Redis 碎片整理的参数配置如下：
# 开启自动内存碎片整理（总开关）
activedefrag yes
# 内存使用 100MB 以下，不进行碎片整理
active-defrag-ignore-bytes 100mb
# 内存碎片率超过 10%，开始碎片整理
active-defrag-threshold-lower 10
# 内存碎片率超过 100%，尽最大努力碎片整理
active-defrag-threshold-upper 100
# 内存碎片整理占用 CPU 资源最小百分比
active-defrag-cycle-min 1
# 内存碎片整理占用 CPU 资源最大百分比
active-defrag-cycle-max 25
# 碎片整理期间，对于 List/Set/Hash/ZSet 类型元素一次 Scan 的数量
active-defrag-max-scan-fields 1000
- expired_keys 这一项，它代表整个实例到目前为止，累计删除过期 key 的数量。
你需要把这个指标监控起来，当这个指标在很短时间内出现了突增，需要及时报警出来，然后与业务应用报慢的时间点进行对比分析，确认时间是否一致，如果一致，则可以确认确实是因为集中过期 key 导致的延迟变大。
- Redis 上执行 INFO 命令，查看 latest_fork_usec 项
# 上一次 fork 耗时，单位微秒
latest_fork_usec:59477
这个时间就是主进程在 fork 子进程期间，整个实例阻塞无法处理客户端请求的时间。
如果你发现这个耗时很久，就要警惕起来了，这意味在这期间，你的整个 Redis 实例都处于不可用的状态。
