redis持久化

RDB

• 在指定时间间隔,将内存中的数据写入到硬盘,redis会fork一个子线程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化号的文件,整个过程中,主进程是不进行任何IO操作的,者就确保了极高的性能,如果需要进行大规模数据的回复,且对数据恢复的完整性不是非常敏感,那么RDB方式要比AOF方式更加的高效,RDB的缺点是最后一次持久化后的数据可能丢失

• fork是复制一个和当前进程一样的进程,新进程的所有数据都和袁锦程一致,该操作可能占用大量内存导致系统宕机

• 配置文件位置:

• 生成的dump.rdb

AOF

• 以日志的形式来记录每个写操作,将redis执行过的所有写指令记录下来,只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

• 配置文件位置:

• 生成的appendonly.aof

• AOF和RDB可同时存在,优先使用AOF进行数据恢复

• AOF和RDB修复

  ---

  RDB同理

• ReWrite

  • AOF采用文件追加方式,文件会越来越大,为了避免这种情况,新增了重写机制,当AOF文件的大小超过设定的阈值时,Redis就会启动AOF文件的内容压缩.只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof

  • AOF文件持续增长而过大时,会fork出一条新的进程来将文件重写,遍历新进程的内存中的数据,每条记录有一条Set语句.重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写成一个新的aof文件.

  • 配置文件详情

主从复制

• 主机数据发生变动,会自动同步到从机的master/slaver机制,master以写为主,slaver以读为主,主要用于读写分离容灾恢复

• 详细配置:

  • 从节点配置:

    slaveof 主机实际ip(如:192.168.92.130) 端口号

    如:salveof 192.168.92.130 6379

  • 最终效果:

    主节点:

    从节点:

    ---

• 哨兵模式

  先创建sentinel.conf配置文件,名字不能错

  并在sentinel.conf中添加一句话: sentinel monitor <主节点名字,随便写> <主节点ip:172.17.0.5,docker下该ip为docker分配的容器ip:'docker inspect 容器名称或id'命令查看> <主节点端口号:6379> <票数超过多少时成为新的主节点:1>

  通过redis-sentinel <sentinel.conf的路径>命令启动,使用了docker的话要在redis容器内部启动,哨兵最少起三个才能保证高可用.