Redis集群

龙崎流河

已于 2023-03-31 15:02:22 修改

阅读量254

点赞数 1

分类专栏： redis 文章标签： redis 数据库 java

于 2023-03-30 21:50:14 首次发布

本文链接：https://blog.youkuaiyun.com/Jiaodaqiaobiluo/article/details/129857450

版权

redis 专栏收录该内容

9 篇文章

订阅专栏

文章目录

定义
作用
集群的算法-分片-槽位slot
- slot槽位映射，业界的三种解决方案
集群环境案例步骤
集群常用命令和CRC16算法分析

定义

Redis集群是一个提供在多个Redis节点间共享数据的程序集，可以支持多个Master。
在这里插入图片描述

作用

Redis集群支持多个Master，每个Master又可以挂在多个Slave，并且由于集群自带哨兵的故障转移机制，内置了高可用的支持，无需再去使用哨兵功能。
客户端与Redis的节点连接，不再需要连接集群中所有的节点，只需要任意连接集群中的一个可用节点即可。
槽位slot负责分配到各个物理服务节点，由对应的集群来负责维护节点，插槽和数据之间的关系。

集群的算法-分片-槽位slot

集群的密钥空间被分为16384个槽，有效地设置了16384个主节点的集群大小上限（但是建议最大节点大小为1000个节点）
哈希槽实质是一个数组，数组[0, 2 ^ 14 - 1]形成hash slot空间，解决均匀分配问题，在数据和节点之间又加入了一层，把这层称为哈希槽，用于管理数据和节点之间的关系，槽解决的粒度问题，相当于把粒度变大了，便于数据移动。

Redis集群的数据分片：

集群没有使用一致性hash，而是引入哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。
在这里插入图片描述
集群中每个redis实例都被认为是整个数据的一个分片，使用redis集群时我们会将存储的数据分散到多台redis机器上。
最大的优势就是方便扩容缩容和数据分派查找。

slot槽位映射，业界的三种解决方案

哈希取余分区

每次数据变动导致节点有变动，映射关系需要重新进行计算。
在这里插入图片描述

一致性哈希算法

提出一致性Hash解决方案，为了当服务器个数发生变动的时候尽量减少影响客户端到服务器的映射关系。
步骤1：
算法构建一致性哈希环
在这里插入图片描述
步骤2：
redis服务器IP节点映射

步骤3：
key落到服务器落键规则

在这里插入图片描述
优点：
加入和删除节点只影响哈希环中顺时针方向相邻的节点，对其他节点无影响。
容错性：

扩展性：

缺点：
数据分布与节点位置相关，因为这些节点不是均匀分布在哈希环上，所以数据进行存储时达不到均匀分布。
在这里插入图片描述

哈希槽分区

在这里插入图片描述

为什么槽的数量是16384
CRC16算法产生的hash值有16bit，该算法产生65535个值，但为什么不用65535呢

在这里插入图片描述
redis集群不保证强一致性，在特定条件下，redis集群可能会丢掉一些被系统收到的写入请求命令。

集群环境案例步骤

三主三从
在这里插入图片描述

新建6个独立的redis实例服务

比如6381配置：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6381
logfile "/myredis/cluster/cluster6381.log"
pidfile /myredis/cluster6381.pid
dir /myredis/cluster
dbfilename dump6381.rdb
appendonly yes
appendfilename "appendonly6381.aof"
requirepass 111111
masterauth 111111
 
cluster-enabled yes
cluster-config-file nodes-6381.conf
cluster-node-timeout 5000

6382配置：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6382
logfile "/myredis/cluster/cluster6382.log"
pidfile /myredis/cluster6382.pid
dir /myredis/cluster
dbfilename dump6382.rdb
appendonly yes
appendfilename "appendonly6382.aof"
requirepass 111111
masterauth 111111
 
cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000

开启它们的服务，比如
redis-server /myredis/cluster/redisCluster6381.conf

构建主从关系命令

