概念:Redis的高性能是由于其将所有数据都存储在了内存中,为了使Redis在重启之后仍能保证数据不丢失,需要将数据从内存中同步到硬盘(文件)中,这一过程就是持久化。
包含: RDB、AOF、不持久以及RDB+AOF-->这四种选项
1.RDB持久化机制
1.RDB概念:
RDB 持久化以指定的时间间隔执行数据集的快照。RDB持久化方式是Redis默认开启的,我们不配置也可以默认使用RDB持久化机制,持久化内存数据到磁盘
2. 触发机制
2.1.自动触发
save 900 1 900秒内至少有一次修改则触发保存的操作
save 300 1 300秒内至少有10次修改则触发保存的操作
save 60 1 60秒内至少有一万次修改则触发保存的操作
执行shutdown命令关闭服务器时,如果没有开启AOF持久化功能,那么会自动执行一次bgsave
主从同步(slave和master建立同步机制)
2.2.手动触发
save命令:会阻塞当前服务器,直到RDB完成为止,如果数据量大的话会造成长时间的阻塞,线上环境一般禁止使用
bgsave命令:就是background save,执行bgsave命令时Redis主进程会fork一个子进程来完成RDB的过程,
完成后自动结束(操作系统的多进程Copy On Write机制,简称COW)。
所以Redis主进程阻塞时间只有fork阶段的那一下。相对于save,阻塞时间很短。
3.RDB执行流程
Redis 使用操作系统的多进程 cow(Copy On Write) 机制来实现RDB快照持久化
1.执行bgsave命令的时候,Redis主进程会检查是否有子进程在执行RDB/AOF持久化任务,
如果有的话,直接返回
2.Redis主进程会fork一个子进程来执行执行RDB操作,fork操作会对主进程造成阻塞(影响Redis的读写),
fork操作完成后会发消息给主进程,从而不再阻塞主进程。(阻塞仅指主进程fork子进程的过程,
后续子进程执行操作时不会阻塞)
3.RDB子进程会根据Redis主进程的内存生成临时的快照文件,持久化完成后会使用临时快照文件
替换掉原来的RDB文件。(该过程中主进程的读写不受影响,但Redis的写操作不会同步到主进程的
主内存中,而是会写到一个临时的内存区域作为一个副本)
4.子进程完成RDB持久化后会发消息给主进程,通知RDB持久化完成
(将上阶段内存副本中的增量写数据同步到主内存)
4.RDB的优点:
1.RDB文件小,非常适合定时备份,用于灾难恢复
2.Redis加载RDB文件的速度比AOF快很多,因为RDB文件中直接存储的是内存数据,
而AOF文件中存储的是一条条命令,需要重演命令。
5.RDB缺点:
1.RDB无法做到实时持久化,若在两次bgsave间宕机,则会丢失区间(分钟级)的增量数据,
不适用于实时性要求较高的场景
2.RDB的cow机制中,fork子进程属于重量级操作,并且会阻塞redis主进程
3.存在老版本的Redis不兼容新版本RDB格式文件的问题
2.AOF持久化机制
1.AOF概念:
AOF 持久化记录服务器收到的每个写操作,这些操作将在服务器启动时再次播放,重建原始数据集。命令使用与 Redis 协议本身相同的格式以仅附加的方式记录。当日志变得太大时,Redis 能够在后台重写日志。
2.开启方式:AOF默认是关闭的,通过redis.conf配置文件进行开启
注意: 当 AOF 和 RDB 机制并存时,Redis 会优先采纳 AOF 机制。
使用 AOF 持久化文件恢复内存中的数据
。而 AOF 刚刚开启时 appendonly.aof 持久化文件中没有任何数据。
拿空的 appendonly.aof 持久化文件恢复内存,就会导致以前所有数据都丢失。
3.AOF本质就是:使用文件记录redis服务器上所有的写操作
4.重写(rewrite)机制:
AOF Rewrite 虽然是“压缩”AOF文件的过程,但并非采用“基于原AOF文件”来重写或压缩,
而是采取了类似RDB快照的方式:基于Copy On Write,全量遍历内存中数据,
然后逐个序列到AOF文件中。因此AOF rewrite能够正确反应当前内存数据的状态。
4.AOF的优点:
AOF只是追加写日志文件,对服务器性能影响较小,速度比RDB要快,消耗的内存较少
5.AOF的缺点:
AOF方式生成的日志文件太大,需要不断AOF重写,进行瘦身。
即使经过AOF重写瘦身,由于文件是文本文件,文件体积较大(相比于RDB的二进制文件)。
AOF重演命令式的恢复数据,速度显然比RDB要慢。
3.如何选择Redis的持久化选项
如果Redis仅仅作为缓存可以不使用任何持久化方式。
其他应用方式综合考虑性能和完整性、一致性要求。
RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。如果Enalbe AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘允许,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。如果不开启AOF,仅靠Master-Slave Replication 实现高可用性能也不错。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时挂掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。新浪微博就选用了这种架构。