Redis进阶:Redis的持久化机制
Redis的持久化机制目前包括RBD和AOF两种方式。
RDB持久化
RDB持久化方式是在指定的时间间隔对数据进行快照存储。过期的键值不会被存储到快照中。如果恢复数据时数据已过期，会通过主动或被动清理策略进行删除。
- 优点：性能影响小，恢复速度快。与AOF相比，在回复大数据量时，速度更快。
- 缺点：save是阻塞式创建快照，如果数据大会影响其他命令的响应。强行关闭或者出现故障的情况下，会存在数据丢失的情况。
//创建子线程异步将快照写入磁盘
bgsave
//阻塞式存储快照，执行该命令时，不在响应其他指令
save
// Redis.Config 可以对save配置进行调整。两个条件满足一个都会触发生成快照。
save 900 1 //900S内 至少1次写操作 触发 快照
save 300 10 //300S内 至少10次写操作 触发 快照
save 60 10000 //60S内 至少10000次写操作 触发 快照 AOF持久化
记录每次对服务器写的操作。服务器重启时会重新执行命令来恢复数据。AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
- 优点：安全 容灾 备份文件易读可修改。
缺点：备份文件占用空间大，恢复速度比RDB较慢。
- 开启： redis.config中的appendonly属性值修改为yes，默认为no。
AOF策略调整
//每次修改都写入AOF 绝对不丢失数据。最安全
appendfsync always
//每秒写入一次AOF 默认策略 在周期内同样存在丢失数据的情况。
appendfsync everysec
//关闭AOF持久化 性能最好
appendfsync no如何选择持久化方式
- 如果想要达到PostgreSQL的数据安全性，推荐两种方式同时使用。
- 如果可以承受一定时间内（几分钟或者几秒）,可以只使用RDB快照方式。
- 很多用户只使用AOF方式，但是官方不推荐，因为定时生成快照方式便有数据管理，同时AOF在特定情况BRPOPLPUSH存在BUG的情况，因为RDB是从头开始创建，理论上更加健壮。
注意
Redis虽然提供了RDB快照及AOF两种持久化的方式，但这两种方式各有利弊：
- RDB不能保证数据完全不丢失，会存在部分数据丢失的情况，具体丢失的数据有多少，具体取决于业务数据量大小及Redis配置文件中关于RDB的触发机制配置。
- 使用AOF同样会存在在数据丢失的情况，具体是和appendfsync配置的周期有关，同时AOF会降低Redis的读写性能，而且无法支持较大的数据量。
以上就是Redis中持久化操作的相关介绍了，更多其他指令可以参考官网，Redis官网，谢谢阅读，希望对你有所帮助。