Redis分布式存储方案

一、Redis分布式存储方案

1、哈希取余分区

①、原理

  1. 哈希计算：首先，对每个键（key）进行哈希计算，得到一个整数哈希值（hash value）。
  2. 取余操作：将这个哈希值对服务器数量进行取余操作（modulus operation），得到一个余数。
  3. 分配服务器：这个余数就是服务器的索引，这样就可以确定这个键应该存储到哪一台服务器上。
  4. 公式：server_index=hash(key)%number_of_servers

②、示例

假设我们有 3 台 Redis 服务器，编号分别为 0、1 和 2。我们要存储以下键值对：

"user:1000"
"user:1001"
"user:1002"

假设我们使用简单的哈希函数（如 Python 中的 hash() 函数）来计算哈希值。

  1. 对 “user:1000” 进行哈希计算，假设哈希值为 2301。取余操作：2301 % 3 = 2，因此 “user:1000” 存储到服务器 2。
  2. 对 “user:1001” 进行哈希计算，假设哈希值为 5290。取余操作：5290 % 3 = 1，因此 “user:1001” 存储到服务器 1。
  3. 对 “user:1002” 进行哈希计算，假设哈希值为 7923。取余操作：7923 % 3 = 0，因此 “user:1002” 存储到服务器 0。

在这里插入图片描述

③、优点

简单粗暴，直接有效，只需要预估好数据规划好节点，例如3台、8台、10台，就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求(并维护这些请求的信息)，起到负载均衡+分雨治之的作用。

实现简单：哈希取余算法非常简单易实现，不需要复杂的配置和维护。
快速定位：可以快速计算出数据应该存储在哪台服务器上。

④、缺点

原来规划好的节点，进行扩容或者缩容就比较麻烦了，不管扩缩，每次数据变动导致节点有变动，映射关系需要重新进行计算，在服务器个数固定不变时没有问题，如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化:Hash(key)3会变成Hash(key)/?。此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。

扩展性差：增加或删除服务器时，几乎所有的数据都需要重新分布。这是因为哈希取余算法高度依赖服务器数量的固定值。
数据倾斜：如果哈希函数不好，可能会导致部分服务器负载过重，而其他服务器几乎没有负载（数据分布不均）。

2、一致性哈希算法分区

①、原理

一致性哈希算法在1997年由麻省理工学院中提出的，设计目标是为了解决分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数不OK了。一致性哈希算法得目的就是为了解决当服务器数量发生变动时，减少影响客户端与服务器的映射关系

一致性哈希将所有的键和值以及服务器映射到一个虚拟的哈希环上。哈希环的基本原理如下：

  1. 哈希环：将哈希值空间组织成一个环形结构（通常是 0 到 2^32-1 的范围是一个线性空间，但是经过算法控制使0=2^32让他形成一个环形空间）。
  2. 节点哈希：对每个服务器节点进行哈希运算，并将其映射到环上的某一点。
  3. 数据哈希：对每个键进行哈希运算，并将其映射到环上的某一点。
  4. 顺时针查找：从数据的哈希值开始，顺时针查找第一个节点，这个节点就是数据应存储的位置。

在这里插入图片描述

②、示例

节点映射

将集群中各个IP节点映射到环上的某一个位置。将各个服务器使用Hash进行一个哈希值计算，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置。

假如4个节点NodeA、B、C、D，经过IP地址的哈希函数计算(hash(ip))，使用IP地址哈希后在环空间的位置如下：

在这里插入图片描述

key落到哈希环的规则

当我们需要存储一个kv键值对时，首先计算key的hash值，hash(key)，将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上。

如我们有ObiectA、ObiectB、Obiectc、ObiectD四个数据对象，经过哈希计算后，在环空间上的位置如下;根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到NodeC上，D被定为到Node D上。

在这里插入图片描述

③、优点

容错性：节点故障时的自愈能力

假设Node C宕机，可以看到此时对象A、B、D不受到影响，只有C对象被重定位到NodeD。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器(即沿着逆时针方向行走遇到的第一台服务器)之间数据，其它不会受到影响。简单说，就是C挂了，受到影响的只是B、C之间的数据，并且这些数据会转移到D进行存储。

在这里插入图片描述

扩展性：平滑扩展

数据量增加了，需要增加一台节点NodeX的位置在A和B之间，那收到影响的也就是A到X之间的数据，重新把A到X的数据录入到X上即可，不会导致hash取余全部数据重新洗牌。

在这里插入图片描述

