redis集群核心原理:gossip通信、jedis Smart定位、主备切换

1、节点间的内部通信机制

1.1 基础通信原理

• redis cluster节点间采取gossip协议进行通信 
  维护集群的元数据有两种方式：集中式和gossip 
  集中式： 
  优点在于元数据的更新和读取，时效性非常好，一旦元数据出现变更立即就会更新到集中式的存储中，其他节点读取的时候立即就可以立即感知到； 
  不足在于所有的元数据的更新压力全部集中在一个地方，可能导致元数据的存储压力。 
  gossip： 
  优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力； 
  缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。
• 10000端口 
  每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口。 
  每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong。

• 1.2 gossip协议

  gossip协议包含多种消息，包括ping，pong，meet，fail等等。 
  meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信，不需要发送形成网络的所需的所有CLUSTER MEET命令。发送CLUSTER MEET消息以便每个节点能够达到其他每个节点只需通过一条已知的节点链就够了。由于在心跳包中会交换gossip信息，将会创建节点间缺失的链接。
  ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据； 
  pong: 返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新； 
  fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

  2、面向集群的jedis内部实现原理

  2.1 基于重定向的客户端

  • 请求重定向 
    客户端会挑选任意一个redis实例去发送命令，每个redis实例接收到命令，都会计算key对应的hash slot；

  #查看key对应的hash slot
  cluster keyslot key
  
  #连接客户端时加-c参数可以自动重定向
  redis-cli -c

  • 1
  • 2
  • 3
  • 4
  • 5
  • 计算hash slot 
    计算hash slot的算法，就是根据key计算CRC16值，然后对16384取模，拿到对应的hash slot； 
    用hash tag可以手动指定key对应的slot，同一个hash tag下的key，都会在一个hash slot中，比如set mykey1:{100}和set mykey2:{100}；
  • hash slot查找 
    节点间通过gossip协议进行数据交换，就知道每个hash slot在哪个节点上；

  2.2 smart jedis

  (1) 什么是smart jedis？ 
  基于重定向的客户端，很消耗网络io，因为大部分情况下，可能都会出现一次请求重定向，才能找到正确的节点； 
  所以大部分的客户端比如java redis客户端，都是jedis，都是smart的， 
  本地维护一份hashslot -> node的映射表在缓存里，大部分情况下直接走本地缓存就可以找到hashslot -> node，不需要通过节点进行moved重定向；

  3. 高可用性与主备切换原理

  3.1 判断节点宕机

  如果一个节点认为另外一个节点宕机，name就是pfail，主观宕机； 
  如果多个节点都认为另外一个节点宕机了，那么就是fail，客观宕机，跟哨兵的原理几乎一样，sdown，odown； 
  在cluster-node-timeout内，某个节点一直没有返回pong，那么就被认为pfail； 
  如果一个节点认为某个节点pfail了，那么会在gossip ping消息中，ping给其他节点，如果超过半数的节点都认为pfail了，那么就会变成fail；

  3.2 从节点过滤

  对宕机的master node，从其所有的slave node中，选择一个切换成master node； 
  检查每个slave node与master node断开连接的时间，如果超过了cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成master；

  3.3 从节点选举

  哨兵：对所有从节点进行排序，slave priority，offset，run id； 
  每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举； 
  所有的master node开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master； 
  从节点执行主备切换，从节点切换为主节点；

  3.4 与哨兵比较

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

  转载自：https://blog.csdn.net/r_p_j/article/details/78813265