概述
- RDB是基于定时更新生成内存快照的方式持久化，快照里存储的所有数据的最终态的数据，比如 age:30
- AOF是基于状态机+命令日志+日志压缩的方式实现持久化（类似于Zookeeper状态机机制），日志里面存储的是过程态的操作日志，比如 操作1
age:10，操作2age:20，操作3age:30 - 用户可以关闭Redis持久化的功能，也可以AOF、 RDB一起使用（restart时会根据AOF重建内存状态)
AOF更适合精准、海量数据：数据完整性要求严格、大数据存储量、人工可追溯的业务场景
RDB更适合运维方便：节省硬盘空间、更方便数据备份和恢复
rdb 定时快照持久化
- 优点：
- 定时生成一个高度压缩的二进制文件，容易备份和恢复
- 相比于AOF机制，如果数据集很大，RDB的启动效率会更高,因为快照存储的是一个最终态的数据，而不是过程态的数据
- 缺点：
- 数据不是百分百安全，未持久化的数据可能会丢失
- 当内存中的数据特别大的时候，因为每次都是生成一个完整的快照文件，速度会很慢，而AOF只有在日志压缩的时候才会面临这个问题
- 工作原理
- 将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内存快照。
- 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 #从不同步。高效但是数据不会被持久化
- 具体配置
appendonly yes
appendfilename "appendonly.aof"
appendfsync always
#配置当 AOF 文件需要比旧 AOF 文件增大多少时才进行 AOF 重写，默认和旧AOF文本大小
auto-aof-rewrite-percentage 100
#当 AOF 文件需要达到多大体积时才进行 AOF 重写
auto-aof-rewrite-min-size 64mb
- 优点：
- AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建，而RDB是二进制文件
- 数据集文件过大会自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创 建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性
- AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据
- 缺点
- 大存储数据的时候重启的时候，加载速度比RDB要慢,但是因为是追加添加日志，不存在生成大快照的卡顿的情况出现
- 相对于RDB的方式，相同的数据量AOF占用的空间更大
- 重写机制
- aof里存放了所有的redis 操作指令，当aof文件达到一定条件或者手动bgrewriteaof命令都可以触发rewrite
- rewrite之后aof文件会保存keys的最后的状态，清除掉之前冗余的，来缩小这个文件
- 重写时机：两个几乎都满足的时候才出发，比如最开始size为1kb，到了2kb不触发，至于到了64mb的时候才触发第一次
Expire过期机制
删除过期键对象，由于内存中保存了大量的键，维护键精准的过期删除机制会导致消耗大量的CPU，对于单线程的Redis来说成本过高，因此，Redis采用惰性删除和定时任务删除机制来实现过期键的内存回收。
-
惰性删除：惰性删除用于当client端读取到带有超时属性的键时，如果已经超过键设置的过期时间，会执行删除操作并返回空，该策略是出于节省CPU成本考虑，不需要单独维护TTL链表来处理过期键的删除。该方式存在内存泄漏的可能，当过期键一直没有访问将无法得到及时删除，从而导致内存不能及时释放。
-
定时任务删除：Redis内部维护一个定时任务，默认每秒运行10次，定时任务中删除过期键逻辑采用了自适应算法，根据键的过期比例，使用快慢两种速率模式回收键。
内存溢出策略
当Redis所用内存达到maxmemory上限时会触发相应的溢出控制策略，策略由maxmemory-policy参数控制，可以通过config set maxmemory-policy {policy} 动态设置。
LRU就是 least Recent Use，根据最近最少使用的
-
noeviction：默认策略，不会删除任何数据，拒绝所有写入操作并返回client端OOM错误信息，此时Redis只响应读操作；
-
allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时时间，直到释放足够的内存空间为止；
-
allkeys-random：随机删除所有键，直到释放足够的内存空间为止；
-
volatile-lru:根据LRU算法删除设置了超时属性的键，直到释放足够空间为止，如果没有可删除的键对象，回退到noeviction策略；
-
volatile-random：随机删除过期键，直到释放足够的内存空间为止；
-
volatile-ttl：根据键对象的ttl属性，删除最近将要过期的数据，如果没有，回退到noeviction策略
参考
官网讲的很详细了
https://redis.io/topics/persistence#snapshotting
https://blog.csdn.net/guweiyu_thinker/article/details/78816071
网友评论