zoukankan      html  css  js  c++  java
  • redis cluster

    redis cluster,主要是针对海量数据+高并发+高可用的场景。redis cluster 支撑 N 个 redis master node,每个 master node 都可以挂载多个 slave node。这样整个 redis 就可以横向扩容了。如果你要支撑更大数据量的缓存,那就横向扩容更多的 master 节点,每个 master 节点就能存放更多的数据了。

    redis cluster的特点

    • 自动将数据进行分片,每个 master 上放一部分数据
    • 提供内置的高可用支持,部分 master 不可用时,还是可以继续工作的

    在 redis cluster 架构下,每个 redis 要放开两个端口号,比如一个是 6379,另外一个就是 加1w 的端口号,比如 16379。

    16379 端口号是用来进行节点间通信的,也就是 cluster bus 的东西,cluster bus 的通信,用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议,gossip?协议,用于节点间进行高效的数据交换,占用更少的网络带宽和处理时间。

    节点间的内部通信机制

    基本通信原理

    redis cluster 节点间采用 gossip 协议进行通信 。集中式将集群元数据(节点信息、故障等等)集中存储在某个节点上。集中式元数据集中存储的一个典型代表,就是大数据领域的storm。它是分布式的大数据实时计算引擎,是集中式的元数据存储的结构,底层基于 zookeeper(分布式协调的中间件)对所有元数据进行存储维护。

    01

    redis 维护集群元数据采用另一个方式,gossip协议,所有节点都持有一份元数据,不同的节点如果出现了元数据的变更,就不断将元数据发送给其它的节点,让其它节点也进行元数据的变更。

    02

    集中式的好处在于,元数据的读取和更新,时效性非常好,一旦元数据出现了变更,就立即更新到集中式的存储中,其它节点读取的时候就可以感知到;不好在于,所有的元数据的更新压力全部集中在一个地方,可能会导致元数据的存储有压力。

    gossip 好处在于,元数据的更新比较分散,不是集中在一个地方,更新请求会陆陆续续,打到所有节点上去更新,降低了压力;不好在于,元数据的更新有延时,可能导致集群中的一些操作会有一些滞后。

    10000 端口

    每个节点都有一个专门用于节点间通信的端口,就是自己提供服务的端口号+10000,比如 7001,那么用于节点间通信的就是 17001 端口。

    每个节点每隔一段时间都会往另外几个节点发送ping消息,同时其它几个节点接收到ping之后返回pong。

    交换的信息

    信息包括故障信息,节点的增加和删除,hash slot 信息 等等。

    gossip 协议

    gossip 协议包含多种消息,包含ping,pong,meet,fail等等。

    • meet:某个节点发送 meet 给新加入的节点,让新节点加入集群中,然后新节点就会开始与其它节点进行通信。redis-trib.rb add-node其实内部就是发送了一个 gossip meet 消息给新加入的节点,通知那个节点去加入我们的集群。
    • ping:每个节点都会频繁给其它节点发送 ping,其中包含自己的状态还有自己维护的集群元数据,互相通过 ping 交换元数据。
    • pong:返回 ping 和 meeet,包含自己的状态和其它信息,也用于信息广播和更新。
    • fail:某个节点判断另一个节点 fail 之后,就发送 fail 给其它节点,通知其它节点说,某个节点宕机啦。

    ping 消息深入

    ping 时要携带一些元数据,如果很频繁,可能会加重网络负担。

    每个节点每秒会执行 10 次 ping,每次会选择 5 个最久没有通信的其它节点。当然如果发现某个节点通信延时达到了cluster_node_timeout / 2,那么立即发送 ping,避免数据交换延时过长,落后的时间太长了。比如说,两个节点之间都 10 分钟没有交换数据了,那么整个集群处于严重的元数据不一致的情况,就会有问题。所以cluster_node_timeout可以调节,如果调得比较大,那么会降低 ping 的频率。

    每次 ping,会带上自己节点的信息,还有就是带上 1/10 其它节点的信息,发送出去,进行交换。至少包含3个其它节点的信息,最多包含总结点-2个其它节点的信息。

    redis cluster 的高可用与主备切换原理

    redis cluster 的高可用的原理,几乎跟哨兵是类似的

    判断节点宕机

    如果一个节点认为另外一个节点宕机,那么就是pfail,主观宕机。如果多个节点都认为另外一个节点宕机了,那么就是fail,客观宕机,跟哨兵的原理几乎一样,sdown,odown。

    在cluster-node-timeout内,某个节点一直没有返回pong,那么就被认为pfail。

    如果一个节点认为某个节点pfail了,那么会在gossip ping消息中,ping给其他节点,如果超过半数的节点都认为pfail了,那么就会变成fail。

    从节点过滤

    对宕机的 master node,从其所有的 slave node 中,选择一个切换成 master node。

    检查每个 slave node 与 master node 断开连接的时间,如果超过了cluster-node-timeout * cluster-slave-validity-factor,那么就没有资格切换成master。

    从节点选举

    每个从节点,都根据自己对 master 复制数据的 offset,来设置一个选举时间,offset 越大(复制数据越多)的从节点,选举时间越靠前,优先进行选举。

    所有的 master node 开始 slave 选举投票,给要进行选举的 slave 进行投票,如果大部分 master node(N/2 + 1)都投票给了某个从节点,那么选举通过,那个从节点可以切换成 master。

    从节点执行主备切换,从节点切换为主节点。

    与哨兵比较

    整个流程跟哨兵相比,非常类似,所以说,redis cluster 功能强大,直接集成了 replication 和 sentinel 的功能。

    #######################

  • 相关阅读:
    eclipse中误删tomcat后,文件都报错,恢复server时无法选择tomcat7.0解决办法
    java web多组件协作实现用户登录验证
    设计模式--享元模式
    设计模式--中介者模式
    设计模式--职责链模式
    设计模式--观察者模式与命令模式
    设计模式--桥接模式
    设计模式--迭代器模式
    设计模式--组合模式
    设计模式--备忘录模式
  • 原文地址:https://www.cnblogs.com/amunote/p/10480509.html
Copyright © 2011-2022 走看看