Redis持久化
redis提供了将数据定期自动持久化到硬盘的能力,包括RDB和AOF两种方案,两种方案分别由其长处后短处,可以配合起来同事运行,去报数据的稳定性。
必须使用数据持久化?
redis的数据持久化机制是可以关闭的。如果你只是把redis作为缓存使用redis中存储的所有数据都不是该数据的主题而仅仅是同步过来备份的,那么可以关闭redis的数据持久化机制。
但通常来说,简历至少开一RDB方式数据的持久化, 因为:
- RDB方式的持久化几乎不损耗redis本身的性能,在进行RDB持久化时,Redis主进程,唯一需要做的事情,就是forck一个子进程,所有持久化都由子进程来完成。
- Redis无论因为什么原因crash调后,重启时,能够自动恢复到上次RDB快照中记录的数据。着省去了手工从其他数据源(如DB),同步数据过程,而且要比其他方式要快,
- 现在硬盘那么大,真的不缺那一点地方
RDB
采用RDB持久化方式,redis会定期保存数据快照至一个rdb文件中,并在启动时自动加载rdb文件,恢复之前保存的数据。可以在配置文件中配redis进行快照博保存的时机:
save [seconds] [changes]
意为在[seconds]秒内如果发生了[changes]次数据修改,则进行一次RDB快照保存,例如
save 60 100
会让Redis每60秒检查一次数据变更情况,如果发生了100次或以上的数据变更,则进行RDB快照保存。
可以配置多条save指令,让Redis执行多级的快照保存策略。
Redis默认开启RDB快照,默认的RDB策略如下:
save 900 1
save 300 10
save 60 10000
也可以通过BGSAVE命令手工触发RDB快照保存。
RDB的优点:
对性能影响最小。如前文所述,Redis在保存RDB快照时会fork出子进程进行,几乎不影响Redis处理客户端请求的效率。
每次快照会生成一个完整的数据快照文件,所以可以辅以其他手段保存多个时间点的快照(例如把每天0点的快照备份至其他存储媒介中),作为非常可靠的灾难恢复手段。
使用RDB文件进行数据恢复比使用AOF要快很多。
RDB的缺点:
快照是定期生成的,所以在Redis crash时或多或少会丢失一部分数据。
如果数据集非常大且CPU不够强(比如单核CPU),Redis在fork子进程时可能会消耗相对较长的时间(长至1秒),影响这期间的客户端请求。
AOF
采用AOF持久方式时,Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时,会把AOF文件中记录的所有写操作顺序执行一遍,确保数据恢复到最新。
AOF的优点:
最安全,在启用appendfsync always时,任何已写入的数据都不会丢失,使用在启用appendfsync everysec也至多只会丢失1秒的数据。
AOF文件在发生断电等问题时也不会损坏,即使出现了某条日志只写入了一半的情况,也可以使用redis-check-aof工具轻松修复。
AOF文件易读,可修改,在进行了某些错误的数据清除操作后,只要AOF文件没有rewrite,就可以把AOF文件备份出来,把错误的命令删除,然后恢复数据。
AOF的缺点:
AOF文件通常比RDB文件更大
性能消耗比RDB高
数据恢复速度比RDB慢