Redis Cluster Gossip Protocol: MEET

2023-10-04 07:46

本文主要是介绍Redis Cluster Gossip Protocol: MEET,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

返回目录

CLUSTER MEET

过程说明

client Node A Node B cmd: cluster meet B_ip B_port [B_cport] Invalid node address specified: ip:port OK alt [ip or port or cport is invalid] clusterCron message1: MEET message2: PONG handshake completed clusterCron message3: PING message4: PONG handshake completed client Node A Node B

注意:B_ip 不能使用域名

Node A 收到client发送的meet命令后:
  1. 如果 B_cport 不存在,则 B_cport = B_port + 10000
  2. 检查 B_ip, B_port, B_cport 的合法性
  3. 在自己的cluster节点字典中查找是否存在这样的节点
    • 处于handshake状态 &&
    • ip == B_ip &&
    • port == B_port &&
    • cport == B_cport
      如果存在,说明相同的节点已经处于handshake阶段,不需要重复handshake,返回OK给client。
  4. 新建实体B:
    • 生成一个随机节点ID
    • 设置创建时间为当前时间
    • 添加标记: NODE_HANDSHAKE | NODE_MEET
    • 设置传入的 ip, port, cport
  5. 把实体B加入到自己的cluster节点字典
  6. 返回OK给client

clusterCron: 一个专门处理cluster间通信的周期性调度。

消息说明

以下执行步骤只挑选了主要的步骤。

message1:A meet B

Node A 在ClusterCron时:

  1. 检查B是否存在NODE_MEET标记,没有则返回
  2. 判断跟B的handshake是否已经timeout:
    当前时间 - 节点的创建时间 > max(cluster-node-timeout, 1000)
    cluster-node-timeout 是配置项)
  3. 如果timeout了,从cluster节点字典中删除B的信息并返回
  4. 检查是否存在指向Node B的link,如果没有则创建一个(方向为TO)
  5. 连通后发送message1(MEET)给Node B
  6. 从实体B中移除NODE_MEET标记

message2:B pong A

Node B在收到message1后:

  1. 如果没有配置 cluster-announce-ip,则从socket中查找自己的ip
  2. 新建实体A
    • 生成一个随机节点ID
    • 设置创建时间为当前时间
    • 通过socket查找Node A的ip
    • 添加标记: NODE_HANDSHAKE
    • 设置传入的 ip, port, cport
  3. 把实体A加入到cluster节点字典
  4. 处理消息中的gossip部分
  5. 回复message2(PONG)给Node A
  6. 到此,在Node B看来,还没有完成跟Node A的handshake,所以不会直接使用message1中Node A的ID,也不会更新A的slots分布

Node A在收到message2后:

  1. message2中获取Node B的ID,更新实体B。因为之前新建实体B时用的是随机ID,而这次message2中带的才是真正的ID,所以需要更新
  2. 移除实体B中的HANDSHAKE标记
  3. 根据message2中的信息设置实体B为master或者slave
  4. 到此,在A看来,已完成跟B的handshake过程。但此时A还没有获取B中的slots分布。handshake完成后的下一次ping/pong才会更新slots。

message3:B ping A

Node B 在ClusterCron时:

  1. 检查是否存在指向Node A的link,没有则创建一个(方向为TO)
  2. 连通后发送message3(PING)给Node A

Node A在收到message3后:

  1. 更新currentEpoch和configEpoch
  2. 如果没有配置 cluster-announce-ip,则从socket中查找自己的ip
  3. 回复message4(PONG)给Node B
  4. 更新实体B中slots的分布
  5. 处理gossip和extension部分

message4: A pong B

Node B在收到message4后:

  1. message4中获取Node A的ID,更新实体A。因为之前新建实体A时用的是随机ID,而这次message4中带的才是真正的ID,所以需要更新
  2. 移除实体A中的HANDSHAKE标记
  3. 根据message4中的信息设置实体B为master或者slave
  4. 到此,在B看来,已完成跟A的handshake过程。但此时B还没有获取A中的slots分布。handshake完成后的下一次ping/pong才会更新slots。

