《Redis设计与实现》读书笔记

很喜欢这本书的创作过程，以开源的方式，托管到Git上进行创作；
作者通读了Redis源码，并分享了详细的带注释的源码，让学习Redis的朋友轻松不少；
阅读优秀的源码作品能快速的提升编码内功，而像Redis这样代码量不大（2万多行）却句句精致的作品，当然不能错过；
有兴趣的朋友当好好享用；
源码：https://github.com/huangz1990/annotated_redis_source

以下是这本书重点环节的读书笔记；

过期键的清除

如果一个键是过期的，那它什么时候会被删除？
这个问题有三种可能的答案：

1. 定时删除：在设置键的过期时间时，创建一个定时事件，当过期时间到达时，由事件处理器自动执行键的删除操作。
2. 惰性删除：放任键过期不管，但是在每次从 dict 字典中取出键值时，要检查键是否过期，如果过期的话，就删除它，并返回空；如果没过期，就返回键值。
3. 定期删除：每隔一段时间，对 expires 字典进行检查，删除里面的过期键；定期删除是这两种策略的一种折中：
   • 它每隔一段时间执行一次删除操作，并通过限制删除操作执行的时长和频率，籍此来减少删除操作对 CPU 时间的影响。
   • 另一方面，通过定期删除过期键，它有效地减少了因惰性删除而带来的内存浪费。

定时删除和惰性删除这两种删除方式在单一使用时都有明显的缺陷：定时删除占用太多 CPU 时间，惰性删除浪费太多内存；
Redis 使用的过期键删除策略是惰性删除加上定期删除， 这两个策略相互配合，可以很好地在合理利用 CPU 时间和节约内存空间之间取得平衡。
参考：http://origin.redisbook.com/en/latest/internal/db.html#id20

AOF写文件的三阶段

命令到 AOF 文件的整个过程可以分为三个阶段：

1. 命令传播：Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。2. 缓存追加：AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的 AOF 缓存中。
2. 文件写入和保存：AOF 缓存中的内容被写入到 AOF 文件末尾，如果设定的 AOF 保存条件被满足的话，fsync 函数或者 fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中。

AOF 保存模式对性能和安全性的影响

redis 目前支持三种 AOF 保存模式，它们分别是：

1. AOF_FSYNC_NO ：不保存。
2. AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。
3. AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。

三种 AOF 保存模式，它们对服务器主进程的阻塞情况如下：

1. 不保存（AOF_FSYNC_NO）：写入和保存都由主进程执行，两个操作都会阻塞主进程。
2. 每一秒钟保存一次（AOF_FSYNC_EVERYSEC）：写入操作由主进程执行，阻塞主进程。保存操作由子线程执行，不直接阻塞主进程，但保存操作完成的快慢会影响写入操作的阻塞时长。
3. 每执行一个命令保存一次（AOF_FSYNC_ALWAYS）：和模式 1 一样。因为阻塞操作会让 Redis 主进程无法持续处理请求，所以一般说来，阻塞操作执行得越少、完成得越快，Redis 的性能就越好。

AOF 后台重写

AOF 重写程序可以很好地完成创建一个新 AOF 文件的任务，但是，在执行这个程序的时候，调用者线程会被阻塞。很明显，作为一种辅佐性的维护手段，Redis 不希望 AOF 重写造成服务器无法处理请求，所以Redis 决定将 AOF 重写程序放到（后台）子进程里执行，这样处理的最大好处是：

1. 子进程进行 AOF 重写期间，主进程可以继续处理命令请求。
2. 子进程带有主进程的数据副本，使用子进程而不是线程，可以在避免锁的情况下，保证数据的安全性。不过，使用子进程也有一个问题需要解决：因为子进程在进行 AOF 重写期间，主进程还需要继续处理命令，而新的命令可能对现有的数据进行修改，这会让当前数据库的数据和重写后的AOF 文件中的数据不一致。为了解决这个问题，Redis 增加了一个 AOF 重写缓存，这个缓存在 fork 出子进程之后开始启用，Redis 主进程在接到新的写命令之后，除了会将这个写命令的协议内容追加到现有的 AOF文件之外，还会追加到这个缓存中
   注 子进程与线程在访问数据上的区别，难道不是都需加锁么
   ref：http://blog.csdn.net/wangkehuai/article/details/7089323

