二、Redis持久化 _持久

目录
1.RDB
1.1 RDB流程
1.2RDB优缺点
2.AOF
2.1 AOF流程
2.2AOF缓冲区同步策略
2.3AOF重写机制
3.总结
任何一个分布式集群，都需要考虑如何避免因为故障，造成数据丢失的问题。持久化机制能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。
例如Kafka利用页缓存而非用户内存缓存数据，定期将数据持久化到硬盘，基于追加写入的方式保证磁盘的顺序写。相较于Kafka，Redis由于有自己的数据结构，需要在用户内存中对数据进行操作，持久化方式并不相同。
Redis支持RDB和AOF两种持久化机制。
AOF（ only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。
1.RDB
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。
所谓的RDB可以理解为Redis的一个全量数据文件。
1.1 RDB流程
执行命令，如果判断父进程（一般是init进程）存在子进程，则返回OK 。然后 Redis fork 出一个新子进程，fork操作时父进程会阻塞。原来的 Redis 进程(父进程)继续处理客户端请求。fork出的子进程则负责将数据保存到磁盘，生成RDB文件然后退出。通知父进程，RDB过程结束。
RDB过程实质上是一个全量异步持久化数据的过程，fork操作会复制一个子线程，通过COW（copy on write）即子进程共享父进程的内存数据，只有在进行写操作时才拷贝相应的内存数据到子进程的内存空间。通过fork操作，可以减少额外内存的消耗。
除了操作，Redis还有save操作，后者是同步操作，在整个持久化期间都会阻塞进程，损耗很大，几乎不会被使用。
1.2RDB优缺点
优点：
有优点，但不多。（狗头保命）
缺点：
为了解决Redis不适合实时持久化的风险，Redis提供了AOF持久化的方式来解决。
2.AOF
AOF（ only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF，说白了就是日志重放，这是目前Redis数据持久化的主流方式。
2.1 AOF流程
AOF流程相对来说简单不少。
所有命令以追加写入的方式写道（缓冲区）。缓冲区数据刷到硬盘。定时重写AOF文件，控制AOF文件大小。重启时加载AOF文件恢复。2.2AOF缓冲区同步策略
Redis提供了多种AOF缓冲区同步文件策略，由参数控制。
【二、Redis持久化】AOF缓冲区同步策略
可配置值
意义
写入后调用系统fsync操作，同步刷到硬盘。
写入后调用系统write操作，写入页缓存后返回。交由另一个线程每秒一次调用fsync刷到硬盘。
no
写入后调用系统write操作，写入页缓存后返回。交由系统调度fsync（默认30s）刷到硬盘。
2.3AOF重写机制
随着命令增加，AOF文件会越来越大，需要进行重写压缩它的体积。重写的原则主要为以下几条：
超时的数据不再写入文件。删除无效的中间命令，只保留最终数据的写入命令。合并多条命令，eg：lpush list a、lpush list b、lpush list c合并成lpush list a b c 。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。
AOF重写过程也可以手动触发和自动触发。以手动触发为例，展示一下，AOF的重写流程。
执行重写。fork操作复制一个子进程。父进程继续响应指令，并将新指令追加写入到。基于cow将重写后的指令数据写。生成新的AOF文件。新AOF文件写入完成，子进程通知父进程，替换旧AOF文件。3.总结 Redis提供了两种持久化方式：RDB（全量数据快照）和AOF（命令日志记录）。RDB全量快照，开销大，适用于数据冷备和复制传输。AOF记录日志，适用于实时持久化。