④、缺点

数据倾斜

一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜(被缓存的对象大部分集中缓存在某一台服务器上)问题。

例如系统中只有两台服务器:

在这里插入图片描述

3、哈希槽分区（大企业）

①、原理

  1. 哈希槽：Redis Cluster 将所有可能的键空间分成 16384 个哈希槽。每个键通过哈希函数映射到一个槽，槽的范围是 0 到 16383。哈希槽实质就是一个数组，数组[0,2^14 -1]形成hash slot空间。
  2. 节点：Redis 集群中的每个节点负责管理部分哈希槽。节点数量可以动态增加或减少，槽的分配也可以重新分配。
  3. 哈希函数：Redis 使用 CRC16 哈希函数计算键的哈希值，然后对 16384 取模，得到对应的哈希槽编号：slot=CRC16(key)%16384

哈希槽的出现是为了解决一致性哈希的数据倾斜问题。解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽(slot)，用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据。

在这里插入图片描述

槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。
哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配

一个集群只能有16384个槽，编号0-16383(0-2^14-1) 。这些槽会分配给集群中的所有主节点，分配策略没有要求。可以指定哪些编号的槽分配给那个主节点。集群会记录节点和槽的对应关系。

解决了节点和槽的关系后，接下来就需要对kev求哈希值，然后对16384取余，余数是几key就落入对立的槽里。slot=CRC16(key)%16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

②、示例

redis集群中内置了 16384个哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。当需要在 Redis 集群中放置一个 key-value时，redis 先对 key使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个key 都会对应一个编号在 0-16383之间的哈希槽，也就是映射到某个节点上。如下代码，key之A、B在Node2，key之C落在Node3上

在这里插入图片描述

二、3主3从redis集群配置（哈希槽分区）

1、关闭防火墙和启动Docker服务（Ubuntu）

systemctl stop ufw
systemctl start docker

在这里插入图片描述

2、新建6个docker容器实例

docker run -d --name redis-node-1 --net host --privileged=true -v /data/redis/share/redis-node-1:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6381

docker run -d --name redis-node-2 --net host --privileged=true -v /data/redis/share/redis-node-2:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6382

docker run -d --name redis-node-3 --net host --privileged=true -v /data/redis/share/redis-node-3:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6383

docker run -d --name redis-node-4 --net host --privileged=true -v /data/redis/share/redis-node-4:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6384

docker run -d --name redis-node-5 --net host --privileged=true -v /data/redis/share/redis-node-5:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6385

docker run -d --name redis-node-6 --net host --privileged=true -v /data/redis/share/redis-node-6:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6386

在这里插入图片描述

启动了一个名为 redis-node-1 的 Redis 容器，启用了集群模式和 AOF 持久化，并通过 6381 端口对外提供服务，同时将主机的 /data/redis/share/redis-node-1 目录挂载为容器内的 /data 目录。

docker run -d：以守护进程模式（后台运行）启动一个新的容器。

--name redis-node-1：给容器指定一个名字为 redis-node-1。这样你可以通过名字而不是容器 ID 来管理和访问这个容器。

--net host：让容器使用主机的网络堆栈。这样，容器将直接使用主机的 IP 地址和端口。需要注意的是，这可能会带来一些安全问题，因为容器将完全暴露在主机网络上。

--privileged=true：以特权模式运行容器。这样容器将拥有更高的权限，类似于主机上的 root 权限。这在某些需要高权限操作的应用中是必要的，但同样也增加了安全风险。

-v /data/redis/share/redis-node-1:/data：将主机的 /data/redis/share/redis-node-1 目录挂载到容器内的 /data 目录。这样，容器中的 Redis 可以使用主机上的存储来保存数据。

redis:6.0.8：使用 Redis 版本 6.0.8 的镜像来创建容器。

--cluster-enabled yes：启用 Redis 集群模式。这是 Redis 集群配置的一部分，用于实现数据分片和高可用性。

--appendonly yes：启用 AOF（Append Only File）持久化方式。这会将每一个写操作记录到日志文件中，以确保数据的持久性。

--port 6381：将 Redis 服务绑定到端口 6381。由于使用了 --net host，这个端口将直接绑定到主机的端口 6381。

查看容器是否运行

docker ps -a

在这里插入图片描述

3、创建集群关系

①、进入容器

随便进入一台redis容器

docker exec -it redis-node-1 bash

在这里插入图片描述

②、构建主从关系

构建主从关系（主动对应关系为随机，不固定）

