在说到Redis主从同步之前先说说同步过程中会用到的Pipeline
Redis客户端与Redis服务器之间使用TCP协议进行连接,一个客户端可以通过一个socket连接发起多个请求命令。每个请求命令发出后client通常会阻塞并等待redis服务器处理,redis处理完请求命令后会将结果通过响应报文返回给client,因此当执行多条命令的时候都需要等待上一条命令执行完毕才能执行。
简单的说普通模式单线程的,而Pipelin模式是类似于并发的
Pipeline
- Plpeline和Linux的管道类似
- Redis基于请求/响应模型,单个请求处理需要一一应答
- Pipeline批量执行指令,节省多次IO往返的时间
- 有顺序依赖的指令可以分批发送
一句话:pipeline是通过减少客户端与redis的通信次数来实现降低往返延时时间,而且Pipeline 实现的原理是队列,而队列的原理是时先进先出,这样就保证数据的顺序性。
Pipelin性能虽好但不使用与线上使用,因为线上的操作大都需要及时返还操作结果,但是用在主从的增量同步刚好啊!
Redis主从同步可分为两种:全量同步和增量同步
主从全量同步:一般发生在Slave初始化阶段
- Slave发送sync命令道Master
- Master启动一个后台进程,将Redis中的数据快照保存到文件中(BGSAVE)
- Master将保存数据快照期间指令收集到写指令缓存起来
- Master完成写文件操作后,将该文件发送给Slave,并在发送期间继续记录被执行的写命令
- Slave丢弃所有旧数据,载入新的快照
-
Slave完成快照载入,开始接受命令请求,并执行Master发送的缓存指令
主从增量同步:Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程
- Master接收到用户的操作指令,判断是否需要传播到Slave
- 将操作记录追加到AOF文件
- 将操作传播到其他Slave:a对齐主从库;b往相应缓存写入指令
- 将缓存数据发送给Slave
- Slave执行Master发送的缓存指令
Redis主从可以用来读写分离,Master用来处理写操作,Slave处理读操作(可能会有延迟),但毕竟是单点,万一Master宕机了怎么办?那么就有了哨兵机制的出现,通过自动完成故障发现和转移保证服务的高可用。
Redis Sentinel:解决主从同步Master宕机后主从切换问题
监控:检查主从服务器是否正常运行
* 每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图,哨兵配置时只要配置对主节点的监控即可,通过向主节点发送info,获取从节点的信息,并当有新的从节点加入时可以马上感知到;
* 每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息,同时每个哨兵节点也会订阅该频道,来了解其它哨兵节点的信息及对主节点的判断,其实就是通过消息publish和subscribe来完成的
* 每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测,这个也是哨兵用来判断节点是否正常的重要依据
提醒:通过API向管理员或其他应用程序发送故障通知
自动故障迁移:主从切换
* 选出一个Slave脱离原从节点升级为主节点
* 将其他Slave指向新的主节点
* 通知客户端主节点已更换
* 将原Master变成从节点,指向新的Master
流言协议Goddip--在杂乱无章中需求一致
- 每个节点都随机与对方通信,最终所有节点的状态达成一致
- 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
- 不保证信息一定会传递到所有节点,但保证最终的一致性