Redis性能监控问题

Java艺术 2021-09-09

401

关注“Java艺术”一起来充电吧!

并发数上升，到底是哪个服务处理能力到了瓶颈，还是Redis性能到了瓶颈，只有找出是哪里的性能问题，才能对症下药。所以，了解redis的一些运维知识能够帮助我们快速判定是否Redis集群的性能问题。

redis-cli命令的 --stat选项

关于stat选项，官网也是介绍的比较简单。使用redis-cli命令加上stat选项可以实时监视redis实例，比如当前节点内存中缓存的 key总数以及每秒处理请求数等。stat默认每隔一秒会输出一行信息，如果需要改变频率可使用-i <interval> 指定频率，单位为秒，如--stat -i 100。需要配合-h选项使用。

关于requests与connections官方也没有介绍，自己结合本地和线上的输出，做了对比得出的结论。

 ------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections            
97146      6.82G    1724    0       60068357585 (+49536) 93936323    
97146      6.82G    1724    0       60068403702 (+46117) 93936323    
97146      6.82G    1724    0       60068451875 (+48173) 93936323    
97146      6.82G    1724    0       60068496037 (+44162) 93936323

keys：当前节点缓存的key总数
mem：当前节点缓存总的占用内存
clients：当前节点的活跃连接数，或者说未断开连接的总连接数
blocked：当前节点正在等待阻塞命令的数量
requests：当前处理的请求数，与上一次请求数相减可知1秒所处理的请求，或者说所执行的命令数。
connections：是历史连接总数，即到目前为止，一共新建了多少个连接。与前一次相减，可以得出一秒内新建的连接数。

Requests列括号里的数是每间隔所处理的命令数。比如当前60068496037减去前一次60068451875 等于44162，由于stat默认频率是每秒输出一次，44162就是每秒执行4万多条命令。正好是括号里面的数字，也因此可以知道，括号里面的数字代表每秒(interval)执行的命令数。

当然--stat每秒输出一次结果也是一条命令，所以在没有任何请求的情况下，你看到的requests是自增的，可以本地起个redsi服务，然后使用redis-cli --stat观察下输出。

Blocked并不是排队等待执行的命令数，而是客户端执行阻塞命令的总数。比如BLPOP。

Connections也是很有用的参数，如果发现connections与前一次的差值很大，且很频繁，那就要看下代码中连接池配置是否生效了。

使用--stat分析读写分离的主从集群缺点

在此之前，我们项目中用的是古老的主从集群模式，使用读写分离的连接池，所有写请求都会访问主节点，所有读请求都会访问从节点，那么读写分离会存在哪些问题？

观察主节点，所有写请求都会发到这个节点。

------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections          
382453     1.22G    1305    0       53636611824 (+5112) 70953183    
382453     1.22G    1305    0       53636616926 (+5102) 70953183    
382453     1.22G    1305    0       53636622056 (+5130) 70953183

观察从节点，所有读请求都会发到这个节点。

------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections           
382551     1.22G    1307    0       197046636517 (+34705) 75561440    
382551     1.22G    1307    0       197046669775 (+33258) 75561440    
382552     1.22G    1307    0       197046701747 (+31972) 75561440    
382551     1.22G    1307    0       197046734329 (+32582) 75561440

很明显，主节点每秒处理的写请求数远小于从节点每秒处理的读请求数。在极端情况下，比如写少读多的场景，使用这种主从读写分离方案，会导致一个节点无请求，而另一个节点忙得不可开交。

主从读写分离还有一个缺点，如果一时间批量写了很多数据，由于主从同步的延时问题，会出现一个空白期，从从节点上读不到数据。如果有实时性要求高的场景，或者大批量数据更新很频繁的场景，还是不建议使用读写分离。从节点应该只用来提供高可用的保证，在主节点挂的情况下从节点保证这部分槽位可用。当然，这不用也是浪费。

分析两主无从Cluster集群模式

只有两个主节点的Cluster集群，槽位平均分配。使用redis-cli --stat实时监视实例。

节点1输出片段:

------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections          
97270      6.82G    1726    0       60242433804 (+26930) 94154236    
97270      6.81G    1726    0       60242457927 (+24123) 94154236    
97270      6.82G    1725    0       60242485748 (+27821) 94154236    
97270      6.82G    1725    0       60242511827 (+26079) 94154236

节点2输出片段:

------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections             
96077      4.20G    1725    0       61244385399 (+32594) 94349868    
96076      4.20G    1725    0       61244417031 (+31632) 94349868    
96075      4.21G    1725    0       61244443142 (+26111) 94350076    
96075      4.20G    1725    0       61244466682 (+23540) 94350076

