RDB
- 简介
RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。 - 两种触发方式
- 手动触发
- save：
该命令会阻塞redis,在sava期间，不能执行其他命令，直到持久化完成。 - bgsave：
该命令不会阻塞redis，在后台进行的。该触发方式会fork一个子进程，由子进程负责持久化，因此阻塞只会发生在fork子进程的时候。
- save：
- 自动触发
- 手动触发
除了根据redis配置文件配置规则自动触发，还有下面三种触发方式：
1、从节点全量复制时，主节点发送一个rdb文件给从节点完成复制操作时，主节点会触发bgsave。
2、执行debug reload时自动触发RDB持久化。
3、执行shutdown时，若没有开启aof 也会触发RDB持久化。
- RDB持久化流程
这里注意的是fork操作会阻塞，导致Redis读写性能下降。我们可以控制单个Redis实例的最大内存，来尽可能降低Redis在fork时的事件消耗。以及上面提到的自动触发的频率减少fork次数，或者使用手动触发，根据自己的机制来完成持久化。 - RDB优缺点
- 优点
- RDB 是紧凑的二进制文件，比较适合备份，全量复制等场景
- RDB 恢复数据远快于 AOF
- 缺点
- RDB 无法实现实时或者秒级持久化；
- 新老版本无法兼容
RDB格式。
AOF
- 简介
使用AOF持久化时，Redis会将每一个收到的写命令都通过write函数追加到文件中，类似于MySQL的binlog。当Redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于OS会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。这样AOF方式的持久化也还是有可能会丢失部分修改。 - 配置AOF
-
- AOF原理
采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时，会把AOF文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。
AOF的整个流程大体分为两步，一步是命令的实时写入（如果是appendfsync everysec配置，会有1s损耗），第二步是对aof文件的重写（重写是直接把当前内存的数据生成对应命令）。
对于增量追加到文件这一步主要的流程是：命令写入=》追加到aof_buf =》同步到aof磁盘。那么这里为什么要先写入buf在同步到磁盘呢？如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。
aof重写的目的是为了减少aof文件的大小，可以手动(bgrewriteaof)或者自动触发(根据配置规则触发)。
- 在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；因此它依然会写入旧的AOF file中，如果重写失败，能够保证数据不丢失。
- 为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据。
- 重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。
- AOF文件直接采用的文本协议，主要是兼容性好、追加方便、可读性高可认为修改修复。
- AOF的优缺点
- 优点
- 可以更好地保护数据不丢失；
appen-only模式写入性能比较高；- 适合做灾难性的误删除紧急恢复。
- 缺点
- 对于同一份文件，AOF 文件要比 RDB 快照大；
- AOF 开启后，会对写的 QPS 有所影响，相对于 RDB 来说 写 QPS 要下降；
- 数据库恢复比较慢， 不合适做冷备。
混合持久化机制
基本上都不会是单独使用每一种方式解决持久化的。因为都存在问题。4.0版本的混合持久化默认关闭的，通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，5.0之后默认开启。混合持久化是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据，
优点： 混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。
缺点： 兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差
RDB和AOF的对比
- redis提供了rdb持久化方案，为什么还要aof？
优化数据丢失问题，rdb会丢失最后一次快照后的数据，aof丢失不会超过2秒的数据 - 如果aof和rdb同时存在，听谁的？
aof - rdb和aof优势劣势
rdb 适合大规模的数据恢复，对数据完整性和一致性不高 ,在一定间隔时间做一次备份，如果redis意外down机的话，就会丢失最后一次快照后的所有操作aof 根据配置项而定。
官方建议 两种持久化机制同时开启，如果两个同时开启 优先使用aof持久化机制
Redis 淘汰策略有哪些？
Redis 可以看作是一个内存数据库，通过 Maxmemory 指令配置 Redis 的数据集使用指定量的内存。设置 Maxmemory 为 0，则表示无限制。当内存使用达到 Maxmemory 极限时，需要使用某种淘汰算法来决定清理掉哪些数据，以保证新数据的存入。
- Redis的淘汰策略
noeviction：禁止驱逐数据，也就是当内存不足以容纳新入数据时，新写入操作就会报错，请求可以继续进行，线上任务也不能持续进行，采用no-enviction策略可以保证数据不被丢失，这也是系统默认的一种淘汰策略。allkeys-lru：从数据集中挑选最近最少使用的数据淘汰，该策略要淘汰的key面向的是全体key集合，而非过期的key集合。volatile-lru：除了淘汰机制采用LRU，策略基本上与volatile-lru相似，从设置过期时间的数据集中挑选将要过期的数据淘汰，ttl值越大越优先被淘汰。allkeys-random：从数据集中选择任意数据淘汰。volatile-random：从已设置过期时间的数据集中任意选择数据淘汰。当内存达到限制无法写入非过期时间的数据集时，可以通过该淘汰策略在主键空间中随机移除某个key。volatile-ttl：除了淘汰机制采用LRU，策略基本上与volatile-lru相似，从设置过期时间的数据集中挑选将要过期的数据淘汰，ttl值越大越优先被淘汰。