redis持久化机制

1、redis速度快：

（1）基于内存操作：纯内存操作，内存本身就很快

（2）单线程：Redis服务器核心是基于非阻塞的IO多路复用机制，单线程避免了多线程的频繁上下文切换问题

（3）使用了高效的数据结构，例如哈希表和跳表；

2、 如果不做其他操作，redis重启则会丢失数据，故提供持久化机制，RDB（Redis Database）内存快照和AOF（Append Only File）日志

RDB：根据自己配置的时间或者手动执行BGSAVE或SAVE文件，redis生成一个二进制的RDB文件，重启时会读取文件恢复数据；

AOF：把redis所有写命令记录到日志文件里面，redis重跑日志文件，恢复数据

RDF：RDB执行SAVE或BESAVE命令，生成文件，非常耗时，如果只有一个线程处理，那其他的请求不就得等了？

redis是单线程的，但是有一套事件处理机制，主要是处理文件事件（命令请求和应答等）和时间事件（RDB定时持久化、清理过期key）

其中：定时的RDB是一个时间事件，流程：

线程轮询就绪事件 -->发现RDB可执行事件 -->调用BGSAVE命令 -->fork子进程生成RDB文件，完成持久化

fork子进程过程中是阻塞的，结束后处理请求的进程就放开

故而单线程是对的，只是fork了子线程出来处理RDB事件，在redis较新的版本中，一些删除操作（UNLINK FLUSHALL ASYNC等）、redis6.x之后对网路数据的解析都用了多线程处理，redis核心的命令请求和响应是单线程

AOF: AOF也是fork 了个子进程去做的？

AOF是在命令执行完之后，写入到buffer缓冲区，然后利用redis提供的策略（每秒一次、每条命令都执行、从不存盘)写入磁盘，然后启动之后，重新执行该命令，恢复数据；为防止没有做过处理的命令集合越来越膨胀，redis会fork一个子进程对原始命令集合进行重写（压缩），压缩完之后替换原始文件；为防止在fork子进程，主进程堵塞时数据丢失，需要将新接受的命令保存到新的缓存区；

AOF刷盘是后台线程异步的，文件重写是fork子进程

RDB恢复时间比AOF快

在Redis4.0以后也支持了AOF和RDB混合：以一定频率执行内存快照，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

AOF 和 RDB 该如何选择

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

如果redis内存已满，还需要继续写数据，需要做好对应的监控和容量的考量，等容量达到阈值事，及时发现并扩容；或者淘汰一些不活跃的点，把新数据写进去；