–cluster-replicas表示为每个master创建一个slave节点
redis-cli -a 111111 --cluster create --cluster-replicas 1 192.168.111.175:6381 192.168.111.175:6382 192.168.111.172:6383 192.168.111.172:6384 192.168.111.174:6385 192.168.111.174:6386
在这里插入图片描述
一切都ok，三主三从搞定

链接进入6381作为切入点，查看并检验集群状态

redis-cli -a 111111 6381
info replication
在这里插入图片描述
cluster nodes
查看集群信息

cluster info

三主三从redis集群读写

注意槽位的范围区间，需要路由到位
在这里插入图片描述

防止出现这种错误，加入参数-c，优化路由。
redis-cli -a 111111 -p 6381 -c

查看某个key该属于对应的槽位值CLUSTER KEYSLOT键名称
cluster keyslot k1

主从切换迁移案例

主6381和从机切换，先停止主机6381，6381主机停了，对应的真实从机上位。
6381原来的主机回来了，是否会上位？
恢复前：
在这里插入图片描述
恢复后：
6381不会上位并从节点形式回归

集群不保证数据一致性百分之百OK，一定会有数据丢失情况。
上面一换后6381和6384主从对调了，该怎么给它调回来？
重新登录6381机器后，使用命令CLUSTER FAILOVER
在这里插入图片描述

主从扩容案例

首先新建6387和6388两个服务实例配置文件+新建后启动：
vim /myredis/cluster/redisCluster6387.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 6387
logfile "/myredis/cluster/cluster6387.log"
pidfile /myredis/cluster6387.pid
dir /myredis/cluster
dbfilename dump6387.rdb
appendonly yes
appendfilename "appendonly6387.aof"
requirepass 111111
masterauth 111111

cluster-enabled yes
cluster-config-file nodes-6387.conf
cluster-node-timeout 5000

vim /myredis/cluster/redisCluster6388.conf


bind 0.0.0.0
daemonize yes
protected-mode no
port 6388
logfile "/myredis/cluster/cluster6388.log"
pidfile /myredis/cluster6388.pid
dir /myredis/cluster
dbfilename dump6388.rdb
appendonly yes
appendfilename "appendonly6388.aof"
requirepass 111111
masterauth 111111
 
cluster-enabled yes
cluster-config-file nodes-6388.conf
cluster-node-timeout 5000

启动这两个实例
将新增的6387节点作为master节点加入原集群：
redis-cli -a 111111 --cluster add-node 192.168.111.174:6387 192.168.111.175:6381
在这里插入图片描述
检查集群情况第一次:
redis-cli -a 111111 --cluster check 192.168.111.175:6381

重新分配槽号：
redis -cli -a 111111 --cluster reshard 192.168.111.175:6381

再检查一次：

为主节点6387分配从节点6388：

检查集群第三次：
在这里插入图片描述

主从缩容案例

目的：6387和6388下线
检查集群情况第一次，先获得从机6388的节点ID：
在这里插入图片描述
从集群中将4号从节点6388删除：
redis-cli -a 111111 --cluster del-node 192.168.111.174:6388 218e7b8b4f81be54ff173e4776b4f4faaf7c13da

将6387的槽清空，重新分配，本例将清出来的槽号都给6381
redis-cli -a 111111 --cluster reshard 192.168.111.175:6381
在这里插入图片描述

检查集群第二次：

删除6387：

检查集群情况第三次，6387/6388被彻底去除

集群常用命令和CRC16算法分析

不在同一个槽位下的键值无法使用mset，mget等多键操作，但可以通过{}来定义同一个组的概念，使key中{}内相同内容的键值对放到一个slot槽位去。
在这里插入图片描述
redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每一个节点负责一部分hash槽。
常用的命令有：
cluster-require-full-coverage yes

CLUSTER COUNTKEYSINSLOT 槽位数字编号
1表示该槽位被占用，0表示该槽位没占用
ClUSTER KEYSLOT 键名称
该键应该存在哪个槽位上