转自 极客时间 Redis 亚风 原文视频：https://u.geekbang.org/lesson/535?article=681062

Redis 同步

Redis主从数据同步,主从第⼀次同步是全量同步

replicaof 主机 端口 #当前这个机器做Master的备份

master如何判断slave是不是第⼀次来同步数据：
Replication ld：简称replid，是数据集的标记，id⼀致则说明是同⼀数据集。每⼀个master都有唯⼀的replid，slave则会继承master节点的replid。
Offset：偏移量，随着记录在repl_baklog中的数据增多⽽逐渐增⼤。slave完成同步时也会记录当前同步的offset。
如果slave的offset⼩于master的offset，说明slave数据落后于master，需要更新。
因此slave做数据同步，必须向master声明⾃⼰的replication id 和offset，master才可以判断到底需要同步哪些数据。

如果slave重启后同步，会进⾏增量同步。

repl_baklog⼤⼩有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致数据被覆盖，则⽆法实现增量同步，只能再次全量同步。slave 和Master 始终保持着一点差距，也就是上面的Slave 节点追不上 Master 节点了，超过一圈，后面的数据就被重写了。

可以从以下⼏个⽅⾯来优化Redis主从集群
在master中配置repl-diskless-sync yes启⽤⽆磁盘复制(需要看网络带宽，作为了解不太实用)，避免全量同步时的磁盘IO。
Redis单节点上的内存占⽤不要太⼤，减少RDB导致的过多磁盘IO
适当提⾼repl_baklog的⼤⼩，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步

⼀个master上的slave节点数量，如果实在是太多slave，则可以采⽤主-从-从链式结构，减少master压⼒。

哨兵

slave节点宕机恢复后可以找master节点同步数据，那master节点宕机怎么办？
Redis提供了哨兵(Sentinel）机制来实现主从集群的⾃动故障恢复。哨兵的结构和作⽤如下：

• 监控：Sentinel 会不断检查master和slave是否按预期⼯作
• ⾃动故障恢复：如果master故障，Sentinel会将⼀个slave提升为master。当
故障实例恢复后也以新的master为主
• 通知：Sentinel充当Redis客户端的服务发现来源，当集群发⽣故障转移时，
会将最新信息推送给Redis的客户端
Sentinel基于⼼跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

上下线检测及选举
• 主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
• 客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的⼀半。⼀旦发现master故障，sentinel需要在salve中选择⼀个作为新的master，选择依据是这样的：
1） ⾸先会判断slave节点与master节点断开时间⻓短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
2） 然后判断slave节点的slave-priority值，越⼩优先级越⾼，如果是0则永不参与选举
3） 如果slave-prority⼀样，则判断slave节点的offset值，越⼤说明数据越新，优先级越⾼
4）最后判断slave节点的运⾏id⼤⼩，越⼩优先级越⾼
当选中了其中⼀个slave为新的master后（例如slave1），故障的转移的步骤如下：
1）sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master。
2） sentinel给所有其它slave发送slaveof ip port命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
3）Sentinel将故障节点标记为slave（修改配置），当故障节点恢复后会⾃动成为新的master的slave节点。
sping 针对主从的应用

spring.redis.sentinel.master=mymaster
spring.redis.sentinel.node=ip:port,ip:port

连接Sentinel的时候需要指定这个bean

这⾥的ReadFrom是配置Redis的读取策略，是⼀个枚举，包括下⾯选择：
MASTER： 从主节点读取
MASTER_PREFERRED：优先从master节点读取，master不可⽤才读取replica
REPLICA: 从slave (replica）节点读取
REPLICA_PREFERRED：优先从slave (replica）节点读取，所有的slave都不可⽤才读取master

Redis 分片集群

主从和哨兵可以解决⾼可⽤、⾼并发读的问题。但是依然有两个问题没有解决：
• 海量数据存储问题
• ⾼并发写的问题
使⽤分⽚集群可以解决上述问题，分⽚集群特征：
• 集群中有多个master，每个master保存不同数据
• 每个master都可以有多个slave节点
• master之间通过ping监测彼此健康状态
• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

Redis会把每⼀个master节点映射到0~16383共16384个插槽 (hash slot）上，查看集群信息时就能看到：

数据key不是与节点绑定，⽽是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：
Key中包含{}，且{}中⾄少包含1个字符，{}中的部分是有效部分
key中不包含{}，整个key都是有效部分
例如：key是num，那么就根据num计算，如果是{a}num，则根据a计算。计算⽅式是利⽤CRC16算法得到⼀个hash值，然后对16384取余，得到的结果就是slot值。

cluster failover命令可以⼿动让集群中的某个master宕机，切换到执⾏cluster failover命令的slave节点，实现⽆感知的数据迁移。⼿动的failover⽀持三种不同模式：
• 缺省：默认的流程，如下面的图
不常用下面两个命令：
• force：省略了对offset的⼀致性校验（不管当前节点是否与Master有距离）
• takeover：直接执⾏第5歩，忽略数据⼀致性、忽略master状态和其它master的意⻅