线上redis bgsave导致服务响应延迟

最近一个服务上线一个月后出现某个时间段响应延迟的问题，先看下监控数据：

   

这里有一点，单台实例的并发最高达到200是因为没修改spring boot中tomcat默认的最大线程数（默认是200）。

从上图可以看出21点—24点以及第二天08点—11点服务的延迟已经达到s级别，甚至严重时已经达到30多s，整个app基本不可用。

问题第一次出现时，整个服务启了4台实例，dau是40万，所以当时单纯怀疑是因为访问量增加导致实例的请求线程被打满，出现请求阻塞导致的延迟。于是在24点时将服务增加到8台实例，响应出现好转。

但是第二天又出现类似情况，且更加严重，每台实例的qps只有500左右，所以分析是其他问题导致的请求耗时较高从而引起的请求阻塞。因为我们的服务很依赖redis，且对redis进行过一次降配（这个服务属于突然起量），于是redis的性能：

   

 可以看到在出问题的时间段redis的延迟也达到s级别。于是查看redis的内存和cpu状态：

CPU load：

   

 可以看到redis实例出现cpu load达到1以上，说明CPU阻塞严重，大量的处理请求在排队。

memory：

  

 可以看到内存使用率已经达到90%以上，所以很明显redis内存存在问题，为了尽快解决线上问题，先进行redis内存的升级（使用的阿里服务，升级耗时3分钟），再去寻找内在具体原因。

 进入redis集群，通过info查看redis状态：果然发现异常，rdb_last_bgsave_status:err

                            

 redis bgsave失败，使用的RDB持久化策略，bgsave会fork一个进程进行数据的持久化，具体的分析可以参考这篇文章，讲的很详细：https://zhuanlan.zhihu.com/p/89248752

 通过以上分析，可以看出这次问题的具体原因是：

    1、fork子进程会消耗CPU资源，通过下图可以看出，CPU随着定时执行的bgsave出现锯齿状波动

            

    2、Redis 使用的操作系统的多进程 COW（Copy On Write）机制来实现快照持久化，所以RDB也叫快照持久化。Redis 会使用操作系统的 COW 机制来进行数据段页面的分离，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改，这时子进程相应的页面是没有变化的，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变。

　　所以出现这次问题的本质原因是因为内存使用率过高，而且redis的写请求量很大，所以导致bgsave时主进程复制大量的数据页面导致内存不足而发生错误，出现错误又会重新fork子进程去重新执行数据同步，所以导致CPU负载一直较高无法处理其他请求，从而hang住了整个客户端。

      通过一点可以印证这一点，从00点到08点之间，其实redis内存的使用率一直很高，但是在这段时间用户的请求量较少，所以redis的写请求不多，也就不会导致bgsave因内存不足而发生报错。