一、主从
1. 主从复制
- 方式一、新增redis6380.conf, 加入slaveof 192.168.42.111 6379, 在6379 启动完后再启6380，完成配置；
- 方式二、redis-server --slaveof 192.168.42.111 6379
- 查看状态：info replication
- 断开主从复制：在slave 节点，执行6380:>slaveof no one
- 断开后再变成主从复制：6380:> slaveof 192.168.42.111 6379
- 数据较重要的节点，主从复制时使用密码验证： requirepass
- 从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致
- 传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis 提供repl-disable-tcp-nodelay 参数决定是否关闭TCP_NODELAY,默认为关闭
参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，
参数启用时：主节点合并所有数据成TCP 包节省带宽，默认为40 毫秒发一次，取决于内核，主从的同步延迟40 毫秒，适用于网络环境复杂或带宽紧张，如跨机房
2. 数据同步
redis 2.8 版本以上使用psync 命令完成同步，过程分“全量”与“部分”复制
全量复制：一般用于初次复制场景（第一次建立SLAVE 后全量）
部分复制：网络出现问题，从节占再次连主时，主节点补发缺少的数据，每次数据增加同步
心跳： 主从有长连接心跳， 主节点默认每10S 向从节点发ping 命令，repl-ping-slave-period 控制发送频率
3. 主从复制原理
1) 全量同步
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：
- 从服务器连接主服务器，发送SYNC命令；
- 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
- 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
- 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
- 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
- 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
2) 增量同步
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
3) Redis主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
二、哨兵机制
哨兵机制(sentinel)的高可用
- 原理：当主节点出现故障时，由redis sentinel 自动完成故障发现和转移，并通知应用方，实现高可用性。
其实整个过程只需要一个哨兵节点来完成，首先使用Raft 算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知
哨兵有三个定时监控任务完成对各节点的发现和监控：
任务1，每个哨兵节点每10 秒会向主节点和从节点发送info 命令获取最拓扑结构图，哨
兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当
有新的从节点加入时可以马上感知到
任务2，每个哨兵节点每隔2 秒会向redis 数据节点的指定频道上发送该哨兵节点对于主
节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵
节点的信息及对主节点的判断，其实就是通过消息publish 和subscribe 来完成的；
任务3，每隔1 秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping 命令做一次
心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
主观下线： 刚我知道知道哨兵节点每隔1 秒对主节点和从节点、其它哨兵节点发送ping
做心跳检测，当这些心跳检测时间超过down-after-milliseconds 时，哨兵节点则认为该节点
错误或下线，这叫主观下线；这可能会存在错误的判断。
客观下线： 当主观下线的节点是主节点时，此时该哨兵3 节点会通过指令sentinel
is-masterdown-by-addr 寻求其它哨兵节点对主节点的判断，当超过quorum（法定人数）个
数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意
下线操作，也就说是客观下线
领导者哨兵选举流程：
- 每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr 命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
- 当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
- 如果哨兵3 发现自己在选举的票数大于等于num(sentinels)/2+1 时，将成为领导者，如果没有超过，继续选举…………
故障转移机制
-
由Sentinel 节点定期监控发现主节点是否出现了故障sentinel 会向master 发送心跳PING 来确认master 是否存活，如果master 在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel 会主观地(单方面地)认为这个master 已经不可用了
-
当主节点出现故障，此时3 个Sentinel 节点共同选举了Sentinel3 节点为领导，负载处理主节点的故障转移
-
由Sentinel3 领导者节点执行故障转移，过程和主从复制一样，但是自动执行
流程：
1，将slave-1 脱离原从节点，升级主节点，
2，将从节点slave-2 指向新的主节点
3，通知客户端主节点已更换
4，将原主节点（oldMaster）变成从节点，指向新的主节点 -
故障转移后的redis sentinel 的拓扑结构图
-
哨兵机制－故障转移详细流程
A，过滤掉不健康的（下线或断线），没有回复过哨兵ping 响应的从节点
B，选择slave-priority 从节点优先级最高（redis.conf）
C，选择复制偏移量最大，指复制最完整的从节点 -
部署建议：
a，sentinel 节点应部署在多台物理机（线上环境）
b，至少三个且奇数个sentinel 节点
c，通过以上我们知道，3 个sentinel 可同时监控一个主节点或多个主节点
监听N 个主节点较多时，如果sentinel 出现异常，会对多个主节点有影响，同
时还会造成sentinel 节点产生过多的网络连接，
一般线上建议还是， 3 个sentinel 监听一个主节点
三、redis 集群:
1，分布式数据库把整个数据按分区规则映射到多个节点，即把数据划分到多个节点上，每个节点负责整体数据的一个子集
比如我们库有900 条用户数据，有3 个redis 节点，将900 条分成3 份，分别存入到3 个redis 节点
2，分区规则：
常见的分区规则哈希分区和顺序分区，redis 集群使用了哈希分区，顺序分区暂用不到，不做具体说明；
rediscluster 采用了哈希分区的“虚拟槽分区”方式（哈希分区分节点取余、一900 条数据分区规则redis-1 redis-2 redis-3致性哈希分区和虚拟槽分区）。
3，虚拟槽分区(槽：slot)
RedisCluster 采用此分区，所有的键根据哈希函数(CRC16[key]&16383)映射到0－16383 槽内，共16384 个槽位，每个节点维护部分槽及槽所映射的键值数据
哈希函数: Hash()=CRC16[key]&16383
redis 用虚拟槽分区原因：解耦数据与节点关系，节点自身维护槽映射关系，分布式存储
4，redisCluster 的缺陷：
a，键的批量操作支持有限，比如mset, mget，如果多个键映射在不同的槽，就不支持了
b，键事务支持有限，当多个key 分布在不同节点时无法使用事务，同一节点是支持事务
c，键是数据分区的最小粒度，不能将一个很大的键值对映射到不同的节点
d，不支持多数据库，只有0，select 0
e，复制结构只支持单层结构，不支持树型结构。