将key进行hash_tag的包装,然后把tag用大括号括起来,保证所有的key只向一个node请求数据,这样执行类似mget命令只需要去一个节点获取数据即可,效率更高
3.6.5 四种优化方案优缺点分析 3.7 故障发现Redis Cluster通过ping/pong消息实现故障发现:不需要sentinel
ping/pong不仅能传递节点与槽的对应消息,也能传递其他状态,比如:节点主从状态,节点故障等
故障发现就是通过这种模式来实现,分为主观下线和客观下线
3.7.1 主观下线某个节点认为另一个节点不可用,'偏见',只代表一个节点对另一个节点的判断,不代表所有节点的认知
主观下线流程:
1.节点1定期发送ping消息给节点2 2.如果发送成功,代表节点2正常运行,节点2会响应PONG消息给节点1,节点1更新与节点2的最后通信时间 3.如果发送失败,则节点1与节点2之间的通信异常判断连接,在下一个定时任务周期时,仍然会与节点2发送ping消息 4.如果节点1发现与节点2最后通信时间超过node-timeout,则把节点2标识为pfail状态 3.7.2 客观下线当半数以上持有槽的主节点都标记某节点主观下线时,可以保证判断的公平性
集群模式下,只有主节点(master)才有读写权限和集群槽的维护权限,从节点(slave)只有复制的权限
客观下线流程:
1.某个节点接收到其他节点发送的ping消息,如果接收到的ping消息中包含了其他pfail节点,这个节点会将主观下线的消息内容添加到自身的故障列表中,故障列表中包含了当前节点接收到的每一个节点对其他节点的状态信息 2.当前节点把主观下线的消息内容添加到自身的故障列表之后,会尝试对故障节点进行客观下线操作故障列表的周期为:集群的node-timeout * 2,保证以前的故障消息不会对周期内的故障消息造成影响,保证客观下线的公平性和有效性
3.8 故障恢复 3.8.1 资格检查 对从节点的资格进行检查,只有难过检查的从节点才可以开始进行故障恢复 每个从节点检查与故障主节点的断线时间 超过cluster-node-timeout * cluster-slave-validity-factor数字,则取消资格 cluster-node-timeout默认为15秒,cluster-slave-validity-factor默认值为10 如果这两个参数都使用默认值,则每个节点都检查与故障主节点的断线时间,如果超过150秒,则这个节点就没有成为替换主节点的可能性 3.9.2 准备选举时间 使偏移量最大的从节点具备优先级成为主节点的条件 3.8.3 选举投票 对选举出来的多个从节点进行投票,选出新的主节点 3.8.4 替换主节点 当前从节点取消复制变成离节点(slaveof no one) 执行cluster del slot撤销故障主节点负责的槽,并执行cluster add slot把这些槽分配给自己 向集群广播自己的pong消息,表明已经替换了故障从节点 3.8.5 故障转移演练 对某一个主节点执行kill -9 {pid}来模拟宕机的情况 3.9 Redis Cluster的缺点 当节点数量很多时,性能不会很高 解决方式:使用智能客户端。智能客户端知道由哪个节点负责管理哪个槽,而且当节点与槽的映射关系发生改变时,客户端也会知道这个改变,这是一种非常高效的方式 4.搭建Redis Cluster搭建Redis Cluster有两种安装方式
1.原生命令安装
2.官方工具安装
5.开发运维常见的问题 5.1 集群完整性cluster-require-full-coverage默认为yes,即是否集群中的所有节点都是在线状态且16384个槽都处于服务状态时,集群才会提供服务
集群中16384个槽全部处于服务状态,保证集群完整性
当某个节点故障或者正在故障转移时获取数据会提示:(error)CLUSTERDOWN The cluster is down
建议把cluster-require-full-coverage设置为no
5.2 带宽消耗Redis Cluster节点之间会定期交换Gossip消息,以及做一些心跳检测
官方建议Redis Cluster节点数量不要超过1000个,当集群中节点数量过多时,会产生不容忽视的带宽消耗
消息发送频率:节点发现与其他节点最后通信时间超过cluster-node-timeout /2时,会直接发送PING消息
消息数据量:slots槽数组(2kb空间)和整个集群1/10的状态数据(10个节点状态数据约为1kb)
节点部署的机器规模:集群分布的机器越多且每台机器划分的节点数越均匀,则集群内整体的可用带宽越高