这是我参与2022首次更文挑战的第2天，活动详情查看2022首次更文挑战
自动化触发RDB持久化
- 根据redis.conf配置里的SAVE m n定时触发（m:代表多少秒 n:代表写命令次数 用的是BGSAVE）
- 主从复制时，主节点自动触发
- 执行Debug Reload
- 执行Shutdow且没有开启AOF持久化
BGSAVE原理
系统调用fork():创建进程，实现了Copy-on-Write
RDB持久化
缺点：
- 内存数据的全量同步，数据量大会由于I/O而严重影响性能
- 可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据
RDB是Redis默认的持久化方式，按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。（快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品）
AOF：Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于Mysql的binlog，当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。
Redis的主从复制
持久化保证了即使redis服务重启也不会丢失数据，因为redis服务重启后会将硬盘上持久化的数据恢复到内存中，但是当redis服务器的硬盘损坏了可能会导致数据丢失，如果通过redis的主从复制就可以避免这种单点故障。
Redis是单线程，但Redis为什么这么快？
- 完全基于内存，绝大部分请求是纯碎的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作时间复杂度都是O(1)；
- 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的
- 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或多进程导致的切换而消耗CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。
- 使用多路I/O复用模型，非阻塞IO，“多路”：多个网络连接，“复用”：复用同一个线程
- 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接构建了VM 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
