Redis核心技术笔记05-06

05 内存快照

把内存中的数据在某一时刻的状态以文件的形式写到磁盘上就是快照，这个快照文件就称为RDB（Redis DataBase）文件。

和 AOF 相比，RDB 记录的是某一时刻的数据，并不是操作，所以，在做数据恢复时，我们可以直接把 RDB 文件读入内存，很快地完成恢复。

Redis RDB快照是全量快照，会将所有数据保存到磁盘中。

对于Redis的单线程模型，要尽量避免所有会阻塞主线程的操作。

生成方式

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave:

• save：在主线程中执行，会导致阻塞；
• bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。

写时复制

如果快照执行期间数据不能被修改，会给业务服务造成巨大的影响。
Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。

原理：

1. bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。
2. 如果主线程要修改一块数据（例如键值对 C），那么，这块数据就会被复制一份，生成该数据的副本（键值对 C’）。
3. 然后，主线程在这个数据副本上进行修改。同时，bgsave 子进程可以继续把原来的数据（键值对 C）写入 RDB 文件。

这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影响。

快照开销

1. 增大磁盘带宽压力
2. fork创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。

增量快照

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法：
设置的参数是： aof-use-rdb-preamble yes

1. 内存快照以一定的频率执行
2. 在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

小结

• 数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；
• 如果允许分钟级别的数据丢失，可以只使用 RDB；
• 如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个平衡。

问题：
2核4G服务器Redis数据大小2G，读写比2:8的场景，用RDB做持久化的风险？
答案：
a、内存资源风险：持久化过程中，“写时复制”会重新分配整个实例80%的内存副本，大约1.6GB内存，如果此时父进程又有大量新key写入，很快机器内存就会被吃光，如果机器开启了Swap机制，那么Redis会有一部分数据被换到磁盘上，当Redis访问这部分在磁盘上的数据时，性能会急剧下降，已经达不到高性能的标准（可以理解为武功被废）。如果机器没有开启Swap，会直接触发OOM，父子进程会面临被系统kill掉的风险。
b、CPU资源风险：虽然子进程在做RDB持久化，但生成RDB快照过程会消耗大量的CPU资源

06 主从一致

高可靠性

1. 数据尽量少丢失：AOF和RDB
2. 服务尽量少中断：增加副本冗余量，将一份数据同时保存在多个实例上

读写分离

Redis 提供了主从库模式，以保证数据副本的一致，主从库之间采用的是读写分离的方式。

• 读操作：主库、从库都可以接收；
• 写操作：首先到主库执行，然后，主库将写操作同步给从库。

主从同步

启动多个 Redis 实例时，它们相互通过 replicaof 命令形成主库和从库的关系，之后会按照三个阶段完成数据的第一次同步。

replicaof  172.16.19.3  6379

1. 建立连接，协商同步

从库给主库发送 psync 命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。
psync 命令包含了主库的 runID 和复制进度 offset 两个参数：

• runID，是每个 Redis 实例启动时都会自动生成的一个随机 ID，用来唯一标记这个实例。当从库和主库第一次复制时，因为不知道主库的 runID，所以将 runID 设为“？”。
• offset，此时设为 -1，表示第一次复制。

主库收到 psync 命令后，会用 FULLRESYNC 响应命令带上两个参数：主库 runID 和主库目前的复制进度 offset，返回给从库。

FULLRESYNC 响应表示第一次复制采用的全量复制，也就是说，主库会把当前所有的数据都复制给从库。

2. 主库同步数据给从库

主库将所有数据同步给从库。从库收到数据后，在本地完成数据加载。这个过程依赖于内存快照生成的 RDB 文件。

1. 主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。
2. 从库接收到 RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。
3. 为了保证主从库的数据一致性，主库会在内存中用专门的 replication buffer，记录 RDB 文件生成后收到的所有写操作。

3. 主库发送新写命令给从库

主库会把第二阶段执行过程中新收到的写命令，再发送给从库。
具体的操作是，当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。

主库压力

一次全量复制中，对于主库来说，需要完成两个耗时的操作：生成 RDB 文件和传输 RDB 文件。

1. 如果从库数量很多且都要全量复制，fork操作会阻塞主线程，导致主库响应速度变慢
2. 传输 RDB 文件也会占用主库的网络带宽，同样会给主库的资源使用带来压力。

主-从-主模式

将主库生成 RDB 和传输 RDB 的压力，以级联的方式分散到从库上：

1. 选择一个从库用于级联其他从库
2. 选择一些从库和级联从库建立主从关系replicaof 级联从库IP 6379

风险点：网络断连或阻塞。

断网重连

从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。

当主从库断连后，主库会把断连期间收到的写操作命令，写入 replication buffer，同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。

repl_backlog_buffer 是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。

1. 刚开始的时候，主库和从库的写读位置在一起，这算是它们的起始位置。
2. 随着主库不断接收新的写操作，它在缓冲区中的写位置会逐步偏离起始位置，我们通常用偏移量来衡量这个偏移距离的大小，对主库来说，对应的偏移量就是 master_repl_offset。主库接收的新写操作越多，这个值就会越大。
3. 从库在复制完写操作命令后，它在缓冲区中的读位置也开始逐步偏移刚才的起始位置，此时，从库已复制的偏移量 slave_repl_offset 也在不断增加。正常情况下，这两个偏移量基本相等。
4. 主从库的连接恢复之后，从库首先会给主库发送 psync 命令，并把自己当前的 slave_repl_offset 发给主库，主库会判断自己的 master_repl_offset 和 slave_repl_offset 之间的差距。
5. 在增量复制时，主库只用把 master_repl_offset 和 slave_repl_offset 之间的命令操作同步给从库就行了。

注意：因为 repl_backlog_buffer 是一个环形缓冲区，所以在缓冲区写满后，主库会继续写入，此时，就会覆盖掉之前写入的操作。如果从库的读取速度比较慢，就有可能导致从库还未读取的操作被主库新写的操作覆盖了，这会导致主从库间的数据不一致。从库的复制进度赶不上主库，会导致主库决定从库重新进行全量复制。
我们可以调整 repl_backlog_size 这个参数。这个参数和所需的缓冲空间大小有关，默认1M。

缓冲空间的计算公式是：
缓冲空间大小 = 主库写入命令速度 操作大小 - 主从库间网络传输命令速度 操作大小。
repl_backlog_size = 缓冲空间大小 * 2。

示例：
如果主库每秒写入 2000 个操作，每个操作的大小为 2KB，网络每秒能传输 1000 个操作，那么，有 1000 个操作需要缓冲起来，这就至少需要 2MB 的缓冲空间。
repl_backlog_size应设置为4M。

小结

1. 一个 Redis 实例的数据库不要太大，一个实例大小在几 GB 级别比较合适，这样可以减少 RDB 文件生成、传输和重新加载的开销。
2. 调大repl_backlog_size这个参数，可以减少从库在网络断连时全量复制的风险。

问题：AOF 记录的操作命令更全，相比于 RDB 丢失的数据更少。那么，为什么主从库间的复制不使用 AOF 呢？
回答：

1. RDB是压缩过的二进制数据，文件很小。
2. AOF需要选择文件刷盘策略，选择不当会影响redis性能。