Redis主从、哨兵、集群模式介绍

先来收悉下Redis的持久化方式：
RDB快照：默认情况下，Redis将内存数据库快照保存为名为dump.rdb二进制文件，可以设置他的初九话规则为N秒内发生了M次改动时就做一次保存动作 列： “60秒内有至少有1000个键被改动”这一条件时，自动保存一次数据集：配置文件有体现# save 60 1000
此处有个知识点：命令bgsave,就是写时复制机制，在生成快照持久化时任然可以处理写命令，他是由主线程fork出的子线程。也就是前面提到过的Redis并不是单线程。
AOF : RDB有个缺点，当服务宕机后，会确实最近没达到持久化条件一段时间内的数据。所以AOF出现了，他是规定多长时间就持久化一次，推荐每秒同步一次，即使故障也就那一秒的数据没有。这样的话文件就会较大，所以当恢复采用aof文件，碎度就会稍慢。Redis4.0混合持久化，先采用RDB快照恢复，再用AOF补充缺失的部分数据。重启效率大大提高
一、Redis主从架构

1.为什么需要主从复制？
虽然单台的Redis的并发能达到10万，但是始终有局限性，这时建立主从模式，可以实现读写分离，一个master负责写，多个从节点负责读，从而提升并发能力。
但是与之而来会带出另一个问题，主从复制风暴：当从节点过多，会导致主节点给从节点同步数据时压力过大，解决方式可以让从节点与从节点同步数据。

如果某一个实例master挂掉，我们需要手动把一台从服务器切换为主服务器，还会造成一段时间内服务不可用。为了解决主从模式不能高可用的问题，就发明了哨兵模式

二、哨兵高可用模式

哨兵模式很特殊，他不提供读，也不提供写，主要是做监控Redis实例节点。为了挽救不成熟的主从架构而生。为什么这么说，很简单，主从架构中，如果主节点挂了，没有从节点能代替上位成为主节点。
sentinel哨兵是特殊的Redis服务，哨兵模式下，cline端第一次找出Redis的主节点，后续直接访问Redis的主节点，当主节点发生变化，哨兵第一时间感知到，并将新的Redis主节点通知给客户端。为了实现高可用，sentinel必须是需要集群，当Redis的主节点挂了，每一个发现其下线的sentinel都会开始都票选举出自己醒目中的从节点作为主节点对外提供服务。
至此好像Redis的高可用已经很完美，但是他有个致命的缺点，甚至都会被主从架构看不起：哨兵模式中，只有Redis的主节点对外提供服务，从节点不提供读写，只是当做成为主节点上位的备胎使用，这样在高并发的情况下，并发不升反降。
3.高可用集群模式
1.上面提到过哨兵模式中，哨兵集群主要作用可归功于自动选举，但是并发能力上不去，只有Redis的master节点对外提供读写服务，从节点只是备份节点等待上位。说了这么多，那么集群模式下的从节点难道可以对外提供读服务，想多了其实也是一样，只是作为备份。之所以叫集群模式，是因为他有多个master节点，组成集群，这样多个master一起对外提供服务，提升并发能力

官方描述：redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵∙也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。
数据分布的实现原理：Redis 集群将所有数据划分为16384个槽位，每个节点（主节点）负责其中的一部分，当我们根据key存放的时候，Redis根据CRC16算法得出一个结果，然后对16384求余数，这样每个key都会落在0-16383之间，然后找到对应的节点区间。

总结下选举机制：集群模式下，各个master之间会互相通信，当通信超时则认为下线了，此时下线的主节点所对应的所有从节点开始抢夺上位成主节点，当半数的集群主节点同意才能选举成功。从节约资源的角度除法考虑集群主节点设置为奇数个。哨兵模式下sentinel选举也是同样的机制。