Redis-4-持久化 *** 作&主从复制

Redis-4-持久化 *** 作&主从复制

文章目录

• 1 Redis的持久化
• • 1.1 RDB
  • 1.2 AOF
• 2 主从复制
• • 2.1 主从复制概述
  • 2.2 搭建一主两从
  • 2.3 主从复制原理
  • 2.4 薪火相传
  • 2.5 哨兵模式 sentinel

1 Redis的持久化 1.1 RDB

RDB即Redis Data base 指在指定的时间间隔将内存中的数据集快照写入磁盘
也就是snapshot快照，它恢复时将快照文件直接读入内存，以持久化Redis的数据

Redis工作时会单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束后，再用临时文件替换上次持久化好的文件dump.rdb，整个过程主进程不进行IO以保证性能，但RDB的最后一次持久化后的数据可能丢失

RDB的优劣：

优势：
1，适合大规模的数据恢复
2，对数据完整性和一致性要求不高的场景更适用
3，节省磁盘空间
4，恢复速度快

劣势：
1，创建子进程时，需要临时空间，内存有额外占用
2，RBD每隔一段时间备份一次，如果Redis意外宕机，可能丢失最后一次的修改

1.2 AOF

AOF即Append only File，以日志的形式记录每个写 *** 作
将Redis执行的所有写 *** 作记录下来，日志文appendonly.aof只允许追加不允许改写
Redis启动时就会读取日志文件中的指令全部执行一遍，以恢复数据

其工作过程类似RDB，主进程会先fork出子进程，保证主进程不承担IO *** 作，由子进程将Redis内存中数据保存到临时文件，并将新的写请求记录，之后替换原先的AOF文件
AOF的优劣:

优势:
1，备份机制更稳健，丢失数据概率更低
2，可读的日志文件，通过 *** 作AOF文件，可以处理 *** 作失误

劣势:
1，比起RDB要占用更多的磁盘空间 不仅存数据还要存命令
2，恢复数据的过程速度慢

2 主从复制 2.1 主从复制概述

主从复制：主机数据更新后根据配置和策略，自动同步到备份机的master/slave机制
Master以写为主，Slave以读为主

采用主从复制的机制，可以：
1，实现读写分离，扩展应用性能
2，容灾快速恢复，某从机异常宕机后，其他从机可以分担它的工作

2.2 搭建一主两从

搭建一主两从：

1，创建并启动三个Redis服务器A,B,C
将A作为主机使用，BC作为从机使用

2，在BC从机上使用slave of [masterIP] [masterPort]
让BC正式成为A的从机

一主两从搭建成功后，在主机上写的数据 可以在从机上读取到 在从机上进行写 *** 作会报错

主从体系的特点：

1，从服务器宕机后重启需要指定主服务器ip+port 才能重新成为从服务器
且重启的过程会复制主服务器中的数据，不用担心重启的从服务器数据丢失的问题

2，主服务器宕机后，从服务器能感知到主服务器宕机
主服务器重启后，自动重新回到主服务器的位置

2.3 主从复制原理

在主从体系中，写 *** 作由主服务完成，从服务器会复制主服务器中的数据并提供读服务
slave从master复制数据的过程如下：

1，从服务器连接到主服务器后，slave会向master发送进行数据同步的消息

2，master会将自己的数据持久化RDB，将rdb文件发给slave
slave拿到rdb文件后读取并加载到内存，完成复制

3，每次master完成写 *** 作后，都会主动和slave进行数据同步

由于所有的写 *** 作都是对于master进行的，master完成写 *** 作后还要同步slave，以更新slave中的数据
保证体系中所有机器的数据一致性，但同步过程有一定的延迟，当系统很繁忙时和slave数量的增加会导致延迟问题会更加严重，这就是复制延迟的问题，也可能导致数据不一致

2.4 薪火相传

考虑公司一个研发部门中，一开始一个leader管理三五个人，有什么事能很快的同步沟通
但随着公司的发展，研发部人数到了100人，一个人来管理这100人同步工作是不现实的
为此将这100人划分几个组，leader只用管理同步几个组长就能间接管理这100人

回到Redis一主多从的体系中，如果体系中只有1个master但有10个slave时
master每次完成写 *** 作时都要同步10个slave，这是低效且耗时的
为此将slave中的一两台机器看做是组长，master来同步这些组长，组长再同步剩下的slave
组长是leader的slave，剩下的组员是组长的slave
这样能提高整个体系的工作效率和master压力

但该设计也有明显缺陷，体系里的组长宕机后，master完成写 *** 作后，
该组长机下的slave无法复制到最新的数据，导致数据不一致的问题

2.5 哨兵模式 sentinel

当master异常宕机后，slave可以感知到master的离开
且可以让其slave来成为master管理其他的slave
可以在某台slave中通过slaveof no one命令 将该slave变为master

但这样通过输入命令的方式在线上环境是不可取的，运维人员即使及时发现了master宕机
想要重启master或让某个slave成为master起码要做远程连接等工作
为此我们希望当某个master宕机后，slave中可以自动选出一个机器成为新的master

哨兵模式：能够监测master是否故障，如果故障根据投票数自动将某slave转换为master

1，创建sentinel.conf文件

2，在sentinel.cong文件中 配置哨兵
sentinel monitor [mymaster] [ip] [port]
mymaster就是被监控的master 名字可以自己取
ip+port用来指明master 

3，启动哨兵，哨兵会监控master的状况
当master异常宕机后，会从slave中根据策略选择一个slave成为新的master
且原先的master将会成为新master的slave

选举新master规则：

优先级在redis.config中默认为100，值越小优先级越高，可自行配置replica-priority
偏移量指和master数据同步程度最高的，如master有10条数据，slaveA有8条，slaveB有5条，slaveA偏移量大
runid指每个redis服务启动后会随机生成一个40位id