redis-cli --cluster create 192.168.2.159:6381 192.168.2.159:6382 192.168.2.159:6383 192.168.2.159:6384 192.168.2.159:6385 192.168.2.159:6386 --cluster-replicas 1

redis-cli：Redis 命令行工具，用于与 Redis 服务器进行交互。

--cluster create：这是 redis-cli 提供的一个选项，用于创建一个 Redis 集群。

192.168.2.159:6381 192.168.2.159:6382 192.168.2.159:6383 192.168.2.159:6384 192.168.2.159:6385 192.168.2.159:6386：这是一系列 Redis 实例的地址和端口号，用来构建 Redis 集群。在这个命令中，共有六个节点，分别位于相同的 IP 地址 192.168.2.159 上的不同端口号。

--cluster-replicas 1：这个参数指定了集群中的副本数量。在这个命令中，指定了每个主节点都会有一个对应的从节点。副本数量的设置对于集群的可用性和容错性非常重要，它确保了在主节点故障时可以自动切换到从节点以保证服务的可用性。

确认配置

# 使用 redis-cli 工具创建 Redis 集群
redis-cli --cluster create 192.168.2.159:6381 192.168.2.159:6382 192.168.2.159:6383 192.168.2.159:6384 192.168.2.159:6385 192.168.2.159:6386 --cluster-replicas 1

>>> Performing hash slots allocation on 6 nodes...
# 分配哈希槽到 6 个节点上...

# 为每个主节点分配哈希槽范围
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383

# 为每个主节点添加副本
#192.168.2.159:6385 作为 192.168.2.159:6382 的从节点
#192.168.2.159:6386 作为 192.168.2.159:6383 的从节点
#192.168.2.159:6384 作为 192.168.2.159:6381 的从节点
Adding replica 192.168.2.159:6385 to 192.168.2.159:6381
Adding replica 192.168.2.159:6386 to 192.168.2.159:6382
Adding replica 192.168.2.159:6384 to 192.168.2.159:6383


>>> Trying to optimize slaves allocation for anti-affinity
# 尝试优化从节点的分配以避免同一主机上有主从节点

[WARNING] Some slaves are in the same host as their master
# 警告：某些从节点与其主节点在同一主机上

# 显示节点分配情况
#192.168.2.159:6381 负责哈希槽 0 到 5460
#192.168.2.159:6382 负责哈希槽 5461 到 10922
#192.168.2.159:6383 负责哈希槽 10923 到 16383
M: a421f32820b0924ec50a3a064d284817a629d91d 192.168.2.159:6381
   slots:[0-5460] (5461 slots) master
M: ae9a43243fff5ae4f1282f1b3c1f7b2ca947615b 192.168.2.159:6382
   slots:[5461-10922] (5462 slots) master
M: 1b6d461fa6f3af02c88a519cda9ab8caed80699d 192.168.2.159:6383
   slots:[10923-16383] (5461 slots) master
S: 851835d6b208dfee42cfecd6385c9eedf11437cd 192.168.2.159:6384
   replicates a421f32820b0924ec50a3a064d284817a629d91d
S: 1c97e82bbaaee20f1c39768fff522a0087e40e5c 192.168.2.159:6385
   replicates ae9a43243fff5ae4f1282f1b3c1f7b2ca947615b
S: 0ec13cdb76d3c5af9abc4f20679e6ef005a98af0 192.168.2.159:6386
   replicates 1b6d461fa6f3af02c88a519cda9ab8caed80699d

# 确认是否应用上述配置，输入 'yes' 确认
Can I set the above configuration? (type 'yes' to accept): yes

在这里插入图片描述

成功配置并运行，所有 16384 个哈希槽已被正确分配并覆盖

在这里插入图片描述

4、查看集群状态

1、连接redis客户端（redis-node-1为例）

redis-cli -p 6381

在这里插入图片描述

