redis提供持久化策略,在适当的时机采用适当的手段把内存中的数据持久化到磁盘中,每次redis服务启动时,都可以把磁盘上的数据再次加载到内存中使用。
-
RDB策略(数据快照模式):在指定时间间隔内,redis服务执行指定次数的写操作,会自动触发一次持久化操作。
RDB策略是redis默认的持久化策略,redis服务开启时这种持久化策略就已经默认开启了。i.
save <seconds> <changes>
:配置持久化策略
ii.dbfilename
:redis RDB持久化数据存储的文件
iii.dir
:配置redis RDB持久化文件所在目录优点: 1. 存储的文件是紧凑的 2. 适用于备份,方便恢复不同版本的数据 3. 适用于容灾恢复,备份文件可以在其他服务器恢复 4. 最大化了redis的性能,备份时启动的是子线程,父进程不需要执行IO操作 5. 数据保存比AOF快 缺点: 1. 如果Redis因为没有正确关闭而停止工作是,到上个保存点之间的数据将会丢失 2. 由于需要经常fork子线程来进行备份操作,如果数据量很大的话,fork比较耗时,如果cpu性能不够,服务器可能是卡顿。属于数据量大的时候,一个服务器不要部署多个Redis服务。
创建快照有以下5种形式:
- 客户端发送
BGSAVE
指令,服务端会fork一条子进程将快照写入磁盘 - 客户端发送
SAVE
指令,服务端在主线程进行写入动作。一般不常使用,一般在内存不够去执行BGSVAE
的时候才用 - 设置了
SAVE
配置项,如SAVE 300 100
,那么当“300秒内有100次写入”时,Redus会自动触发BGSAVE
命令。如果有多个配置项,任意一个满足,都会触发备份 - Redis通过
SHUTDOWN
命令接收到关闭服务器的请求、或者TERM
信号时,会执行SAVE
命令,这时候会阻塞所有客户端,不在执行客户端发送的任何命令 - 当一个Redis服务器连接另外一个Redis服务器,并像对方发送
SYNC
命令开始一次复制操作时,如果主服务器目前没有在执行BGSAVE
操作,或者主服务器刚刚执行完,那么主服务器就会执行GBSAVE
- 客户端发送
-
AOF策略(追加模式):采用操作日志来记录每一次写操作,每次redis服务启动时,都会重新执行一遍操作日志中的指令。
但是AOF效率低下,redis默认不开启AOF功能。i.
appendonly
:配置是否开启AOF策略。
ii.appendfilename
:配置操作日志文件优点: 1. 使用AOF模式更加的灵活,因为可以有不同的fsync策略 2. AOF是一个日志追加文件,所有不需要定位,就算断电也没有损坏问题,哪怕文件末尾是一个写到一半的命令,redus-check-aof工具也可以很轻易的修复 3. 当AOF文件很大的,Redis会自动在后台进行重写。重写是决对安全的,因为Redis是继续往旧的文件里面追加,使用创建当前数据集所需的最小操作集合来创建一个全新的文件,一旦创建完成,Redis就会切换到新文件,开始往新文件进行追加操作 4. AOF包含一个又一个的操作命令,易于理解和解析 缺点: 1. 对于同样的数据集,AOF文件通常要大于RDB文件 2. AOF可能比RDB要慢,这取决于fsync策略。通常fsync设置为每秒一次的话性能仍然很高,如果关闭sfync,即使在很高的负载下也和RDB一样快。不过,即使在很大的写负载情况下,RDB还是能提供很好的最大延迟保证 3. AOF通过递增的方式更新数据,而RDB快照是从头开始创建,RDB会更健壮和稳定(所以适用于备份)
总结:根据数据的特点来决定开启哪种持久化策略:一般情况下,开启RDB策略足够。
参考:https://blog.csdn.net/q649381130/article/details/79920277