pipeline
倘若我们使用Redis进行批量生产数据，然后存入缓存，通常情况下，我们理解的是，上一条缓存，存完了之后才轮到下一个存储指令的执行。这样势必会让Redis的性能降低，而实际上Redis也针对此进行了一定的优化，而优化的方法，也就是关于Redis针对Pipeline的使用：
- pipeline和linux的管道类似
- pipeline批量执行指令，节省多次IO往返的时间
- 有顺序依赖的指令建议分批发送
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，同步信息。
并且以上讲述的同步，也分为两种，一种是全同步，一种是增量同步。我细节的将上述的操作重新表达一下：
- 全同步过程
Slave发送sync命令给Master，
Master启动一个后台进程，
将Redis中的数据快照保存到文件中（BGSAVE），
Master将保存数据快照期间受到的写命令缓存起来（存入内存Buffer），
Master完成写文件操作之后，
将该文件发送给Slave（同步），
最后使用新的AOF文件替换掉旧的AOF文件（完成AOF的同步），
最后，Master将这期间收集到的增量写命令发送给Slave端（完成最终一致）。
- 增量同步过程
Master接收到用户的操作指令，判断是否需要传播到Slave，
将操作记录追加到AOF文件，
将操作传播到其他Slave：1、对齐主从库，2、往响应缓存写入指令。
将缓存中的数据发送给Slave
但是主从同步，也是有一定的弊端的：
不具备高可用性，只要Master挂了，就不能写入缓存了
于是Redis官方就提供了Redis Sentinel，也就是哨兵模式。
- Redis Sentinel
解决主从同步Master宕机后的主从切换问题：
监控：检查主从服务器是否运行正常。
提醒：通过API向管理员或者其他应用程序发送故障通知。
自动故障迁移：当出现Master宕机之后，会使用投票协议（类似zk）选择Slave当老大，重新主从同步，代替之前的Master。
我们可以使用留言协议Gossip来接收主服务器是否下线的信息
它可以：
- 每个节点都随机的与对方通信，最终所有节点的状态都达成一致。
- 种子节点定期随机向其他节点列表以及需要传播的信息。
- 不保证信息一定会传递给所有节点，但是最终会趋于一致。