AOF 后台重写的触发条件

子进程完成 AOF 重写之后，它会向父进程发送一个完成信号，父进程在接到完成信号之后，会调用一个信号处理函数，并完成以下工作：

1. 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。
2. 对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。当步骤 1 执行完毕之后，现有 AOF 文件、新 AOF 文件和数据库三者的状态就完全一致了。当步骤 2 执行完毕之后，程序就完成了新旧两个 AOF 文件的交替。
   在整个 AOF后台重写过程中，只有最后的写入缓存和改名操作会造成主进程阻塞，在其他时候，AOF 后台重写都不会对主进程造成阻塞，这将 AOF 重写对性能造成的影响降到了最低。

当 serverCron 函数执行时，它都会检查以下条件是否全部满足，如果是的话，就会触发自动的 AOF 重写：

1. 没有 BGSAVE 命令在进行。
2. 没有 BGREWRITEAOF 在进行。
3. 当前 AOF 文件大小大于 server.aof_rewrite_min_size （默认值为 1 MB）。
4. 当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比。默认情况下，增长百分比为 100% ，也即是说，如果前面三个条件都已经满足，并且当前 AOF文件大小比最后一次 AOF 重写时的大小要大一倍的话，那么触发自动 AOF 重写。

事件

事件是 Redis 服务器的核心，它处理两项重要的任务：

1. 处理文件事件：在多个客户端中实现多路复用，接受它们发来的命令请求，并将命令的执行结果返回给客户端。
2. 时间事件：实现服务器常规操作（server cron job）

事件的执行与调度

Redis 里面既有文件事件，又有时间事件，那么如何调度这两种事件就成了一个关键问题。简单地说，Redis 里面的两种事件呈合作关系，它们之间包含以下三种属性：

1. 一种事件会等待另一种事件执行完毕之后，才开始执行，事件之间不会出现抢占。
2. 事件处理器先处理文件事件（处理命令请求），再执行时间事件（调用 serverCron）
3. 文件事件的等待时间（类 poll 函数的最大阻塞时间），由距离到达时间最短的时间事件决定。

说明：
• 时间事件分为单次执行事件和循环执行事件，服务器常规操作 serverCron 就是循环事件。
• 文件事件和时间事件之间是合作关系：一种事件会等待另一种事件完成之后再执行，不会出现抢占情况。

命令的请求、处理和结果返回

Redis 以多路复用的方式来处理多个客户端，为了让多个客户端之间独立分开、不互相干扰，服务器为每个已连接客户端维持一个 redisClient 结构，从而单独保存该客户端的状态信息。
当客户端连上服务器之后，客户端就可以向服务器发送命令请求了。从客户端发送命令请求，到命令被服务器处理、并将结果返回客户端，整个过程有以下步骤：

1. 客户端通过套接字向服务器传送命令协议数据。
2. 服务器通过读事件来处理传入数据，并将数据保存在客户端对应 redisClient 结构的查询缓存中。
3. 根据客户端查询缓存中的内容，程序从命令表中查找相应命令的实现函数。
4. 程序执行命令的实现函数，修改服务器的全局状态 server 变量，并将命令的执行结果保存到客户端 redisClient 结构的回复缓存中，然后为该客户端的 fd 关联写事件。
5. 当客户端 fd 的写事件就绪时，将回复缓存中的命令结果传回给客户端。至此，命令执行完毕。

Posted by: 大CC | 11JUL,2014
博客：blog.me115.com [订阅]
微博：新浪微博