从两个节点的当前连接数可以看出，JedisCluster配置的连接池会为每个节点创建一个连接池，每个节点的连接池连接数都是相同的。之所以会每个节点都维持相同的连接数，因为每个请求的key都有可能落在其中的一个节点上，你无法预知程序运行过程中落在哪个节点的请求数较多，哪个较少。

当各个服务的集群总节点数很多的情况下，就需要合理分配连接池的最大连接数。官方推荐单个redis节点最大连接数不超过1w，假设有20个服务节点需要用到redis，那么每个节点的连接池最大连接数最大不能超过10000/20 = 500。建议连接池的最大连接数比业务线程的最大线程数多20个连接，只要确保每个工作线程都能有一个redis连接，不至于为了等待连接而阻塞就可以，因为不可能一个线程同时会用到2个以上的连接。假设工作线程数为200，那么redis连接池可以配置为200～220。

从两个节点的内存使用和每秒处理的请求数能够看出，数据的倾斜还是较为严重的，每秒请求数相差在1w左右，这个差距还在可接受范围内。如果请求和内存的倾斜比较严重，就可以重新分配槽位，给请求和存储较少的一方分配更多的槽位以达到平衡状态。

使用info也能统计每秒处理的命令数

stat对于性能监控还是很有帮助的。能够获取到每秒处理的命令数还可以通过info Stats。如

172.31.x.x:6379> info stats
# Stats
.....
instantaneous_ops_per_sec:8589
....

instantaneous_ops_per_sec：redis内部较实时的每秒执行的命令数。

如果想要获取更详细的每种命令的平均耗时，可以使用info Commandstats查看如：

172.31.x.x:6379> info Commandstats
cmdstat_zrangebyscore:calls=1006828954,usec=9633479351,usec_per_call=9.57
cmdstat_rpush:calls=49673,usec=278402,usec_per_call=5.60
cmdstat_setbit:calls=86267170,usec=2645199883,usec_per_call=30.66
......

cmdstat_zrangebyscore: 即zrangebyscore命令
calls：命令调用总次数
usec: 总耗时
usec_per_call: 平均耗时，单位微秒

slowlog慢查询分析

当命令的执行耗时超过配置的慢查询时间，则会被放入一个慢查询的队列中。可通过config set slowlog-log-slower-than xxx修改慢查询时间，单位微秒，默认情况下，这个值为10000，即所有执行时间超过10ms的都会记录到慢查询队列。使用slowlog get可以查看慢查询信息。

172.31.x.x:6379> slowlog get 1
 1) 1) (integer) 6018
    2) (integer) 1575108134
    3) (integer) 19861
    4) 1) "ZRANGEBYSCORE"
       2) "ip-country-city-locations-range-3708"
       3) "3.72526109E9"
       4) "1.7976931348623157E308"
       5) "limit"
       6) "0"
       7) "1"
     5）"172.31.x.x:xxx"
    ......

1)、慢查询自增id；

2)、命令执行完成时间，时间戳；

3)、命令执行耗时，单位为微秒，1秒=1000毫秒，1毫秒等于1000微秒；

4)、执行的命令；

5) 、发起该命令请求的客户端ip及端口号。

通过分析慢查询，可以分析项目中哪些地方用到这些命令，及时优化这些命令能够在大流量来临之前杜绝隐患，也能及时对代码进行调优，通过替换存储的数据结构优化查询性能，减少单次请求的耗时。

网络延迟也是我们要关注的问题

redis-cli命令--latency选项可以测试当前服务器与redis某个节点的网络延迟。

>src/redis-cli --latency -h 172.31.1.1
min: 0, max: 12, avg: 0.25 (1047 samples)

avg：0.25，即延迟为250μs。如果通过外网连接网络延迟会很高，比如跨机房的redis调用，延迟高的情况下使用redis反而比使用本地硬盘读写性能更差。

还有其它影响redis性能的因素，比如内存的使用，持久化策略等。

AOF持久化策略影响性能问题

如果数据不需要持久化，或者要求不严格，建议直接禁用掉AOF持久化策略，同时RDB快照的保存时间间隔也要调高一些，比如一小时一次，以此达到更高的性能。

# 是否开启持久化策略
# （支持同时开启RDB和AOF，即混合策略）
appendonly no


# yes: 在aof重写期间不做fsync刷盘操作，可能丢失整个AOF重写期间的数据，
no-appendfsync-on-rewrite yes


# fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。
# always：每次写入都要同步AOF文件。
# no：同步硬盘操作由操作系统负责，通常同步周期为30秒，数据安全性无法保证。
# everysec：由专门线程每秒同步一次fsync。理论上只有在系统突然宕机的情况下丢失1秒的数据。
appendfsync no


#当前aof文件大小与上次重写后文件大小的比值超过该值时进行重写，200即等于之前的2倍
auto-aof-rewrite-percentage 200


#当aof文件大小大于该值时进程重写，以减小aof文件占用的磁盘空间
auto-aof-rewrite-min-size 64mb