一 主从切换
master和slave的主从切换，保证了服务的高可用；
二 哨兵（sential）机制
sential本身也需要部署，并且也是集群的方式部署，然后和redis集群一起协同工作。
哨兵至少部署三个实例，
因为哨兵采用的是多数选举机制，比如3个节点，多数是2；5个节点，多数是3.。。。
当多数哨兵都认为master挂了，可以进行故障转移，才能进行转移。
如果只部署了2个节点，而2个节点的多数还是2。假设一个哨兵节点挂了，那么剩下的一个是无法进行故障转移判断的。
所以经典的哨兵部署是3个节点，gurom=2；（节点数和gurom比较，取大者）
三 数据丢失问题和解决方案
- 主备切换时，会发生数据丢失。
- 故障现象：当主还在接收数据，而由于网络原因，导致主同步到备数据很慢。当发生主备切换时，主上还没有同步的数据就会丢失了。
- 解决方案1：修改redis主从复制的延迟参数，比如可以修改为10秒，那么如果主发现数据同步到备所需时间超过了十秒，就会拒绝客户端的数据写入，以保证主数据能够同步到备。
设定时长的目的，主要是确保这个数据丢失范围是可控的，即便丢失也是在一个短时间范围内。 - 解决方案2：当主拒绝接收新的写入请求，就需要客户端从处理，对新的数据进行缓存或者写入频率降级，比如本地数据缓存，或者把数据缓存到kafka中，再慢慢消费到redis中等等。
- 集群脑裂，导致数据丢失
- 故障现象：所谓脑裂，就是当master正常运行，但是master和哨兵的网络断了，让哨兵以为master挂了，于是就选举slave为新的master，这样集群中就有了两个master，而老的master可能刚好又有client在写入数据。 当老的master重新接入集群时，它就只能变成slave，从新的master里同步数据。这样就导致老master的最后写入的数据丢失。
- 解决方案: 还是一样设置slave数据落后于master数据时间的时长，比如设置为10秒，那么只要master发现slaver落后了，就会停止client写入数据。于是真正丢失的数据也只有10秒钟。
四 哨兵推举slave的机制
- 排除与master连接断开最久的slave；
- 按照slave优先级（配置中指定）来排序，取最高优先级；
3.同一优先级，则看哪个offset做多，即同步数据最多的作为master； - 如果都一样，那么就看哪个slave 的 run id 最小，就取那个。
