曹工说Redis源码（7）-- redis server 的周期执行任务，到底要做些啥

文章导航

Redis源码系列的初衷，是帮助我们更好地理解Redis，更懂Redis，而怎么才能懂，光看是不够的，建议跟着下面的这一篇，把环境搭建起来，后续可以自己阅读源码，或者跟着我这边一起阅读。由于我用c也是好几年以前了，些许错误在所难免，希望读者能不吝指出。

曹工说Redis源码（1）-- redis debug环境搭建，使用clion，达到和调试java一样的效果

曹工说Redis源码（2）-- redis server 启动过程解析及简单c语言基础知识补充

曹工说Redis源码（3）-- redis server 启动过程完整解析（中）

曹工说Redis源码（4）-- 通过redis server源码来理解 listen 函数中的 backlog 参数

曹工说Redis源码（5）-- redis server 启动过程解析，以及EventLoop每次处理事件前的前置工作解析（下）

曹工说Redis源码（6）-- redis server 主循环大体流程解析

本讲主题

本讲，聚焦于redis的周期执行任务。redis启动起来后，基本就剩下两件事，上一讲的主流程分析中，已经讲到了。1个是处理客户端请求，2就是指向周期任务。处理客户端请求，大概会细分为：处理客户端连接事件（客户端连接到redis）、客户端读写事件（客户端发送请求，redis返回响应）；

周期任务呢，就是本讲主题，let's go。

周期任务的大体流程

周期任务，上一讲已经提到，其就是一个函数指针，具体实现，就是redis.c中的 serverCron 函数。

该函数的大的流程，按照代码中的执行顺序，我们先了解下：

1. 注册一个watchdog，注册方式是通过一个timer，注册了该timer之后，会定期给当前进程，触发一个SIGALRM信号，触发了这个信号后，会干嘛呢，会回调位于 debug.c 文件中的 watchdogSignalHandler方法，这个方法，主要是在redis执行一些命令时，超过指定时长后，打印一些debug日志。

   可以参考：

   Redis 2.6 的新特性：Watchdog（看门狗）

   Redis software watchdog

2. 更新server时间，redis server在很多时候，都需要获取当前时间，就像我们写业务代码差不多，但是，redis比较扣，扣什么？扣性能。在不需要获取当前时间的时候，redis觉得，获取一个不那么准确的时间就行了。所以，就缓存了一个全局时间，这个全局时间，什么时候刷新呢，就在这个周期任务中。

   大家仔细看注释吧：

   /* We take a cached value of the unix time in the global state because with
    * virtual memory and aging there is to store the current time in objects at
    * every object access, and accuracy is not needed. To access a global var is
    * a lot faster than calling time(NULL) */
   void updateCachedTime(void) {
       server.unixtime = time(NULL);
       server.mstime = mstime();
   }
   

   简单翻译下，就是说，每个对象，每次被访问的时候，有个access-time，这个时间，不需要那么精确，没必要每次去new date()，使用缓存的时间就行了，这样能比较快。全局时间，缓存在server.unixtime 和 server.mstime中。

3. 计算redis的ops，类似于tps；这个操作，不是每次该周期任务时，都要执行，而是自定义执行的周期，总体来说，没有本周期任务那么频繁。

   redis中，定义了一个宏来实现这个功能，比如：

       // 记录服务器执行命令的次数
       run_with_period(100) trackOperationsPerSecond();
   

   这个就是，每100ms执行一次上面的这个操作。

   这个怎么去计算ops（operation per second）呢？看下面的代码即懂：

   void trackOperationsPerSecond(void) {
   
       // 计算两次抽样之间的时间长度，毫秒格式
       long long t = mstime() - server.ops_sec_last_sample_time;
   
       // 计算两次抽样之间，执行了多少个命令
       long long ops = server.stat_numcommands - server.ops_sec_last_sample_ops;
   
       long long ops_sec;
   
       //1 计算距离上一次抽样之后，每秒执行命令的数量
       ops_sec = t > 0 ? (ops * 1000 / t) : 0;
   	...
   }
   

   1处，分子分母，大家一看，应该就懂了。ops = 一段时间内的操作数量/ 时间长度。

