redis（二）redis的主从模式和集群模式
主从模式
集群模式
主从模式
redis的主从模式，指的是针对多台redis实例时候，只存在一台主服务器master，提供读写的功能，同时存在依附在这台主服务器的从服务器slaver，只提供读服务，且数据和主服务器保持一致。主服务器只能有一台，从服务器可以有多台，而且可以存在级联模式(从服务器下面也挂载从服务器)。主从的存在是为了分散访问量，提高访问可读性，同事保证数据的冗余和备份。
从服务器需要在配置文件中指定主服务的地址 slaveof 127.0.0.1 6379(主服务器的ip)。
redis的主从数据同步：
1、全量同步：
一般出现在从节点初始化阶段，全量数据需要从主节点上复制过来。
收到同步命令之后，master都会启动一个后台进程，将数据库快照保存到文件中，同时master主进程会开始收集新的写命令并缓存起来。如果master同时收到多个 slave发来的同步连接命令，只会使用启动一个进程来写数据库镜像，然后发送给所有slave，但是可能出现io剧增导致主服务器宕机。
2、增量同步：出现在从服务器初始化成功之后，开始正常提供服务之后，对主服务器发起增量同步，主服务器通过之前建立好的连接，发送写命令给从服务器。在增量同步失败的情况下，可以发起全量同步。
哨兵作用：
哨兵模式的出现，是为了弥补主服务突然宕机的情况下，能够及时选举出新的主服务器，使得服务依旧可用。 通过sentinel.conf配置文件进行配置 sentinel monitor mymast 192.168.110.133 6379 1 #主节点 名称 IP 端口号 选举次数
哨兵模式，指的是在原有主从的基础之上，增加sentinel系统来实时用来监听redis的健康状况。哨兵本质也是redis，用于监听redis服务，哨兵模式是集群模式，每个哨兵都是实时想其他哨兵，master，slaver发送心跳，来判断是都活着。当出现master不能访问的时候，采集其他哨兵对master的判断情况，当有半数以上的投票判断master死亡之后，哨兵集群会通过一定的算法来重新选举出一个slaver节点作为master，以保证整个reids服务的可用性。
选举结束之后，所有的配置文件都会发生修改。
正对死亡的reids实例，哨兵也会监听。当原来死亡的主服务器重新恢复之后，哨兵集群会把它当做从服务器加入到redis服务中。
自动切换ip漂移：
在主从模式下，客户端访问redis的服务器的ip地址是固定的，通过keepalived，可以使得客户端在redis故障切换之后，不需要修改ip，只需要访问固定的虚拟ip就可以。
集群模式
redis集群模式，指的是针对多个redis实例，去中心化，去中间件，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态，并且每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
redis集群没有统一的ip入口，客户端与redis节点直连,不需要中间proxy层，客户端访问任意一个节点，都可以进入集群，访问集群的所有数据。节点内部使用PING-PONG机制来互相通信，当集群添加一个节点的时候，只需要连接集群中任意一个节点即可，不需要连接所有节点。(https://blog.csdn.net/nihao12323432/article/details/81204499)
当超过半数的master节点检测某个master节点失效时(通行超时)，该节点才会失效，进行故障转移。因此必须要有3个以上的master才可以创建出集群。
如果一个master进行故障转移的时候，发现没有slaver来使用，那么整个集群fails。当整个集群有一半的master出现故障，无论有没有slaver，整个集群fails。
通过 redis-trib.rb create --replicas 1来创建集群。
哈希槽：
哈希槽的存在，是为了能快速找到key所在的节点。一个redis集群包含2^16=16384个哈希槽，会分配给各个节点。可以通过槽的分配来控制不同节点的数据量和请求数。哈希槽通过顺时针来分片，即一个节点顺时针到下一个几点之间的槽属于下一个节点。
每一个key，通过公式slot=CRC16（key）/16384来计算属于哪个槽。
扩容的时候，只需要动一个节点的数据即可。eg.A->B(顺时针)，中间插入C节点，那么只修要迁移B的数据，重新分配到B和C中即可。
每一个redis实例节点都会保持元数据对应的哈希槽信息，数据会不断的同步。
