redis-5，redis哨兵，集群

redis哨兵

哨兵巡查监控后台master主机是否故障，如果故障了，根据投票数自动将某一个库转换为新主库，继续对外提供服务

主要作用

主从监控： 监控主从redis库是否运行正常
消息通知： 哨兵可以将故障转移的结果发送给客户端
故障转移： 如果master异常，可以进行主从切换
配置中心： 客户端通过连接哨兵来获得当前reids的主节点地址

redis架构说明

三哨兵，一主二从
哨兵只负责监控和维护集群，不存入数据

哨兵的配置文件和数据库是不一样的

配置文件参数说明

sentinel monitor <master-name> <ip> <redis-port> <quorum>
设置要监控的master服务器
quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数

哨兵运行的时候会在配置文件写入数据
配置文件最好一个实例一个文件

宕机的节点重连之后会成为slave节点

两个小问题
主节点断开之后从节点可能会出现
sever closed the connection

broken pipe
broken pipe通常是对端的管道断开，无法再对这个管道进行读写操作
该异常产生的时候对服务端没有多大影响

哨兵运行原理和选举原理

三哨兵监控一主二从

主观下线sdown：

单个sentinel检测到关于master的状态，从sentinel角度来看，如果发送了ping心跳后，在一定时间内没有收到回复，就达到了sdown条件
sentine配置文件中的down-after-milliseconds设置了判断主观下线的时长
默认30s

客观下线odown：

多个哨兵达成一致的意见就认为下线了

选举出领导者哨兵leader：

三个哨兵中选一个来执行slave到master
日志中可以看到选举过程

raft算法选举出来的领导者

自动故障切换并选出新master

选举算法：
priority权限：
谁高谁变成新master
redis.config文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先级越高）
replication offset偏移量：
谁的偏移量大谁变成新master
run id：
最小run id的从节点 字典顺序：ascii码

redis集群redis cluster

集群个数

集群的秘钥空间被分成16384个槽，有效的设置了16384个主节点

分片

使用reids集群时，将存储的数据分散到多个redis机器上，这成为分片，集群中的每个redis实例，都被认为是整个数据的一个分片

如何找到给定key的分片

为了找到给定key的分片，对key进行crc16算法处理并通过对总分片数量取模，然后使用确定性哈希函数，这说明给定的给将多次始终映射到同一个分片，我们可以推断将来读取特定key的位置

分片扩容和缩容

分片方便扩容和缩容
如果想添加一个节点d，需要从哪个节点abc中得部分槽到d上，如果想移除节点a，需要将节点a的槽移动到b和c中，然后将没有任何槽的a节点移除，无论添加还是删除节点都不会造成不可用状态

slot槽位映射三种解决方案

哈希取余分区

如果存储两亿条数据，假设三台机器构成一个集群，用户每次读写都是根据公式
hash(key)%n个机器台数，计算出哈希值，用来决定映射到哪个表上
缺点：
扩容缩容较麻烦，%n的数字是固定的，导致如果增加或者一台宕机之后，读取都会出问题

一致性哈希算法分区

主要解决：当服务器发生变动的时候，尽量减少影响客户端到服务器的映射关系
三大步骤：
算法构建一致性哈希环
服务器节点ip映射
key落到服务器的落键规则

构建一致性哈希环
一致性哈希算法必定有个哈希函数，并按照一定的算法产生哈希值，这个算法的所有可能哈希值会构成一个全量集，这个哈希空间零到二的三十二次方减一，这是一个线性空间，但是我们可以将它首尾相连，在逻辑上形成闭环空间

ip映射和落键规则
四台ip地址落到哈希环上
当我们需要存储一个kv值的时候，首先计算key的hash值，将这个key使用相同的哈希函数映射到环上，之后从此位置沿顺时针方向行走，遇到的第一个服务器就是定位到的服务器。

如果一台服务器不管用，影响的仅仅是这一台服务器逆时针之前的服务器
增加服务器的时候也是只影响这一段数据

缺点：数据倾斜问题，容易头重脚轻，节点分布不均匀会倾斜。

哈希槽分区

哈希槽实质是一个数组
0-2^14-1
用于解决均匀分配问题，在数据和节点之间加入一个槽，用于管理节点和数据之间的关系，相当于节点上放的是槽，槽里放的是数据

槽解决的是粒度问题，相当于把粒度变大，哈希解决的是映射问题。使用key的哈希值来计算所在的槽，便于数据分配。
相当于在前面加了一层

为什么槽数是16384个
2的14次方。
正常的心跳数据包可以携带节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置，这意味着他们包含原始节点的插槽配置，该节点用2k的空间和16k的插槽，但是会使用8k的空间。由于其他设计约束，集群不太可能超过1000个节点。因此16k可以确保主机具有足够的插槽。最多可容纳1000个矩阵。但数量足够少，可以轻松的将插槽位置作为原始的位图传播。
在小型集群中，位图很难压缩，当n较小时，slot/N位占位置位的很大百分比
节点超过一千，发送心跳包的时候会导致网络拥堵。

redis集群不保证强一致性。

三主三从redis集群环境搭配

对于集群需要路由到位
进入redis服务的时候需要加参数-c

集群容错切换

cluster nodes命令查看节点拓扑信息
一个主节点宕机之后，对应的slave会升级成master
原来的主机回来之后不会重新是master会变成slave

当原主机宕机之后，如果这时候存入信息，因为redis在执行从机上位，所以可能会发生数据丢失

节点从属调整

扶正原来的主节点
cluster failover 命令

扩容

新建6387,6388两个服务实例配置文件。
启动87,88两个新的节点实例，此时是独立的master
将87节点作为master加入新集群：
redis-cli -a password --cluster add-node ip:6387 ip:6381
6381作为是集群中原有的节点，新加入的节点通过原有的6381节点加入集群