至此:
5. 当Node A和Node B都完成了handshake过程后,就会进入相互ping/pong/update等的阶段
6. 而Node B可以从Node A的ping/pong中获取到Node A的slots分布,从而更新到实体A
7. 只有handshake成功后的下一次ping/pong才会真正的更新自己cluster节点字典中的实体。

Demo

Node A的日志
# Step 1
# Node A向Node B发送message1(MEET),fe4d****这个ID是实体B随机生成的
3383:M 22 Nov 2022 15:02:45.098 . Connecting with Node fe4d416c13a24d5dc03a6fff25181d3ae15f95ad at 127.0.0.1:17000
# -----------------# Step 3
# Node A收到Node B回复的message2(PONG)
3383:M 22 Nov 2022 15:02:45.099 . --- Processing packet of type pong, 2256 bytes
3383:M 22 Nov 2022 15:02:45.099 . pong packet received: fe4d416c13a24d5dc03a6fff25181d3ae15f95ad
# 根据message2里面Node B的真实ID,更新实体B
3383:M 22 Nov 2022 15:02:45.099 . Renaming node fe4d416c13a24d5dc03a6fff25181d3ae15f95ad into 737418730813700da2f51ddeb8bdc8e3fd2a7805
# 在Node A看来,跟Node B的handshake过程结束
3383:M 22 Nov 2022 15:02:45.099 . Handshake with node 737418730813700da2f51ddeb8bdc8e3fd2a7805 completed.
# -----------------# Step 5
# Node A收到Node B发送来的message3(PING)
3383:M 22 Nov 2022 15:02:45.201 - Accepting cluster node connection from 127.0.0.1:56990
3383:M 22 Nov 2022 15:02:45.201 . --- Processing packet of type ping, 2256 bytes
# Node A 修正自己的IP
3383:M 22 Nov 2022 15:02:45.201 # IP address for this node updated to 127.0.0.1
# Node A根据message3,做一系列操作,包括更新实体B中的slots
3383:M 22 Nov 2022 15:02:45.201 . ping packet received: 737418730813700da2f51ddeb8bdc8e3fd2a7805
# Node A回复message4给Node B(日志没显示)
# -----------------# Step 8
# Node A再次收到Node B发送来的PING
3383:M 22 Nov 2022 15:02:45.303 . --- Processing packet of type ping, 2256 bytes
3383:M 22 Nov 2022 15:02:45.303 . ping packet received: 737418730813700da2f51ddeb8bdc8e3fd2a7805
# Node A回复PONG给Node B(日志没显示)
# -----------------
Node B的日志
# Step 2
# Node B收到NodeA发送来的message1
3372:M 22 Nov 2022 15:02:45.099 - Accepting cluster node connection from 127.0.0.1:44968
3372:M 22 Nov 2022 15:02:45.099 . --- Processing packet of type meet, 2256 bytes
# Node B修正自己的IP
3372:M 22 Nov 2022 15:02:45.099 # IP address for this node updated to 127.0.0.1
# 因为message1中Node A的ID在Node B的cluster节点字典中不存在对应的实体,所以received打印的是NULL
3372:M 22 Nov 2022 15:02:45.099 . meet packet received: NULL
# Node B回复message2给Node A(日志没显示)
# -----------------# Step 4
# Node B在clusterCron时向NodeA发送message3(PING)
3372:M 22 Nov 2022 15:02:45.201 . Connecting with Node ba747dfdcd40d974294054f1d7ca023678ff9874 at 127.0.0.1:16000
# -----------------# Step 6
# Node B收到Node A回复的message4(PONG)
3372:M 22 Nov 2022 15:02:45.204 . --- Processing packet of type pong, 2256 bytes
3372:M 22 Nov 2022 15:02:45.204 . pong packet received: ba747dfdcd40d974294054f1d7ca023678ff9874
# Node B根据message4中Node A的真实ID,更新实体A
3372:M 22 Nov 2022 15:02:45.204 . Renaming node ba747dfdcd40d974294054f1d7ca023678ff9874 into ea017e0f83612b1b32179b4277becba349db5590
# 在Node B看来,跟Node A的handshake过程结束
3372:M 22 Nov 2022 15:02:45.204 . Handshake with node ea017e0f83612b1b32179b4277becba349db5590 completed.
# -----------------# Step 7
# Node B在clusterCron时再次向Node A发送PING消息
3372:M 22 Nov 2022 15:02:45.303 . Pinging node ea017e0f83612b1b32179b4277becba349db5590
# -----------------# Step 9
# Node B收到Node A回复的PONG
3372:M 22 Nov 2022 15:02:45.303 . --- Processing packet of type pong, 2256 bytes
# Node B根据PONG,做一系列操作,包括更新实体A中的slots
3372:M 22 Nov 2022 15:02:45.303 . pong packet received: ea017e0f83612b1b32179b4277becba349db5590

