Redis-运维

转自 极客时间 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的意?