redis持久化使用与场景

Redis持久化方案

持久化是指将数据写入到磁盘上，Redis提供了以下几种方案:

1. RDB:
2. AOF
3. RDB+AOF

除了上面三种持久化方案，还有不开启持久化，这种场景一般是将redis当作缓存使用，不过不推荐使用，因为

RDB(Redis Database)

RDB优点

• RDB非常适合容灾场景，因为它可以设置定期时间来生成快照备份，比如每小时备份最近24小时数据。
• 在键值对较多的情况下，换句话来说，也就是内存占用比较多的时候，RDB文件比AOF占用空间更小。并且启动速度更快。
• RDB文件还可以传送到远程存储或者云存储上，所以在遇到宕机等情况更适合恢复。
• 在主从模式下，RDB支持部分重新同步。在节点重启或故障转移后，可以通过重新同步部分数据来加快恢复速度，而不需要完全重新同步整个数据集。

RDB缺点

• RDB会使用fork()创建子进程来完成持久化，一般情况下是不会阻塞redis进程的，但是数据量过大的时候就会造成几秒阻塞，对于redis来说是不可接受的，而AOF虽然也是fork()，但是根据不同的策略来调整写入频率，不会对持久性产生任何影响。

应用场景

AOF(Append Only File)

AOF优点

在持久化方面，AOF比RDB表现更好，首先AOF有三种策略:

1. Always: 同步写回，每个写命令执行完，立即同步将日志写回到磁盘上。
2. Everysec: 每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
3. No: 让操作系统控制写回，每个写命令执行完之后，只是先把日志写到AOF文件缓冲区，之后让操作系统决定什么时候将缓冲区写回到磁盘。

而且AOF日志是仅追加日志(append-only log)，每次写命令都会追加到最后一行，就算发生断电或者磁盘写满了等其他原因，日志以半写命令结束，redis-check-aof工具也能够轻松修复它。

当AOF日志文件过大时，Redis能够在后台自动对AOF进行重写。重写是完全安全的，因为在Redis继续向旧文件追加数据的同时，会生成一个包含创建当前数据集所需的最小操作集的全新文件。一旦第二个文件准备就绪，Redis会切换到新文件并开始向其追加数据。

AOF缺点

• 相同数据集下的AOF文件比

AOF应用场景