4. 刷新服务器的 LRU 时间，目前，我觉得可以简单理解为：redis的空间大小是有限的，假设机器内存10g，那么不可能把数据库的几个t的数据都放redis，所以基本是放热数据，那不热的数据怎么办？被清除。清除的算法，就是lru。每个key，不管设没设过期时间，都会维护一个lruClock，即最近一次被访问的时间。

   计算一个对象的空闲时长，就是用服务器的LRU时间 减去 key的LRU时间。

   // 使用近似 LRU 算法，计算出给定对象的闲置时长
   unsigned long long estimateObjectIdleTime(robj *o) {
       unsigned long long lruclock = LRU_CLOCK();
       if (lruclock >= o->lru) {
           return (lruclock - o->lru) * REDIS_LRU_CLOCK_RESOLUTION;
       } else {
           return (lruclock + (REDIS_LRU_CLOCK_MAX - o->lru)) *
                       REDIS_LRU_CLOCK_RESOLUTION;
       }
   }
   

   网上的一篇文章写得不错，可以参考：

   redis的LRU策略理解

5. 记录服务器的内存峰值

       /* Record the max memory used since the server was started. */
       // 记录服务器的内存峰值
       if (zmalloc_used_memory() > server.stat_peak_memory)
           server.stat_peak_memory = zmalloc_used_memory();
   

   什么时候用呢？好像只在info命令里看到使用了。

6. 判断服务器的关闭标识是否打开，如打开，则关闭

   // 服务器进程收到 SIGTERM 信号，关闭服务器
       if (server.shutdown_asap) {
           // 尝试关闭服务器
           if (prepareForShutdown(0) == REDIS_OK) exit(0);
        }
   

7. 打印数据库的键值对信息、客户端信息

   单纯的log操作，唯一注意的是，要把日志级别调到REDIS_VERBOSE才看得到

8. 检查客户端空闲时长，关闭空闲超时的客户端

   int clientsCronHandleTimeout(redisClient *c) {
   
       // 获取当前时间
       time_t now = server.unixtime;
   
       // 服务器设置了 maxidletime 时间
       if (server.maxidletime &&
           ...
           // 客户端最后一次与服务器通讯的时间已经超过了 maxidletime 时间
           (now - c->lastinteraction > server.maxidletime)) {
           redisLog(REDIS_VERBOSE, "Closing idle client");
           // 关闭超时客户端
           freeClient(c);
           return 1;
       }
       ...
   }
   

9. 对数据库执行各种操作

   /* This function handles 'background' operations we are required to do
    * incrementally in Redis databases, such as active key expiring, resizing,
    * rehashing. */
   // 对数据库执行删除过期键，调整大小，以及主动和渐进式 rehash
   void databasesCron(void)
   

   看注释可知，大概有如下工作：删除过期key，hash表的rehash，hash的size调整（如果字典的使用率低，会缩小其占用的内存大小）

   后续会详解这部分。

10. 如果当前没有aof或者rdb后台任务正在执行，且server之前被schedule了一个aof rewrite后台任务，则执行

    aof 重写。（aof记录了每一条命令，时间长了，会重复，比如先把key a设为1，再设为2，再设为3，这样，aof中有3条记录，实际上，只需要一条即可，所以会重写）

    aof 重写在一个子进程中进行，子进程完成后，会给当前进程发送信号，所以，当前进程会一直等待信号，等待子进程完成后，自己再做些处理。

    比如，主进程要做什么处理呢？在 aof 重写期间，主进程可能还是要不断地处理命令（这里不会无限期等待，这次等不到就到下一次周期任务时再等），这期间，处理的命令，不能记录到aof文件中，免得影响正在进行aof 重写的子进程，所以，主进程会把这期间的命令，记录到一个小本本上。

    等到子进程写完了，主进程再把小本本上的aof命令，写到aof日志文件里。

11. 如果当前没有aof或者rdb后台任务在执行，也没有被schedule 一个aof rewrite任务，那么，上面这步中的全部操作，都不会发生。

    此时，会去检查，当前是否满足aof 重写、rdb 保存的条件。

    比如，rdb不是一般需要配置如下参数吗：

    save 900 1
    save 300 10
    save 60 10000
    

    此时，就会去检查，这些参数，是否满足，如果满足，就要开始进行rdb后台保存。

    或者，当以下的aof参数满足时，也会触发aof重写：

    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb
    

12. 根据配置的aof fsync策略，决定是否要刷新到文件中

    前面我们说的aof写日志文件，不一定真的就写入了文件，可能还在OS cache中，需要调用 fsync 才能写入到文件中。

    这里即对应配置文件中的：

    # appendfsync always
    appendfsync everysec
    # appendfsync no
    

    默认每秒执行一次fsync，性能和数据安全性的折衷。

13. 涉及slave、cluster、sentinel的部分操作

    如果运行在以上几种模式下，会涉及到对应的一些周期操作，后续再涉及这块。

总结

本讲的主题大概是这些，其中，细节部分，比如数据库的周期任务等，留待下讲继续。