这篇关于Redis Cluster Gossip Protocol: MEET的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1607

相关文章

shell脚本批量导出redis key-value方式

《shell脚本批量导出rediskey-value方式》为避免keys全量扫描导致Redis卡顿,可先通过dump.rdb备份文件在本地恢复,再使用scan命令渐进导出key-value,通过CN... 目录1 背景2 详细步骤2.1 本地docker启动Redis2.2 shell批量导出脚本3 附录总

批量导入txt数据到的redis过程

《批量导入txt数据到的redis过程》用户通过将Redis命令逐行写入txt文件,利用管道模式运行客户端,成功执行批量删除以Product*匹配的Key操作,提高了数据清理效率... 目录批量导入txt数据到Redisjs把redis命令按一条 一行写到txt中管道命令运行redis客户端成功了批量删除k

Redis客户端连接机制的实现方案

《Redis客户端连接机制的实现方案》本文主要介绍了Redis客户端连接机制的实现方案,包括事件驱动模型、非阻塞I/O处理、连接池应用及配置优化,具有一定的参考价值,感兴趣的可以了解一下... 目录1. Redis连接模型概述2. 连接建立过程详解2.1 连php接初始化流程2.2 关键配置参数3. 最大连

Redis MCP 安装与配置指南

《RedisMCP安装与配置指南》本文将详细介绍如何安装和配置RedisMCP,包括快速启动、源码安装、Docker安装、以及相关的配置参数和环境变量设置,感兴趣的朋友一起看看吧... 目录一、Redis MCP 简介二、安www.chinasem.cn装 Redis MCP 服务2.1 快速启动(推荐)2.

Redis中Stream详解及应用小结

《Redis中Stream详解及应用小结》RedisStreams是Redis5.0引入的新功能,提供了一种类似于传统消息队列的机制,但具有更高的灵活性和可扩展性,本文给大家介绍Redis中Strea... 目录1. Redis Stream 概述2. Redis Stream 的基本操作2.1. XADD

Knife4j+Axios+Redis前后端分离架构下的 API 管理与会话方案(最新推荐)

《Knife4j+Axios+Redis前后端分离架构下的API管理与会话方案(最新推荐)》本文主要介绍了Swagger与Knife4j的配置要点、前后端对接方法以及分布式Session实现原理,... 目录一、Swagger 与 Knife4j 的深度理解及配置要点Knife4j 配置关键要点1.Spri

Redis出现中文乱码的问题及解决

《Redis出现中文乱码的问题及解决》:本文主要介绍Redis出现中文乱码的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1. 问题的产生2China编程. 问题的解决redihttp://www.chinasem.cns数据进制问题的解决中文乱码问题解决总结

Redis的持久化之RDB和AOF机制详解

《Redis的持久化之RDB和AOF机制详解》:本文主要介绍Redis的持久化之RDB和AOF机制,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录概述RDB(Redis Database)核心原理触发方式手动触发自动触发AOF(Append-Only File)核

Redis分片集群、数据读写规则问题小结

《Redis分片集群、数据读写规则问题小结》本文介绍了Redis分片集群的原理,通过数据分片和哈希槽机制解决单机内存限制与写瓶颈问题,实现分布式存储和高并发处理,但存在通信开销大、维护复杂及对事务支持... 目录一、分片集群解android决的问题二、分片集群图解 分片集群特征如何解决的上述问题?(与哨兵模

SpringBoot连接Redis集群教程

《SpringBoot连接Redis集群教程》:本文主要介绍SpringBoot连接Redis集群教程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1. 依赖2. 修改配置文件3. 创建RedisClusterConfig4. 测试总结1. 依赖 <de