redis高可用方案
主从复制
这个模式就是解决单台机器的内存性能问题，可以把主实例和从实例放到不同的机器上面。从机器可以作备份使用，当master主机出现故障时，可以将某一台slave提升为master。一定程度上提高缓存的高性能，如果能接受一定的延迟，也可以做一个主从分离，所有的读都从slave上来，提高性能。缺点是没有故障转移和监测。如果master挂了，还需要手动切到slave上面去。你的应用程序连接地址也得做相应的改动。
主从复制的过程
当slave第一次启动连接master，或者被认为是第一次连接，是主从采用全量复制，全量复制的执行过程如下。
slave redis 会启动，会从redis.conf 中读取 master ip 和 host。
定时任务每秒会检查是否有新的 master 需要连接，如果发现就与 master 建立 socket 连接。
slave 会发送 ping 指令到 master。
如果 master 配置 require pass，slave 需要发送认证给 master。
salve 会发送sync命令到master。
master 会启动一个后台进程，将 redis 中的数据快照 rdb保存到文件中。
启动后台进程的同时，master 会把保存的数据快照期间接收到的写命令缓存起来。
master 完成写文件操作后，把 rdb发送给salve。
当salve 完成数据快照的恢复以后，master 会把这期间收集的写命令发送给salve端。
后续master收集到的写命令都会通过之前建立的连接，增量的发送给salve端。
增量复制
当slave节点与master全量同步以后，master节点上的数据会再次发生更新，就会触发增量复制。
当我们在master服务器增减数据的时候，会触发一个相关的函数，接下来在Master服务器上调用每一个命令都会
使用相关的函数来同步到slave服务，当然在执行此函数之前，master服务都会判断用户执行的命令是否有数据更新，
如果有数据更新，并且slave服务器不为空，才会执行此函数，函数的主要工作就是把用户执行的命令发送到所有的slave服务，让slave服务器执行。
端点续传
端点续传，是针对master和slave之间断开连接进行优化的。主要过程如下
从服务器向主服务器发送psync命令，携带主服务器的runid和复制偏移量。
主服务器验证runid和自身的runid是否一致，如果不一致，就会进行全量复制。
主服务器验证复制偏移量是否积压在缓冲区内，如不一致，就会进行全量复制。
如果都验证通过，则主服务器将会保持在积压区内的偏移量后的所有数据发送给从服务器，主服务器将会再次回到一致的状态。
哨兵模式
这个模式呢，和主从模式有点像，他是基于主从模式的。他提供了对master的监控和故障转移，当master节点出现故障后，可以自动通过选举选出一台slave做master，待master故障恢复后，再切回来，这就大大提高了可用性了，且哨兵之间也可以做集群部署，相互监测。防止单个哨兵死掉的情况。
哨兵是一个分布式架构，其中包含若干个哨兵节点和Redis数据节点，每个哨兵节点会有多个哨兵节点进行监控，当发现节点不可达的时，会对节点做下线的标识，如果标识是主节点，还会和其他哨兵节点进行协调，当大多数哨兵节点都认为主节点不可达的时，会选举出一个哨兵节点来完成自动的故障转移的工作，同时会把这个变化实时的通知给redis应用方，整个过程完全自动，不需要人工介入。
缺陷是写操作无法负载均衡、存储能力受到单机的限制。
哨兵的流程如下所示
基本的故障转移过程
主节点出现故障，此时两个从节点与主节点失去连接，主从复制出现失败。
每个哨兵节点通过定期监控发现主节点出现故障
多个哨兵节点对主节点的故障达成一致会选举出一个节点作为领导者，进行故障转移。
哨兵领导者节点执行了故障转移，整个过程和手动的调整一致，只是自动化完成的。
故障转移以后整个结构如下所示，重新选举了新的主节点。
集群
通过集群，Redis解决了写操作无法负载均衡以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
todo。。。