关于redis:Redis核心技术笔记0506

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 性能。