127.0.0.1:6381> cluster info
cluster_state:ok
# 集群状态：ok 表示集群状态正常。
cluster_slots_assigned:16384
# 分配的哈希槽数量：16384 表示所有槽都已分配。
cluster_slots_ok:16384
# 正常的哈希槽数量：16384 表示所有槽都正常。
cluster_slots_pfail:0
# 潜在失效的哈希槽数量：0 表示没有潜在失效的槽。
cluster_slots_fail:0
# 失效的哈希槽数量：0 表示没有失效的槽。
cluster_known_nodes:6
# 已知的节点数量：6 表示集群中共有 6 个节点（3 个主节点，3 个从节点）。
cluster_size:3
# 集群大小：3 表示集群中有 3 个主节点。
cluster_current_epoch:6
# 当前纪元：6 表示当前集群的配置纪元。
cluster_my_epoch:1
# 当前节点的纪元：1 表示当前查询的节点的配置纪元。
cluster_stats_messages_ping_sent:201
# 发送的 PING 消息数量：201 表示集群中已发送了 201 条 PING 消息，用于节点之间的心跳检测。
cluster_stats_messages_pong_sent:208
# 发送的 PONG 消息数量：208 表示集群中已发送了 208 条 PONG 消息，用于响应 PING 消息。
cluster_stats_messages_sent:409
# 发送的总消息数量：409 表示集群中已发送了 409 条消息（包括 PING 和 PONG 消息）。
cluster_stats_messages_ping_received:203
# 接收到的 PING 消息数量：203 表示集群中已接收到 203 条 PING 消息。
cluster_stats_messages_pong_received:201
# 接收到的 PONG 消息数量：201 表示集群中已接收到 201 条 PONG 消息。
cluster_stats_messages_meet_received:5
# 接收到的 MEET 消息数量：5 表示集群中已接收到 5 条 MEET 消息，用于节点加入集群时的通信。
cluster_stats_messages_received:409
# 接收到的总消息数量：409 表示集群中已接收到 409 条消息（包括 PING、PONG 和 MEET 消息）。

在这里插入图片描述

127.0.0.1:6381> cluster nodes
ae9a43243fff5ae4f1282f1b3c1f7b2ca947615b 192.168.2.159:6382@16382 master - 0 1716360075833 2 connected 5461-10922
# 节点ID：ae9a43243fff5ae4f1282f1b3c1f7b2ca947615b
# 节点地址：192.168.2.159:6382
# 节点角色：主节点（master）
# 状态：connected
# 哈希槽范围：5461-10922
# 配置纪元：2

1c97e82bbaaee20f1c39768fff522a0087e40e5c 192.168.2.159:6385@16385 slave ae9a43243fff5ae4f1282f1b3c1f7b2ca947615b 0 1716360074000 2 connected
# 节点ID：1c97e82bbaaee20f1c39768fff522a0087e40e5c
# 节点地址：192.168.2.159:6385
# 节点角色：从节点（slave）
# 主节点ID：ae9a43243fff5ae4f1282f1b3c1f7b2ca947615b
# 状态：connected
# 配置纪元：2

851835d6b208dfee42cfecd6385c9eedf11437cd 192.168.2.159:6384@16384 slave a421f32820b0924ec50a3a064d284817a629d91d 0 1716360074832 1 connected
# 节点ID：851835d6b208dfee42cfecd6385c9eedf11437cd
# 节点地址：192.168.2.159:6384
# 节点角色：从节点（slave）
# 主节点ID：a421f32820b0924ec50a3a064d284817a629d91d
# 状态：connected
# 配置纪元：1

0ec13cdb76d3c5af9abc4f20679e6ef005a98af0 192.168.2.159:6386@16386 slave 1b6d461fa6f3af02c88a519cda9ab8caed80699d 0 1716360074000 3 connected
# 节点ID：0ec13cdb76d3c5af9abc4f20679e6ef005a98af0
# 节点地址：192.168.2.159:6386
# 节点角色：从节点（slave）
# 主节点ID：1b6d461fa6f3af02c88a519cda9ab8caed80699d
# 状态：connected
# 配置纪元：3

1b6d461fa6f3af02c88a519cda9ab8caed80699d 192.168.2.159:6383@16383 master - 0 1716360074000 3 connected 10923-16383
# 节点ID：1b6d461fa6f3af02c88a519cda9ab8caed80699d
# 节点地址：192.168.2.159:6383
# 节点角色：主节点（master）
# 状态：connected
# 哈希槽范围：10923-16383
# 配置纪元：3

a421f32820b0924ec50a3a064d284817a629d91d 192.168.2.159:6381@16381 myself,master - 0 1716360072000 1 connected 0-5460
# 节点ID：a421f32820b0924ec50a3a064d284817a629d91d
# 节点地址：192.168.2.159:6381
# 节点角色：主节点（master）
# 自己标识：myself
# 状态：connected
# 哈希槽范围：0-5460
# 配置纪元：1

在这里插入图片描述

三、主从容错迁移

1、数据读写存储

①、数据读写注意项

开启哈希槽集群模式后防止路由失效，连接redis客户端时需要带上-c选项

