剑指Offer(redis)——Pipeline及主从分布原理和哨兵模式讲解

pipeline

倘若我们使用Redis进行批量生产数据，然后存入缓存，通常情况下，我们理解的是，上一条缓存，存完了之后才轮到下一个存储指令的执行。这样势必会让Redis的性能降低，而实际上Redis也针对此进行了一定的优化，而优化的方法，也就是关于Redis针对Pipeline的使用：

1. pipeline和linux的管道类似

2. pipeline批量执行指令，节省多次IO往返的时间

3. 有顺序依赖的指令建议分批发送

Redis的同步机制

• 主从同步原理

一般情况下，Redis都是由一个Master和若干个Slave组成的，master负责写，slave负责读（虽然Master也可以读，但是我们一般让master纯写，是为了提升性能）。

每一个Master-Slave都代表一个Redis-server实例。

为了保证Redis的最终一致性，我们不一定要保证Master和Slave之间的数据一定一直都得是同步的。但是肯定会经过一段时间会趋于同步，这就是所谓的最终一致性。

Redis可以如图所示，进行主从同步，也可以进行从从同步。

在第一次同步的时候，Master做一次BGSAVE，并同时将后续的修改操作记录到内存Buffer中，等到操作结束之后，将rdb同步到Slave中，当Slave接收到rdb文件之后，就会将rdb文件作为镜像加载到内存中，等到同步到内存之后，还会将这一系列在Master的操作和增量的数据，再发送给Slave，同步信息。

并且以上讲述的同步，也分为两种，一种是全同步，一种是增量同步。我细节的将上述的操作重新表达一下：

1. 全同步过程

Slave发送sync命令给Master，

Master启动一个后台进程，

将Redis中的数据快照保存到文件中（BGSAVE），

Master将保存数据快照期间受到的写命令缓存起来（存入内存Buffer），

Master完成写文件操作之后，

将该文件发送给Slave（同步），

最后使用新的AOF文件替换掉旧的AOF文件（完成AOF的同步），

最后，Master将这期间收集到的增量写命令发送给Slave端（完成最终一致）。

2. 增量同步过程

Master接收到用户的操作指令，判断是否需要传播到Slave，

将操作记录追加到AOF文件，

将操作传播到其他Slave：1、对齐主从库，2、往响应缓存写入指令。

将缓存中的数据发送给Slave

但是主从同步，也是有一定的弊端的：

不具备高可用性，只要Master挂了，就不能写入缓存了

于是Redis官方就提供了Redis Sentinel，也就是哨兵模式。

• Redis Sentinel

解决主从同步Master宕机后的主从切换问题：

监控：检查主从服务器是否运行正常。

提醒：通过API向管理员或者其他应用程序发送故障通知。

自动故障迁移：当出现Master宕机之后，会使用投票协议（类似zk）选择Slave当老大，重新主从同步，代替之前的Master。

我们可以使用留言协议Gossip来接收主服务器是否下线的信息

它可以：

1. 每个节点都随机的与对方通信，最终所有节点的状态都达成一致。
2. 种子节点定期随机向其他节点列表以及需要传播的信息。
3. 不保证信息一定会传递给所有节点，但是最终会趋于一致。