redis 多进程_Redis持久化策略

01

Redis持久化概述

Redis是内存数据库，数据存储在内存中，为了避免进程退出而导致数据永久丢失，需要定期将Redis中的数据以某种形式保存到磁盘上，以便在redis重启时，利用持久化文件实现数据恢复，同时也可以利用持久化来实现数据的备份。 Redis持久化分为RDB持久化和AOF持久化，两者的区别在于RDB将当前内存数据快照数据保存到磁盘上，而AOF则是将每次执行的写操作命令追加到日志文件中。Redis持久化可以被禁用，也可以同时开启这两种持久化方式，当redis重启时，优先会使用AOF重建数据。

02

Redis持久化之RDB

RDB持久化策略指的是将redis内存中的数据生成一个完整的快照，以二进制格式文件保存到磁盘中，当需要进行恢复时，再从硬盘加载到内存中。

1RDB触发方式 1、客户端调用save命令 save命令执行时会造成Redis的阻塞，所有操作命令都要排队等待它完成 2、客户端调用bgsave命令 bgsave命令会创建一个子进程，由子进程负责创建RDB文件，bgsave命令在执行时，只有fork子进程时才会阻塞服务器 3、配置自动触发 自动触发在配置文件中通过save m n ,指定当m秒内发生n次变化时会触发bgsave。比如：配置save 900 100的含义是：当在900秒内redis数据至少发生了100次变化则执行bgsave命令。 2RDB执行过程

1. 当前是否在执行save、bgsave或bggrewriteaof的子进程，如果有则直接返回

2. 父进程执行fork创建子进程，这个过程父进程是阻塞的，Redis不能执行客户端的命令

3. fork完成后，basave命令返回"Background saving started"不再阻塞父进程

4. 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，并对原有文件进行替换

5. 子进程向父进程发送已完成，父进程更新统计信息

RDB启动加载

RDB文件的载入工作是在服务器启动时自动执行的，但是AOF的优先级更高，因此如果开启了AOF那么redis会优先使用AOP来恢复数据。只有点那个AOF关闭时才会在redis服务器启动时检测RDB文件并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。如果RDB文件，redis则会启动失败

4RDB常用配置

5RDB优缺点

优点

• RDB文件体积小，利于网络传输，适合全量复制

• 数据恢复速度快

缺点

• 无法做到实时持久化，如果机器挂掉或者进程被杀掉那么上次快照之后写入的数据将会丢失。

• 占用IO资源

03

Redis持久化之AOF

AOF(Append Only File)持久化是将redis每次写命令追加到到单独的日志文件中，当redis重启时以此来恢复数据。 1AOF刷新策略 redis执行写命令，会将命令写入硬盘缓冲区中。

• always：即时将缓冲区中的数据写入到磁盘上
• everysec：每秒刷新到硬盘上，发生故障可能会丢失一秒的数据。aof默认的策略
• no：由操作系统来决定刷新的频率

2AOF执行流程

1、命令追加

redis将写命令追加到缓冲区aof_buf，主要是为了避免每次都直接将命令写入磁盘，导致磁盘IO成为redis负载瓶颈

2、文件同步和写入

对于文件的写入，为了提高文件的写入效率，操作系统提供了write函数和fsync函数。

2.1 write函数：操作系统为提高磁盘数据的读写速度，使用文件缓存page cache来加速磁盘数据的读写效率，当用户调用write函数将数据写入文件时，操作系统通常会把数据先写入到内存缓冲区中，当缓冲区被写满或到达指定时限后，才被真正写入到磁盘上。

2.2 fsync函数：write函数虽然提高了效率，但是如果机器宕机缓存区数据就会丢失，因此操作系统同时提供了fsync、fdatasync等同步函数，强制将缓冲区的数据立刻写入到磁盘上。

• always：命令写入aof_buf后立即调用系统fsync函数同步到AOF文件，fsync完成后线程返回，这种策略每次写命令都会同步到AOF文件，磁盘IO成为性能瓶颈，redis只能支持大约几百QPS，严重影响redis性能
• everysec：命令写入aof_buf后调用系统write操作，write操作完成后返回；fsync同步文件操作由专门的线程每秒调用一次
• no：命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步，同步由操作系统负责，通常同步周期为30秒。这种策略文件同步的时间不可控，且缓冲区堆积的数据可能会很多，数据安全性不能得到保证

3、文件重写 redis服务器执行的写命令越来越多，aof文件也越来越大，磁盘占用也越来越多，通过数据恢复需要的时间也越来越长。例如递增一个计数器100次，那么最终结果就是数据集里的集水器的值为最终递增结果，但是AOF文件会把这100次操作完整的记录下来。而事实上要恢复这个记录只需一条命令即可。 文件重写流程

1、Redis父进程首先判断当前是否存在正在执行basave/bgwriteaof的子进程，如果存在则bgewriteaof命令直接返回，如果存在bgsave命令完成后再执行 2、父进程执行fork操作创建子进程，这个过程是阻塞的 3、fork成功后，bgrewriteaof命令返回“Background append only file rewrite started”信息不再阻塞进程，并可以响应其他命令，Redis的所有命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有aof机制的正确。由于fork操作使用使用写时复制技术，子进程只能共享fork操作时的内存数据，并且在bgrewriteaof执行期间，redis写命令同时追加到aof_bug和aof_rewrite_buf两个缓冲区 4、子进程写完AOF文件后，向父进程发信号，父进程更新统计信息。父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新的AOF文件所保存的数据库状态和服务器当前状态一致 5、将新的AOF文件替换为老文件，完成AOF重写

文件重写的触发方式

• bgrewriteaof

调用bgrewriteaof命令，父进程fork一个子进程执行aof的重写工作

• 配置文件

auto-aof-rewrite-min-size：执行AOF重写文件最小体积，默认值为64MB auto-aof-rewrite-percentage：执行AOF重写当前AOF文件大小和上次重写AOF文件大小的比值，如果要禁用自动的AOF重写，将此值设置为0即可 只有auto-aof-rewrite-miin-size和auto-aof-rewrite-percentage两个参数同时满足才会自动触发AOF重写。 AOF持久化总结 1、AOF重写指把Redis进程内的数据转化为写命令，并生成新的aof文件，不会对旧的aof文件进行任何的读取写入操作 2、主进程在将新的变动写入到内存的buffer同时也会把新的变动更新到旧AOF里，这样即使重写失败也可以保证数据安全 3启动时加载 Redis在启动时优先载入AOF文件恢复数据，只有当AOF关闭时才会载入RDB文件恢复数据；如果AOF开启但是没有AOF文件，即使RDB文件存在也不会加载 4AOF持久化常用配置

04

总结

无论是RDB还是AOF策略持久化都会对性能有所影响。

1、对于RDB来说，bgsave在进行fork子进程时主进程会阻塞；同时也会带来磁盘IO压力

2、对于AOF来说，向磁盘写入也有可能带来磁盘IO压力，甚至可能造成AOF追加阻塞问题，另外AOF重写也会有fork子进程阻塞主进程的问题

所以在生产环境中，可以选择AOF和RDB的一种，或者同时开启两者，又或者不使用任何持久化等。此外，持久化的选择要和Redis的主从策略一起考虑，因为主从复制与持久化同样具有数据备份的功能，而且主机master和从节点slave可以独立的选择持久化策略