未加-c选项，报错无法存储数据

redis-cli -p 6381

127.0.0.1:6381> set k4 v4
(error) MOVED 8455 192.168.2.159:6382
127.0.0.1:6381> 

哈希槽号是 8455。
目标节点是 192.168.2.159:6382。
这意味着键 k4 应该存储在负责哈希槽 8455 的节点 192.168.2.159:6382 上。

在这里插入图片描述

加入-c选项，启动 CLI 的集群模式，这样 CLI 会自动处理重定向

redis-cli -p 6381 -c

127.0.0.1:6381> set k4 v4
-> Redirected to slot [8455] located at 192.168.2.159:6382
OK
192.168.2.159:6382> 

由于 k4 的哈希槽号为 8455，Redis 将请求重定向到负责该槽的节点 192.168.2.159:6382。

在这里插入图片描述

②、查看数据信息

redis-cli --cluster check 192.168.2.159:6381

#节点 192.168.2.159:6381 的 ID 为 a421f328...，负责 5461 个插槽，当前存储 3 个键，有一个从节点。
192.168.2.159:6381 (a421f328...) -> 3 keys | 5461 slots | 1 slaves.
#节点 192.168.2.159:6382 的 ID 为 ae9a4324...，负责 5462 个插槽，当前存储 1 个键，有一个从节点。
192.168.2.159:6382 (ae9a4324...) -> 1 keys | 5462 slots | 1 slaves.
#节点 192.168.2.159:6383 的 ID 为 1b6d461f...，负责 5461 个插槽，当前没有存储键，有一个从节点。
192.168.2.159:6383 (1b6d461f...) -> 0 keys | 5461 slots | 1 slaves.
#集群中总共有 4 个键，分布在 3 个主节点上。
[OK] 4 keys in 3 masters.
#每个插槽平均分配的键数为 0.00（因为大多数插槽目前是空的）。
0.00 keys per slot on average.
#使用节点 192.168.2.159:6381 执行集群检查。
>>> Performing Cluster Check (using node 192.168.2.159:6381)
#M 表示这是一个主节点。a421f32820b0924ec50a3a064d284817a629d91d 是节点的 ID。slots:[0-5460] (5461 slots) 表示这个主节点负责插槽 0 到 5460，共 5461 个插槽。1 additional replica(s) 表示这个节点有一个从节点。
M: a421f32820b0924ec50a3a064d284817a629d91d 192.168.2.159:6381
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
M: ae9a43243fff5ae4f1282f1b3c1f7b2ca947615b 192.168.2.159:6382
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: 1c97e82bbaaee20f1c39768fff522a0087e40e5c 192.168.2.159:6385
   slots: (0 slots) slave
   replicates ae9a43243fff5ae4f1282f1b3c1f7b2ca947615b
S: 851835d6b208dfee42cfecd6385c9eedf11437cd 192.168.2.159:6384
   slots: (0 slots) slave
   replicates a421f32820b0924ec50a3a064d284817a629d91d
S: 0ec13cdb76d3c5af9abc4f20679e6ef005a98af0 192.168.2.159:6386
   slots: (0 slots) slave
   replicates 1b6d461fa6f3af02c88a519cda9ab8caed80699d
M: 1b6d461fa6f3af02c88a519cda9ab8caed80699d 192.168.2.159:6383
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
#所有节点关于插槽配置一致。
[OK] All nodes agree about slots configuration.
#检查打开的插槽（没有未覆盖的插槽）。
>>> Check for open slots...
>>> Check slots coverage...
#检查插槽覆盖情况，所有 16384 个插槽都被覆盖。
[OK] All 16384 slots covered.

在这里插入图片描述

2、容错切换迁移

①、主从切换验证

目前主从分布情况如下（根据实际情况而定）：

在这里插入图片描述

停止Master-1运行

docker stop redis-node-1

在这里插入图片描述

进入Slave-4容器

docker exec -it redis-node-4 bash

在这里插入图片描述

查看集群状态

redis-cli --cluster check 192.168.2.159:6384

在这里插入图片描述

②、还原主从

启动Master-1

docker start redis-node-1

在这里插入图片描述

停止Slave-4

docker stop redis-node-4

在这里插入图片描述

启动Slave-4（需要等几秒钟，等待心跳发送）

docker start redis-node-4

进入Master-1

docker exec -it redis-node-1 bash

查看集群信息

docker exec -it redis-node-1 bash

在这里插入图片描述

