剑指Offer(Redis)——Pipeline及主从同步模式和哨兵模式
Pipeline
加入使用Redis进行批量生产数据然后存入缓存，一般情况下是上一条缓存存完之后才轮到下一个存储指令的执行，这样肯定会让Redis性能降低，实际上Redis对此情况进行了一定的优化，优化方法就是Redis针对Pipeline的使用:
- Pipeline和Linux的管道类似；
- Redis基于请求/响应模型，单个请求处理需要一一应答；
- Pipeline批量执行指令，节省多次IO往返的时间；
- 有顺序依赖的指令建议分批发送。
Redis同步机制
主从同步原理
通常Redis都是由一个Master和若干Slave组成的，Master负责写，Slave负责读(Master纯写是为了提升性能)。
每个Master-Slave都代表一个Redis-Server实例：
为了保证Redis最终一致性，不一定要保证Master和Slave之间的数据一定要一直都是同步的，但是肯定会经过一段时间会趋于同步，这就是最终一致性。
Redis可以如上图所示进行主从同步也可以进行从从同步。
第一次同步时候，Master做一次BGSAVE并同时将后续的修改操作记录到内存Buffer中，操作结束之后将RDB同步到Slave中当Slave接收到RDB文件之后，就会将RDB文件作为镜像加载到内存中，等同步到内存之后还会将这一系列在Master的操作和增量的数据再发送给Slave进行同步信息。
所谓同步也是分为两种的，一种是全同步，一种是增量同步。将这两种同步讲解一下：
- 全同步过程
1、Slave发送sync命令到Master；
2、Master启动一个后台进程，将Redis中的数据快照保存到文件中；
3、Master将保存数据快照期间接收到的写命令缓存起来；
4、Master完成写文件操作后，将该文件发送给Slave；
5、使用新的AOF文件替换掉旧的AOF文件；
6、Master将这期间收集的增量写命令发送给Slave端。
- 增量同步过程
1、Master接收到用户的操作指令，判断是否需要传播到Slave；
2、将操作记录追加到AOF文件中；
3、将操作传播到其他Slave：(1)、对齐主从库;(2)、往响应缓存写入指令；
4、将缓存中的数发送给Slave。
主从同步也是有一定的弊端：
- 不具备高可用性，Master挂掉之后就不提供写入缓存的接口
- Redis为解决这个问题t提供了Redis Sentinel就是哨兵模式
Redis Sentinel
解决主从同步Mater宕机后主从切换问题：
- 监控：检查主从服务器是否运行正常
- 提醒：通过API向管理员或者其他应用程序发送故障通知
- 自动故障迁移：当出现Master宕机之后使用投票协议(类似Zookeeper)选择剩下的Slave中的一个来当Master，重新主从同步，代替之前的Master
使用流言协议Gossip来接收主服务器是否下线的信息，可以实现的功能如下：
- 每个节点都随机的与对方通信，最终所有的节点状态达成一致
- 种子节点定期随机向其他节点发送节点列表以及需要传播的信息
- 不保证信息一定会传递给所有节点，但是最终会趋于一致