Reids持久化和高可用

本文主要是介绍Reids持久化和高可用，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Reids持久化和高可用

Redis持久化

• 持久化：将书籍从掉电易失的内存存放到能够永久存储的设备上
• Redis服务是使用内存来存储数据，如果掉电、服务崩溃都会导致Redis中数据丢失，如有必要，可以持久化数据。
• Redis持久化方式：RDB(Redis DB)、AOF(AppendOnlyFile)

RDB

• 在默认情况下，Redis将某时间点的数据快照保存在名字为dump.rdb的二进制文件中

• 策略

  1. 自动：按照配置文件中的条件满足就执行BGSAVE
  2. 手动：客户端发起SAVE、BGSAVE命令

• 配置

  1. /etc/redis/redis.config配置文件。注意这里是我自己安装时修改了配置文件路径。具体配置文件请查找redis配置文件

  save 900 1 #如果900秒内，有一次更新，或者增加过，会保持落地数据一次
  save 300 10 # 如果在300秒内，有10次以上的改动，会自动保存落地数据一次
  save 60 10000 # 如果在60秒有10000次改动，或10000次以上的改动，就自动保存落地数据一次#数据文件名称
  dbfilename dump.rdb
  #数据文件存放目录
  dir /var/lib/redis/6379
  

  1. save 60 1000,Redis要满足在60秒内至少有1000个键被改动，会自动保存一次，只要满足上面3个条件之一，就自动执行快照。

     • 执行完成后，时间计数器和次数计数器都会归零重新计数。这多个条件不是叠加效果
     • SAVE命令：阻塞式命令，执行期间不响应客户端请求
     • BGSAVE:非阻塞命令，执行期间还可以接受并处理请求，会folk一个子进程创建RDB文件

     127.0.0.1:6379> SAVE
     127.0.0.1:6379> BGSAVE
     

• 优点

  1. 完全备份，不同时机的数据集备份可以做到多版本恢复
  2. 紧凑的单一文件，方便网络传输，适合灾难恢复
  3. 快照文件直接恢复，大数据集速度比AOF快些

• 缺点

  1. 会丢失最近写入、修改的而未能持久化的数据
  2. folk过程较耗时，会造成毫秒级不能响应客户端请求

• RDB备份策略

  1. 创建一个定时任务cron job,每小时或者每天将dump.rdb复制到指定目录
  2. 确保备份文件名称带有日期时间信息，便于管理和还原对应的时间点的快照版本
  3. 启用定时任务删除过期的备份
  4. 如果有必要，跨物理主机、跨机架、异地备份

AOF

• Append only file,采用追加的方式保存，默认文件appendonly.aof。
• AOF实质是记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库

AOF写入机制

• AOF方式不能保证绝对不丢失数据

• 目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区(buffer)里面，等到缓冲区被填满，或者用户执行fsync调用fdatasync调用时才将存储在缓冲区里面的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失

• 写入磁盘的策略

1. appendfsync选项，这个选项的值可以是always、everysec或者no

   • Always:服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到磁盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
   • Everysec(默认): 服务器每一秒重调用一次fdatasync,将缓冲区里面的命令写入到磁盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据

这篇关于Reids持久化和高可用的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---