四、主从扩容

创建两个新redis容器7、8

docker run -d --name redis-node-7 --net host --privileged=true -v /data/redis/share/redis-node-7:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6387

docker run -d --name redis-node-8 --net host --privileged=true -v /data/redis/share/redis-node-8:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6388

在这里插入图片描述

查看容器运行状态

docker ps -a

在这里插入图片描述

进入7号机容器内部

docker exec -it redis-node-7 bash

在这里插入图片描述

让7号作为master加入原集群

redis-cli --cluster add-node 192.168.2.159:6387 192.168.2.159:6381

将新增的6387作为master节点加入集群，
redis-cli --cluster add-node 自己实际IP地址:6387 自己实际IP地址:6381
6387就是将作为master新增节点
6381就是原来集群节点里面的领路人，相当于6387拜6381的码头从而找到组织加入集群

724024159.png?origin_url=..%2F..%2F10_picture%2Fimage-20240522152256114.png&pos_id=img-tTcvOfr7-1716365905338)

检查集群情况

redis-cli --cluster check 192.168.2.159:6381

在这里插入图片描述

分配槽号

redis-cli --cluster reshard192.168.2.159:6381

在这里插入图片描述

分配每个槽位数量（根据16384/Master数量）

How many slots do you want to move (from 1 to 16384)?

在这里插入图片描述

槽位给予新增Master

M: a5e1b955a8d1cef43f00e23ab3e0aafde2ee2d01 192.168.2.159:6387
   slots: (0 slots) master

在这里插入图片描述

What is the receiving node ID? a5e1b955a8d1cef43f00e23ab3e0aafde2ee2d01

选择Master节点（由哪些节点分配出槽位给予新增master）

Please enter all the source node IDs.
  Type 'all' to use all the nodes as source nodes for the hash slots.
  Type 'done' once you entered all the source nodes IDs.

所有Master节点进行重新分配，输入all
指定节点进行分配，则输入ID，然后输入done

在这里插入图片描述

执行提议的重新分配插槽计划

Do you want to proceed with the proposed reshard plan (yes/no)?

在这里插入图片描述

查看集群情况

新增的槽位是原本3台Master分配给新增的Master，这是由于重新分配成本太高

redis-cli --cluster check 192.168.2.159:6387

在这里插入图片描述

添加从节点

redis-cli --cluster add-node 192.168.2.159:6388 192.168.2.159:6387 --cluster-slave --cluster-master-id a5e1b955a8d1cef43f00e23ab3e0aafde2ee2d01


a5e1b955a8d1cef43f00e23ab3e0aafde2ee2d01根据实际情况替换新增的masterID

在这里插入图片描述

检查集群情况

redis-cli --cluster check 192.168.2.159:6387

在这里插入图片描述

五、主从缩容

查看集群环境获取节点ID

redis-cli --cluster check 192.168.2.159:6387

192.168.2.159:6387ID：a5e1b955a8d1cef43f00e23ab3e0aafde2ee2d01
192.168.2.159:6388ID：f891241c6cf8c8d093f8c0dc52eebabd41a25389

在这里插入图片描述

删除从节点

redis-cli --cluster del-node 从节点ID:从节点端口 从节点ID
redis-cli --cluster del-node 192.168.2.159:6388 f891241c6cf8c8d093f8c0dc52eebabd41a25389

在这里插入图片描述

检查集群情况

redis-cli --cluster check 192.168.2.159:6387

在这里插入图片描述

清空主机槽号

redis-cli --cluster reshard 192.168.2.159:6381

在这里插入图片描述

槽位分配

由于新增master6387删除，所有多出来4096个槽位，
也可以分多次分配平均分配到多台master，一次分配1000也可以

在这里插入图片描述

6381接收槽位

M: a421f32820b0924ec50a3a064d284817a629d91d 192.168.2.159:6381
   slots:[1365-5460] (4096 slots) master
   1 additional replica(s)

在这里插入图片描述

6387释放槽位

M: a5e1b955a8d1cef43f00e23ab3e0aafde2ee2d01 192.168.2.159:6387
   slots:[0-1364],[5461-6826],[10923-12287] (4096 slots) master

在这里插入图片描述

执行分配计划

在这里插入图片描述

查看集群情况

redis-cli --cluster check 192.168.2.159:6387

在这里插入图片描述

删除6387节点

M: a5e1b955a8d1cef43f00e23ab3e0aafde2ee2d01 192.168.2.159:6387
   slots: (0 slots) master

