redis集群

1.数据同步:主从复制异步执行
选取主节点
主从复制:
redis.conf 文件进行配置 slaveof  主节点IP  端口号
protected-mode属性:no表示成功
bind：IP  表示允许访问的节点IP  如果不限制直接注释即可

2.原理（）
    全量复制:(初始化)例如新启动一个节点,先链接到主服务器,发送命令（SYNC）到主服务器,主服务器会执行bgsave生成快照并发送给从服务器，从服务器进行load操作进行快照复制,如果生成快照时有其他相
关操作会被存到缓存中，并以命令的方式发送到从节点
    增量复制:主从节点之间心跳机制进行连接的通信
配置:min-slaves-to-write 3 表示只有当3个或以上的slave节点连接到master节点时才能去写入
min-slaves-max-lag 10(s) 表示10秒内没有收到slave的心跳回馈的时候认为slave节点是挂的
master_repl_offset：偏移量(记录上一次同步的位置)redis2.8版本以后采用
    无磁盘复制：redis2.8只有引入，不去生成磁盘快照,之间在内存中生成一个.rdb的文件直接进行主从同步
配置:repl-diskless-sync no 无磁盘复制配置启动

选主(哨兵机制sentinel-外部机制):master选举

哨兵的作用
1.监控master和slave是否运行正常
2.当master出现故障的时候,从slave中选举一个新的master
哨兵也是支持集群的,哨兵之间相互监控
哨兵之间也有一个内部选举机制:raft协议
哨兵会订阅master节点：sub(channel:sentinel:hello)
leader的选举机制:当有一个slave节点检测到leader节点宕机或没有leader节点时,它会向所有的slave节点发送选举请求,此时其它节点也会监控并发现这一情况并发送选举请求,此时最先发送的请求会得到认同,当有
一个节点超过半数以上节点的认同时,则会被选举为leader节点，此时leader节点会发起一个数据同步的操作,将leader节点的数据作为基准同步其他节点的数据,每个节点的请求时间是随机的，这样可以错开所有节点
的投票发送以及请求接收的时间,避免2个slave节点同时进行选举

配置：sentinel.conf 文件中sentinel  monitor mymaster  监控节点  接口端口 数量(标识集群中有几个哨兵节点认为master挂了才会真正认为master挂了)

问题:如果集群中数据量很大的时候,数据量会存储在每个节点,每个节点的数据量都很大
解决:进行redis分片
redis在3.0以后提供了一个redis-cluster
最早的方法来实现redis-cluster使用的是一致性hash算法-->codis（根据redis源码实现的一种方式）/twemproxy(分片管理)/redis-cluster数据分片，路由扩容等
redis-cluster:基于gossip协议的无中心化节点的集群,根据一定的规则将数据路由存储到每一个redis集群中,此时redis集群最好是由一个master和一个slave组成,即可以很高效的存储数据,又可以进行数据key进行
分区存储,同时master节点宕机以后slave节点能够直接顶替master节点加入分片存储
redis cluster bus
redis集群中有一个虚拟槽的概念0-16383（slot）
然后每个节会分配不同的槽位,如果此时的分片有3个master节点,那么3个节点部署在不同的机器上,每个master分配到的槽总和为16383
举例:
分片1:0-5000
分片2:5001-10000
分片1:10001-16383
此时redis存储一个数据 (set  a  111) 此时通过算法取模:CRC16(key)%16383如果=2000,此时这个数据会落在第一个节点上,此时此master对应的slave节点会同步存储此数据
此时如果有些业务需求希望此业务的相关数据都落到同一个分片中(HashTag)，此时可以通过设置一个有规则的key来处理这个业务需求:比如3个key分别为id,name,sex,此时设置命名的时候:
user:(user1):id,user:(user1):name,user:(user1):sex，此时计算的取模的时候会使用括号中的user1来进行计算取模,这个就是(HashTag)的应用

分片存储值后需要去获取值:get a MOVED（如果获取的key不在访问的节点上,此时会返回 MOVED192.168.111.12:8080告诉你需要的数据在哪个节点上）

分片迁移:如果redis节点增加一个或者减少一个的时候,slot需要重新分配，此时的分配规则是从每个节点取出一部分slot(槽)进行迁移,此时会有2个迁移
1.slot迁移
2.数据迁移

说明:如果需要讲masterA中的1，2,3三个槽位迁移到masterB中去,迁移的过程中会有一些不稳定的状态,通过这些状态可以使redis扩展的时候进行热迁移,不需要进行停机
先将masterA中的槽位设置为MIGRANTING状态(表示slot正在迁移),并设置masterB中的状态设置为IMPORTING状态(表示slot正在迁入)
MIGRANTING状态会存在2个约束
1.如果客户端访问的key还没有迁移出去,则正常处理key
2.如果key已经迁移或者不存在,则回复ASK信息跳转到masterB去执行
IMPORTING状态
1.当客户端的访问不是从ASK跳转的时候,不允许修改(防止数据不一致)返回MOVED命令去相应的原节点执行
此处约束的作用:使得slot迁移的时候都是去原节点做迁移操作,然后原节点已经迁移的数据会通过ASK信息跳转到转移后的节点执行,或者是在原节点直接修改

twemproxy:在所有节点中自行实现了一个分片管理
缺点:1.无法动态扩容
2.数据迁移很麻烦
codis:豌豆荚开源的中间件,基于redis源码实现的一种分布式集群的解决方法,支持动态扩容和缩容,数据迁移方便,可以合理利用多CPU