概述

1. RDB是基于定时更新生成内存快照的方式持久化，快照里存储的所有数据的最终态的数据，比如 age:30
2. AOF是基于状态机+命令日志+日志压缩的方式实现持久化（类似于Zookeeper状态机机制），日志里面存储的是过程态的操作日志，比如 操作1 age:10 ，操作2 age:20，操作3 age:30
3. 用户可以关闭Redis持久化的功能，也可以AOF、 RDB一起使用（restart时会根据AOF重建内存状态)

AOF更适合精准、海量数据：数据完整性要求严格、大数据存储量、人工可追溯的业务场景
RDB更适合运维方便：节省硬盘空间、更方便数据备份和恢复

rdb 定时快照持久化

1. 优点：

• 定时生成一个高度压缩的二进制文件，容易备份和恢复
• 相比于AOF机制，如果数据集很大，RDB的启动效率会更高,因为快照存储的是一个最终态的数据，而不是过程态的数据

2. 缺点：

• 数据不是百分百安全，未持久化的数据可能会丢失
• 当内存中的数据特别大的时候，因为每次都是生成一个完整的快照文件，速度会很慢，而AOF只有在日志压缩的时候才会面临这个问题

3. 工作原理

• 将Reids在内存中的数据库记录定时 dump到磁盘上的RDB持久化，
• 正常退出会执行一次生成快照，但是kill进程的方式则不会触发退出时生成快照
  实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
• save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
• save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
• save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

4. RDB配置
   redis.conf （记得启动的时候要指定这个配置文件 windows 下 ./redis-server.exe redis.conf)

# 设置10秒内如果改动达到3个就生成一个快照
save 10 3

rdbcompression yes
rdbchecksum yes

# 设置二进制快照的名字
dbfilename dumpTest.rdb

# 设置快照文件的路径
dir ./

AOF（append only file）

内部机制类似于zab：状态机+命令日志的形式

以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

• appendfsync always #每次有数据修改发生时都会写入AOF文件。
• appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
• appendfsync no #从不同步。高效但是数据不会被持久化

1. 具体配置

appendonly yes
appendfilename "appendonly.aof"
appendfsync always

#配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写，默认和旧AOF文本大小
auto-aof-rewrite-percentage 100

#当 AOF 文件需要达到多大体积时才进行 AOF 重写
auto-aof-rewrite-min-size 64mb

2. 优点：

• AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建，而RDB是二进制文件
• 数据集文件过大会自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创 建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性
• AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据

3. 缺点

• 大存储数据的时候重启的时候，加载速度比RDB要慢,但是因为是追加添加日志，不存在生成大快照的卡顿的情况出现
• 相对于RDB的方式，相同的数据量AOF占用的空间更大

4. 重写机制

• aof里存放了所有的redis 操作指令，当aof文件达到一定条件或者手动bgrewriteaof命令都可以触发rewrite
• rewrite之后aof文件会保存keys的最后的状态，清除掉之前冗余的，来缩小这个文件
• 重写时机：两个几乎都满足的时候才出发，比如最开始size为1kb，到了2kb不触发，至于到了64mb的时候才触发第一次

Expire过期机制

删除过期键对象，由于内存中保存了大量的键，维护键精准的过期删除机制会导致消耗大量的CPU，对于单线程的Redis来说成本过高，因此，Redis采用惰性删除和定时任务删除机制来实现过期键的内存回收。

1. 惰性删除：惰性删除用于当client端读取到带有超时属性的键时，如果已经超过键设置的过期时间，会执行删除操作并返回空，该策略是出于节省CPU成本考虑，不需要单独维护TTL链表来处理过期键的删除。该方式存在内存泄漏的可能，当过期键一直没有访问将无法得到及时删除，从而导致内存不能及时释放。

2. 定时任务删除：Redis内部维护一个定时任务，默认每秒运行10次，定时任务中删除过期键逻辑采用了自适应算法，根据键的过期比例，使用快慢两种速率模式回收键。

内存溢出策略

当Redis所用内存达到maxmemory上限时会触发相应的溢出控制策略，策略由maxmemory-policy参数控制，可以通过config set maxmemory-policy {policy} 动态设置。
LRU就是 least Recent Use，根据最近最少使用的

1. noeviction：默认策略，不会删除任何数据，拒绝所有写入操作并返回client端OOM错误信息，此时Redis只响应读操作；

2. allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时时间，直到释放足够的内存空间为止；

3. allkeys-random：随机删除所有键，直到释放足够的内存空间为止；

4. volatile-lru:根据LRU算法删除设置了超时属性的键，直到释放足够空间为止，如果没有可删除的键对象，回退到noeviction策略；

5. volatile-random：随机删除过期键，直到释放足够的内存空间为止；

6. volatile-ttl：根据键对象的ttl属性，删除最近将要过期的数据，如果没有，回退到noeviction策略

参考

官网讲的很详细了
https://redis.io/topics/persistence#snapshotting

https://blog.csdn.net/guweiyu_thinker/article/details/78816071