Redis从入门到精通( 四 ) _Redis

RDB 持久化方式的缺点如下：

内存数据全量同步，数据量大的状况下，会由于 I/O 而严重影响性能。
可能会因为 Redis 宕机而丢失从当前至最近一次快照期间的数据。

AOF 持久化：保存写状态
AOF 持久化是通过保存 Redis 的写状态来记录数据库的。
相对 RDB 来说，RDB 持久化是通过备份数据库的状态来记录数据库，而 AOF 持久化是备份数据库接收到的指令：

AOF 记录除了查询以外的所有变更数据库状态的指令。
以增量的形式追加保存到 AOF 文件中。

开启 AOF 持久化
①打开 redis.conf 配置文件，将 Appendonly 属性改为 yes 。
②修改 appendfsync 属性，该属性可以接收三种参数，分别是 always，everysec，no 。
always 表示总是即时将缓冲区内容写入 AOF 文件当中，everysec 表示每隔一秒将缓冲区内容写入 AOF 文件，no 表示将写入文件操作交由操作系统决定。
一般来说，操作系统考虑效率问题，会等待缓冲区被填满再将缓冲区数据写入 AOF 文件中。
appendonly yes#appendsync alwaysappendfsync everysec# appendfsync no 日志重写解决 AOF 文件不断增大
随着写操作的不断增加，AOF 文件会越来越大。假设递增一个计数器 100 次，如果使用 RDB 持久化方式，我们只要保存最终结果 100 即可。
而 AOF 持久化方式需要记录下这 100 次递增操作的指令，而事实上要恢复这条记录，只需要执行一条命令就行，所以那一百条命令实际可以精简为一条。
Redis 支持这样的功能，在不中断前台服务的情况下，可以重写 AOF 文件，同样使用到了 COW(写时拷贝) 。
重写过程如下：

调用 fork()，创建一个子进程。
子进程把新的 AOF 写到一个临时文件里，不依赖原来的 AOF 文件。
主进程持续将新的变动同时写到内存和原来的 AOF 里。
主进程获取子进程重写 AOF 的完成信号，往新 AOF 同步增量变动。
使用新的 AOF 文件替换掉旧的 AOF 文件。

AOF 和 RDB 的优缺点
AOF 和 RDB 的优缺点如下：

RDB 优点：全量数据快照，文件小，恢复快。
RDB 缺点：无法保存最近一次快照之后的数据。
AOF 优点：可读性高，适合保存增量数据，数据不易丢失。
AOF 缺点：文件体积大，恢复时间长。

RDB-AOF 混合持久化方式
Redis 4.0 之后推出了此种持久化方式，RDB 作为全量备份，AOF 作为增量备份，并且将此种方式作为默认方式使用。
在上述两种方式中，RDB 方式是将全量数据写入 RDB 文件，这样写入的特点是文件小，恢复快，但无法保存最近一次快照之后的数据，AOF 则将 Redis 指令存入文件中，这样又会造成文件体积大，恢复时间长等弱点。
在 RDB-AOF 方式下，持久化策略首先将缓存中数据以 RDB 方式全量写入文件，再将写入后新增的数据以 AOF 的方式追加在 RDB 数据的后面，在下一次做 RDB 持久化的时候将 AOF 的数据重新以 RDB 的形式写入文件。
这种方式既可以提高读写和恢复效率，也可以减少文件大小，同时可以保证数据的完整性。
在此种策略的持久化过程中，子进程会通过管道从父进程读取增量数据，在以 RDB 格式保存全量数据时，也会通过管道读取数据，同时不会造成管道阻塞。
可以说，在此种方式下的持久化文件，前半段是 RDB 格式的全量数据，后半段是 AOF 格式的增量数据。此种方式是目前较为推荐的一种持久化方式。
Redis 数据的恢复
RDB 和 AOF 文件共存情况下的恢复流程如下图：

文章插图

从图可知，Redis 启动时会先检查 AOF 是否存在，如果 AOF 存在则直接加载 AOF，如果不存在 AOF，则直接加载 RDB 文件。
Pineline
Pipeline 和 Linux 的管道类似，它可以让 Redis 批量执行指令。
Redis 基于请求/响应模型，单个请求处理需要一一应答。如果需要同时执行大量命令，则每条命令都需要等待上一条命令执行完毕后才能继续执行，这中间不仅仅多了 RTT，还多次使用了系统 IO 。
Pipeline 由于可以批量执行指令，所以可以节省多次 IO 和请求响应往返的时间。但是如果指令之间存在依赖关系，则建议分批发送指令。
Redis 的同步机制
主从同步原理
Redis 一般是使用一个 Master 节点来进行写操作，而若干个 Slave 节点进行读操作，Master 和 Slave 分别代表了一个个不同的 Redis Server 实例。