redis-cli --cluster del-node 192.168.2.159:6387 a5e1b955a8d1cef43f00e23ab3e0aafde2ee2d01

在这里插入图片描述

检查集群

redis-cli --cluster check 192.168.2.159:6381

在这里插入图片描述

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/659485.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

Ansible03-Ansible Playbook剧本详解

Ansible03-Ansible Playbook剧本详解

目录 写在前面5. Ansible Playbook 剧本5.1 YAML语法5.1.1 语法规定5.1.2 示例5.1.3 YAML数据类型 5.2 Playbook组件5.3 Playbook 案例5.3.1 Playbook语句5.3.2 Playbook1 分发hosts文件5.3.3 Playbook2 分发软件包，安装软件包，启动服务5.3.3.1 任务拆解…
阅读更多...
数分之SQL查询电商数据案例

数分之SQL查询电商数据案例

1,Python连接SQL数据库 以下是使用Python连接MySQL数据库并进行操作的示例代码： import random import time import pymysql# 定义名字数据 xing ["王", "李", "张", "刘", "陈", "杨", "黄&q…
阅读更多...
【火猫CS2】fantic取代C9参加YaLLa指南针

【火猫CS2】fantic取代C9参加YaLLa指南针

1、近日YaLLa Compass主办方宣布,由于Could9战队未能在截止日期前提交完整的参赛阵容,fantic战队将取代其参赛。该比赛将在阿联酋阿布扎比举行,总奖金40万美元。 最近一段时间Cloud9战队最近将electroNic转会至VP,又下放了HObbit和Perfecto,队伍因没有完整阵容已被迫退出EPL S1…
阅读更多...
服装服饰商城小程序的作用是什么

服装服饰商城小程序的作用是什么

要说服装商家，那数量是非常多，厂家/经销门店/小摊/无货源等，线上线下同行竞争激烈，虽然用户群体广涵盖每个人，但每个商家肯定都希望更多客户被自己转化，渠道运营方案营销环境等不可少。 以年轻人为主的消费…
阅读更多...
前端破圈用Docker开发项目

前端破圈用Docker开发项目

为什么要用 Docker 开发 🤔 直接在系统上开发不香吗？香，但是 Docker 有下面4香 环境依赖管理：Docker 容器可以管理所有依赖项，例如前端里面的 node 和 npm 版本，不需要在本地安装和维护这些依赖项 隔离&a…
阅读更多...
【刷题（12）】图论

【刷题（12）】图论

一、图论问题基础 在 LeetCode 中，「岛屿问题」是一个系列系列问题，比如： 岛屿数量 （Easy）岛屿的周长 （Easy）岛屿的最大面积 （Medium）最大人工岛 （Hard&…
阅读更多...
高效记录收支明细，预设类别账户，智能统计财务脉络，轻松掌握个人财务！

高效记录收支明细，预设类别账户，智能统计财务脉络，轻松掌握个人财务！

收支明细管理是每位个人或企业都必须面对的财务任务，财务管理已经成为我们生活中不可或缺的一部分。如何高效记录收支明细，预设类别账户，智能统计财务脉络，轻松掌握个人财务？晨曦记账本为您提供了完美的解决方案&#…
阅读更多...
windows环境redis未授权利用手法总结

windows环境redis未授权利用手法总结

Redis未授权产生原因 1.redis绑定在0.0.0.0:6379默认端口，直接暴露在公网，无防火墙进行来源信任防护。 2.没有设置密码认证，可以免密远程登录redis服务 漏洞危害 1.信息泄露，攻击者可以恶意执行flushall清空数据 2.可以通过ev…
阅读更多...
使用docker安装nacos单机部署

使用docker安装nacos单机部署

话不多说，直接进入主题 1.查看nacos镜像 docker search nacos 一般选第一个也就是starts最高的。 2.拉取nacos镜像 docker pull nacos/nacos-serverdocker pull nacos/nacos-server:1.4.1 由于我使用的项目alibabacloud版本对应的是nacos1.4.1版本的，所以我安装的是1.4.1…
阅读更多...
复购率下降是什么原因导致的？三个步骤直击复购率下降根源

复购率下降是什么原因导致的？三个步骤直击复购率下降根源

在商业运营中，回购率的波动往往能够直观地反映出客户对品牌和产品的忠诚程度。一个健康的回购率可以为企业带来稳定的收入流，同时也是品牌口碑和市场影响力的有力证明。但是，当企业面临回购率下降的情况时，这通常是一个警示信号&a…
阅读更多...
新版IDEA没有办法选择Java8版本解决方法

