学习笔记——Redis持久化和主从复制

前言

本文是通过各种杂七杂八的渠道整理的相关知识，都是说明性知识点，暂时没有作者自己太多的思考和简要升华。

Redis持久化机制

Redis持久化机制分为两种，rdb持久化和aof持久化。
rdb持久化方式，在一定时间间隔内对数据库内数据集生成快照，写入磁盘，所谓快照方式，你可以理解为，要生成当前数据集的写命令集合生成到文件。然后操作系统安装这些写命令向磁盘写入数据。默认文件为dump.rdb。
aof持久化方式，redis会将每一个收到的写命令通过write函数追加到文件。然后操作系统安装这些写命令向磁盘写入数据，默认文件为appendonly.aof。
redis默认的持久化方式是rdb持久化。

RDB文件的保存过程

Redis调用fork，生产出一个子进程，父进程继续处理client端的请求，子进程负责将内容写入临时文件，由于os的写复制机制，父子进程共享相同的写页面。当父进程处理请求时，os会为父进程共享相同的写页面创建副本，父进程操作副本，所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照，子进程将快照写入临时文件，临时文件替换原来的快照文件，然后子进程退出。
client也可使用save命令通知redis做一次快照持久化，由于redis是使用一个主线程来处理所有的client请求，这种方式会阻塞所有的请求。每次快照持久化都是将内存数据完成写入到磁盘一次，如果数据量过大，可能会严重影响性能。

AOF文件的保存过程

redis会将每一个收到的写命令通过write函数追加到文件，当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容，由于os会在内核中缓存write所做的修改，所以可能不是立即写到磁盘上。
aof持久化有以下三种方式：
appendfsync always //每次收到写命令，就强制写入磁盘，保证完全的持久化，但速度最慢，不推荐使用
appendfsync everysec //没秒强制写入磁盘一次，在性能和持久化方面做了这种，推荐使用
appendfsync no //完全依赖os，性能最好，但是持久化没保证。
aof方式带来了一个多余写的问题，所谓多余写，就是设置一个key值，不停累加到100，这样就会多了一百条指令，而不是直接写这个key值为100。
所以为了压缩aof的持久化文件，redis提供了bgrewriteaof命令。具体实现过程如下：
redis调用fork，现有的父子两个进程，子进程通过快照，往临时文件写入重建数据库的命令，父进程继续处理client请求，除了把写命令写入到原来的aof文件中，同时把收到的写命令缓存起来。这样能保证，即使子进程失败了并不会出问题。当子进程以命令方式把快照内容写入临时文件后，子进程发信号通知父进程。然后父进程把缓存的写命令追加到临时文件。现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的命令也开始往新的aof文件中追加。

Redis的主从复制

全量同步：Redis的全量复制一般是发生在slave初始化阶段，这时slave需要将Master上所有的数据都复制一份。步骤如下：
一、从服务器连接主服务器，发送sync命令。
二、主服务器收到sync命令后，开始执行bgsave命令生成rdb文件并使用缓冲区记录此后执行的所有写命令。
三、主服务器执行完bgsave命令后，向所有的从服务器发送快照文件，并在发送期间继续记录被执行的写命令。
四、从服务器收到快照后，丢弃所有的旧数据，载入收到的快照。
五、主服务器发送完毕快照文件后，开始向从服务器发送缓冲区的写命令。
六、从服务器执行完对快照文件的载入，开始接受命令请求，并执行来自主服务器的缓冲区的写命令。
增量同步：Redis增量负责是在slave初始化完成后，主服务器发生的写操作同步到从服务器的过程。增量同步的过程主要是服务器每执行一个写命令，就会向从服务器发送相同的写命令，从服务器接受并执行。

主从同步策略：slave初始化阶段进行全量同步到初始化完成，之后进行增量同步，增量同步过多的增加冗余的写命令时，可以随时考虑进行全量同步，无论如何，首先都会尝试增量同步，如不成功，要求从机进行全量同步。