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

相关文章

Redis分片集群的实现

《Redis分片集群的实现》Redis分片集群是一种将Redis数据库分散到多个节点上的方式,以提供更高的性能和可伸缩性,本文主要介绍了Redis分片集群的实现,具有一定的参考价值,感兴趣的可以了解一... 目录1. Redis Cluster的核心概念哈希槽(Hash Slots)主从复制与故障转移2.

Redis 中的热点键和数据倾斜示例详解

《Redis中的热点键和数据倾斜示例详解》热点键是指在Redis中被频繁访问的特定键,这些键由于其高访问频率,可能导致Redis服务器的性能问题,尤其是在高并发场景下,本文给大家介绍Redis中的热... 目录Redis 中的热点键和数据倾斜热点键(Hot Key)定义特点应对策略示例数据倾斜(Data S

redis+lua实现分布式限流的示例

《redis+lua实现分布式限流的示例》本文主要介绍了redis+lua实现分布式限流的示例,可以实现复杂的限流逻辑,如滑动窗口限流,并且避免了多步操作导致的并发问题,具有一定的参考价值,感兴趣的可... 目录为什么使用Redis+Lua实现分布式限流使用ZSET也可以实现限流,为什么选择lua的方式实现

Redis中管道操作pipeline的实现

《Redis中管道操作pipeline的实现》RedisPipeline是一种优化客户端与服务器通信的技术,通过批量发送和接收命令减少网络往返次数,提高命令执行效率,本文就来介绍一下Redis中管道操... 目录什么是pipeline场景一:我要向Redis新增大批量的数据分批处理事务( MULTI/EXE

Redis中高并发读写性能的深度解析与优化

《Redis中高并发读写性能的深度解析与优化》Redis作为一款高性能的内存数据库,广泛应用于缓存、消息队列、实时统计等场景,本文将深入探讨Redis的读写并发能力,感兴趣的小伙伴可以了解下... 目录引言一、Redis 并发能力概述1.1 Redis 的读写性能1.2 影响 Redis 并发能力的因素二、

Redis中的常用的五种数据类型详解

《Redis中的常用的五种数据类型详解》:本文主要介绍Redis中的常用的五种数据类型详解,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Redis常用的五种数据类型一、字符串(String)简介常用命令应用场景二、哈希(Hash)简介常用命令应用场景三、列表(L

Redis解决缓存击穿问题的两种方法

《Redis解决缓存击穿问题的两种方法》缓存击穿问题也叫热点Key问题,就是⼀个被高并发访问并且缓存重建业务较复杂的key突然失效了,无数的请求访问会在瞬间给数据库带来巨大的冲击,本文给大家介绍了Re... 目录引言解决办法互斥锁(强一致,性能差)逻辑过期(高可用,性能优)设计逻辑过期时间引言缓存击穿:给

Redis中如何实现商品秒杀

《Redis中如何实现商品秒杀》:本文主要介绍Redis中如何实现商品秒杀问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录技术栈功能实现步骤步骤一:准备商品库存数据步骤二:实现商品秒杀步骤三:优化Redis性能技术讲解Redis的List类型Redis的Set

Redis如何实现刷票过滤

《Redis如何实现刷票过滤》:本文主要介绍Redis如何实现刷票过滤问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录引言一、概述二、技术选型三、搭建开发环境四、使用Redis存储数据四、使用SpringBoot开发应用五、 实现同一IP每天刷票不得超过次数六

Redis客户端工具之RedisInsight的下载方式

《Redis客户端工具之RedisInsight的下载方式》RedisInsight是Redis官方提供的图形化客户端工具,下载步骤包括访问Redis官网、选择RedisInsight、下载链接、注册... 目录Redis客户端工具RedisInsight的下载一、点击进入Redis官网二、点击RedisI