新版IDEA没有办法选择Java8版本解决方法

2023年11月27日后，spring.io 默认不再支持创建jdk1.8的项目 解决方法就是把 Spring的Server URL 改为阿里的。 阿里的Server URL https://start.aliyun.com/ 默认的Server URL https://start.spring.io 阿里的Server URL https://start.aliyun.com/
阅读更多...
【iOS】UI学习（一）

【iOS】UI学习（一）

UI学习（一） UILabelUIButtonUIButton事件 UIViewUIView对象的隐藏UIView的层级关系 UIWindowUIViewController定时器与视图对象 UISwitch UILabel UILabel是一种可以显示在屏幕上，显示文字的一种UI。 下面使用代码来演示UILabel的功能&#…
阅读更多...
AI联想扩图解决方案，智能联想，无需人工干预

AI联想扩图解决方案，智能联想，无需人工干预

对于众多企业而言，无论是广告宣传、产品展示还是客户体验，高质量、宽广视野的图像都是不可或缺的。受限于车载摄像头等设备的物理限制，我们往往难以捕捉到完整、宽广的视觉场景。针对这一挑战，美摄科技凭借其前沿的AI联想扩图解决…
阅读更多...
H2RSVLM：引领遥感视觉语言模型的革命

H2RSVLM：引领遥感视觉语言模型的革命

随着人工智能技术的飞速发展，遥感图像理解在环境监测、气候变化、粮食安全和灾害预警等多个领域扮演着越来越重要的角色。然而，现有的通用视觉语言模型（VLMs）在处理遥感图像时仍面临挑战，主要因为遥感图像的独特性和当…
阅读更多...
15.Redis之持久化

15.Redis之持久化

0.知识引入 mysql的事务,有四个比较核心的特性. 1. 原子性 2.一致性 3.持久性 >(和持久化说的是一回事)【把数据存储在硬盘 >持久把数据存储茌内存上>不持久~】【重启进程/重启主机 之后,数据是否存在!!】 4.隔离性~ Redis 是一个 内存 数据库.把数据存储在内存中的…
阅读更多...
【数据结构和算法】-动态规划爬楼梯

【数据结构和算法】-动态规划爬楼梯

动态规划（Dynamic Programming，DP）是运筹学的一个分支，主要用于解决包含重叠子问题和最优子结构性质的问题。它的核心思想是将一个复杂的问题分解为若干个子问题，并保存子问题的解，以便在需要时直接利用&am…
阅读更多...
万亿应急国债项目之通信指挥类应急装备多链路聚合通信设备在应急行业中的重要作用

万亿应急国债项目之通信指挥类应急装备多链路聚合通信设备在应急行业中的重要作用

万亿应急国债项目的推出，无疑是我国在应急领域的一次重大举措。在这一宏大蓝图中，通信指挥类应急装备的多链路聚合通信设备显得尤为重要，其在应急行业中所发挥的作用，堪称不可或缺的关键一环。 通信指挥是应急响应中的核心环节&a…
阅读更多...
登峰造极，北斗相伴——纪念人类首次登顶珠穆朗玛峰71周年

登峰造极，北斗相伴——纪念人类首次登顶珠穆朗玛峰71周年

71年前的今天，1953年5月29日11时30分，人类实现了一个伟大的壮举：首次登上了珠穆朗玛峰，这座海拔8848.86米的世界最高峰。这是一次充满了艰辛、勇气和智慧的探险，也是一次改变了人类历史和文化的探险。 自那以后&#…
阅读更多...
[FlareOn6]Overlong

[FlareOn6]Overlong

很简单的逻辑 一度让我以为是加保护了 运行告诉我从未编码,懵逼 动调你也发现,你根本没什么可以操作的空间,密文什么的,都是固定的 但是这里大家发现没 我们只加密了28个密文 然后text是128 也就是 0x80 是不是因为密文没加密完呢 我也懒得去写代码了 汇编直接修改push 字…
阅读更多...
windows使用gzip和bzip2对文件进行压缩

windows使用gzip和bzip2对文件进行压缩

git软件 git bash：下载地址https://git-scm.com/downloads，安装时一路next。 这个软件是给程序员提交代码用的工具，内置linux系统的命令行，可以使用linux系统特有的压缩软件gzip和bzip2. gzip使用 gzip一般用于压缩tar包&#…
阅读更多...
最新文章

Copyright @ 2022~2023