redis的持久化策略
时间:2019-05-21 13:29 来源:linux.it.net.cn 作者:IT
redis的持久化方式有俩种，持久化策略有4种：
RDB（数据快照模式），定期存储，保存的是数据本身，存储文件是紧凑的
AOF（追加模式），每次修改数据时，同步到硬盘(写操作日志)，保存的是数据的变更记录
如果只希望数据保存在内存中的话，俩种策略都可以关闭
也可以同时开启俩种策略，当Redis重启时，AOF文件会用于重建原始数据
RDB
RDB定时备份内存中的数据集。服务器启动的时候，可以从 RDB 文件中恢复数据集。
优点
存储的文件是紧凑的
适合用于备份，方便恢复不同版本的数据
适合于容灾恢复，备份文件可以在其他服务器恢复
最大化了Redis的性能，备份的时候启动的是子线程，父进程不需要执行IO操作
数据保存比AOF要快
缺点
如果Redis因为没有正确关闭而停止工作是，到上个保存点之间的数据将会丢失
由于需要经常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(append only file)
AOF记录服务器的所有写操作。在服务器重新启动的时候，会把所有的写操作重新执行
一遍，从而实现数据备份。当写操作集过大（比原有的数据集还大），Redis 会重写写操作集。
优点
- 使用AOF模式更加的灵活，因为可以有不同的fsync策略
- AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复
- 当AOF文件很大的，Redis会自动在后台进行重写。重写是决对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作
- AOF包含一个又一个的操作命令，易于理解和解析
缺点
对于同样的数据集，AOF文件通常要大于RDB文件
AOF可能比RDB要慢，这取决于fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证
AOF1通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份），
(责任编辑：IT)
| redis的持久化方式有俩种，持久化策略有4种： RDB（数据快照模式），定期存储，保存的是数据本身，存储文件是紧凑的 AOF（追加模式），每次修改数据时，同步到硬盘(写操作日志)，保存的是数据的变更记录 如果只希望数据保存在内存中的话，俩种策略都可以关闭 也可以同时开启俩种策略，当Redis重启时，AOF文件会用于重建原始数据 RDB RDB定时备份内存中的数据集。服务器启动的时候，可以从 RDB 文件中恢复数据集。 优点 存储的文件是紧凑的 适合用于备份，方便恢复不同版本的数据 适合于容灾恢复，备份文件可以在其他服务器恢复 最大化了Redis的性能，备份的时候启动的是子线程，父进程不需要执行IO操作 数据保存比AOF要快 缺点 如果Redis因为没有正确关闭而停止工作是，到上个保存点之间的数据将会丢失 由于需要经常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(append only file) AOF记录服务器的所有写操作。在服务器重新启动的时候，会把所有的写操作重新执行 一遍，从而实现数据备份。当写操作集过大（比原有的数据集还大），Redis 会重写写操作集。 优点 - 使用AOF模式更加的灵活，因为可以有不同的fsync策略 - AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复 - 当AOF文件很大的，Redis会自动在后台进行重写。重写是决对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作 - AOF包含一个又一个的操作命令，易于理解和解析 缺点 对于同样的数据集，AOF文件通常要大于RDB文件 AOF可能比RDB要慢，这取决于fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证 AOF1通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份）， (责任编辑：IT) |