Redis的持久化方式
redis提供两种持久化机制:RDB内存快照方式和AOF文件追加方式。这两种方式均在redis.config文件中进行配置。
RDB方式:
在配置的多个save <seconds> <changes> 条件中,满足一个时,触发内存快照操作。此时,操作系统会调用fork()函数复制一个子进程,通过copy-on-write机制共享父进程的
当前内存空间(可当做当前内存空间的一个镜像去理解),并将该内存区域的数据集写到一个临时的二进制文件.rdb文件中,完成之后,通过rename替换原来的.rdb文件。此时,若父进程恰有数据写入,操作系统会将该片数据空间复制一份。这部分数据不会记录到子进程写入的rdb文件中,只能等待下次fork的子进程去快照。当子进程结束后,父进程再对该片数据的原始内存空间进行替换。这种方式的好处在于,子进程在进行快照的时候,不会阻塞父进程的读写操作。当然,也可以自己通过redis客户端去发送save或bgsave命令进行手动快照,但这样,该客户端的读写也将被阻塞,性能不如copy-on-write。
AOF方式:
通过配置appendfsync的参数强制操作系统写入磁盘的时机,有三种策略:always(只要有写命令就调用fsync写磁盘)、everysec (每秒钟强制写磁盘)、no(以来操作系统自行调度fsync,大多数linux操作系统是30s)。由于每次写入的AOF都比较大(写入的是数据的所有历史变更记录),因此,从效率和数据安全上考虑,推荐everysec 方式。redis提供了对大的aof文件的重写功能(实际就是类似rdb的方式,遍历当前内存数据空间,以单条命令(如直接用set命令记录某个key的当前值)记录数据的当前状态代替旧aof文件中用多条命令记录数据状态的历史变更。不过,在rewrite的时候,如果父进程接收到写请求,则该数据会被写到缓冲区中,等子进程写临时AOF文件结束后,再通知父进程将缓冲区的变更数据写入到该临时文件中,写完之后再替换原始aof文件)。由auto-aof-rewrite-percentage(当前aof文件超过上次aof文件的百分比)和auto-aof-rewrite-min-size(满足最小rewrite文件的大小)参数实现AOF文件的rewrite策略。
应用场景选择:
如果系统非常关心数据,但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。 因为定时生成 RDB 快照非常便于进行数据库备份, 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快 。一般需要结合两者方式使用,当redis故障宕机后,先采用rdb方式恢复数据到内存,只有当恢复失败时,才会采用AOF进行恢复。