Redis持久化过程的监控及优化

Redis持久化过程一直是影响redis性能的常见因素，如何监控持久化以及如何优化持久化过程呢？下面我们就一起来看看吧。

fork的监控及优化

不管是使用哪种持久化，RDB持久化或AOF重写，主进程都会fork出一个子进程，在子进程里完成rdb文件的生成或aof的重写。fork操作对于操作系统来说属于比较重的操作。fork阶段，redis会阻塞一段时间。阻塞时间和redis数据占用的内存大小成正比关系，每1G内存fork耗时在20毫秒。

如想知道fork阶段的阻塞时间，可以使用info stats命令，查看latest_fork_usec选项的值，单位是微秒。记住是微秒，不是毫秒。

# redis-cli info stats | grep latest

latest_fork_usec:323

优化fork的方法：

控制redis占用的内存大小。若占用内存过大的话，可以将应用拆分开，在多个服务器上部署，分摊redis的内存占用。

适当降低fork的操作频率。

内存的监控

RDB持久化的日志如下：

……

21692:C 15 May 2020 14:17:06.935 * DB saved on disk

21692:C 15 May 2020 14:17:06.936 * RDB: 2 MB of memory used by copy-on-write

……

可以看到RDB持久化过程消耗了2M内存。

AOF持久化日志如下：

……

15786:C 23 May 2020 07:39:59.145 * AOF rewrite: 2MB of memory used by copy-on-write

10679:M 23 May 2020 07:39:59.201 * Background AOF rewrite terminated with success

10679:M 23 May 2020 07:39:59.201 * Residual parent diff successfully flushed to the rewritten AOF (0.02 MB)

10679:M 23 May 2020 07:39:59.201 * Background AOF rewrite finished successfully

可以看到，aof重写占用的内存为2MB+0.02MB=2.02MB

如想监控持久化过程中内存占用情况，可以编写shell脚本，统计出redis日志里相关信息。

硬盘的监控

Redis持久化过程会对硬盘造成压力，因为持久化后，内存的数据会保存到硬盘中。

linux系统监控硬盘的命令有sar、iostat等，如发现硬盘io压力超过阀值，再根据redis的日志对比下持久化的时间，看看是不是由于redis持久化造成的压力。

优化方法这里提两点：

使用性能好的磁盘，机械硬盘肯定比不了固态硬盘。

如果是单机上配置了好几个redis实例，可以分别写入不同的磁盘里，减轻磁盘的写入压力。

单机多实例部署

因为redis是单线程架构，如果一个服务器上只部署一个redis实例，那么对于多核cpu来说是一种浪费。所以，通常会在一个服务器上部署多个redis应用，比如开启三个redis服务，端口号分别为6379,6380,6381。6379用来做缓存服务，6380用来做消息队列，6381用来做标签及推荐系统。

这样确实可以充分利用cpu，但会容易产生问题。如果多个实例同时在进行持久化，那么对于cpu、内存及影片的压力是非常大的。好的做法是将他们隔离开来，同一时间只有一个实例在进行持久化。

实现该效果的伪代码如下：

while (true)
{
 $redisObj = [6379,6380,……];
   
 foreach ($redisObj as $obj) {
 // 该实例是否构成重写的要求
 if (rewriteConf($ojb)) {
 // 该实例进行持久化
 }
 }
}

foreach用来遍历每一个redis实例，然后对该实例是否达到重写的条件做判断，满足就开始进行重写。这样就可以将多redis实例持久化进行隔离。

 fork的监控及优化

不管是使用哪种持久化，RDB持久化或AOF重写，主进程都会fork出一个子进程，在子进程里完成rdb文件的生成或aof的重写。fork操作对于操作系统来说属于比较重的操作。fork阶段，redis会阻塞一段时间。阻塞时间和redis数据占用的内存大小成正比关系，每1G内存fork耗时在20毫秒。

如想知道fork阶段的阻塞时间，可以使用info stats命令，查看latest_fork_usec选项的值，单位是微秒。记住是微秒，不是毫秒。