本文介绍: redis3.0引入分布式存储方案集群是由多个node节点组成,redis数据分布在这些节点当中。在集群当中也分为主节点和从节点

rediscluster集群

redis3.0引入分布式存储方案
集群是由多个node节点组成,redis数据分布在这些节点当中。
在集群当中也分为主节点和从节点。
 

集群架构

工作模式

集群模式当中是一 一对应的,主有数据写入读取功能,从只有读的功能
集群模式自带哨兵模式,可以自动实现故障切换,但是在故障切换完成之前,整个集群都将不可用。切换完毕之后,集群会立刻恢复

集群的流程

1、集群自带主从哨兵
2、每个主从节点之间互相隔离的,可以容忍数据的不完整。
3、哈希槽位决定每个结点操作,在创建key时,系统已经分配好了指定槽位。
4、MOVED部署报错,只是提醒客户去分配的槽位节点获取数据

集群模式是按照数据分片

1、数据分区:是集群的核心功能,每隔主都可以对外提供读写功能,但是数据是一一对写入主的对应从节点。在集群模式中,可容忍数据的不完整。
2、高可用:集群的主要目的

哈希

redis的集群引入一个哈希槽的概念
redis集群当中16384个哈希槽位。(0-16383)
ge根据集群当中的主从节点上的节点数,分配哈希槽位,每个槽位只负责一部分槽位。
每次读写都涉及到哈希槽位,key通过CRC16校验之后,对16384取余数,余数值决定数据放入到哪个槽位。通过对应槽位所在的节点,然后直接跳转到这个节点。
一个哈希槽位是连续且16383个槽位都会被分配

哈希流程图

主节点宕机之后,主节点原来负责哈希槽位将会不可用,需要从节点代替主节点继续负责原有的哈希操作。保证集群正常工作故障求换的过程中,集群会提示不可用。切换完成后,集群恢复正常工作
 

实验

实验需求需要6台装有redis虚拟机

                                六台redis服务器配置
vim /etc/redis/6379.conf
*****************************************************************************************

1、默认监听所有网卡-----70行
bind 0.0.0.0

2、关闭保护模式-----89行
protect-mode no

3、开启守护进程,以独立进程启动-----137行
daemonize yes

4、开启AOF持久化-----700行
appendonly yes

5、开启集群功能-----833行
cluster-enabled yes

6、集群名称文件设置-----841行
cluster-config-file nodes-6003.conf

7、集群超时时间设置-----847行(15000毫秒)
cluster-node-timeout 15000

*****************************************************************************************

创建集群:redis-cli -h 所在服务器ip --cluster create ip地址:6379 --cluster-replicas 1

此时在192.168.10.80主机创建
redis-cli -h 192.168.10.80 --cluster create 192.168.10.80:6379  192.168.10.150:6379 179 192.168.10.152:6379 192.168.10.153:6379 192.168.10.154:6379 --cluster-replicas 1

[root@localhost ~]# redis-cli -h 192.168.10.80 --cluster create 192.168.10.80:6379  192.168.79 192.168.10.152:6379 192.168.10.153:6379 192.168.10.154:6379 --cluster-replicas 1
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.10.153:6379 to 192.168.10.80:6379
Adding replica 192.168.10.154:6379 to 192.168.10.150:6379
Adding replica 192.168.10.152:6379 to 192.168.10.151:6379
M: f9a09e3ededa9767aafc6aca98fcaad8e28272b6 192.168.10.80:6379
   slots:[0-5460] (5461 slots) master
M: 508caf1dfeab313b2df0173dc015b62591b012fb 192.168.10.150:6379
   slots:[5461-10922] (5462 slots) master
M: 68d8e79f5b4478dcd8143ef024607f17d02820c6 192.168.10.151:6379
   slots:[10923-16383] (5461 slots) master
S: 6c1dc5ae608ca1c20f80f4762933ee07aa4a77c5 192.168.10.152:6379
   replicates 68d8e79f5b4478dcd8143ef024607f17d02820c6
S: d82924c43dd5c907fda4abf35ffe33ad2b295abf 192.168.10.153:6379
   replicates f9a09e3ededa9767aafc6aca98fcaad8e28272b6
S: 8ae774dce41372b08e38904ef81adba51413d072 192.168.10.154:6379
   replicates 508caf1dfeab313b2df0173dc015b62591b012fb
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
....
>>> Performing Cluster Check (using node 192.168.10.80:6379)
M: f9a09e3ededa9767aafc6aca98fcaad8e28272b6 192.168.10.80:6379
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
S: 8ae774dce41372b08e38904ef81adba51413d072 192.168.10.154:6379
   slots: (0 slots) slave
   replicates 508caf1dfeab313b2df0173dc015b62591b012fb
S: 6c1dc5ae608ca1c20f80f4762933ee07aa4a77c5 192.168.10.152:6379
   slots: (0 slots) slave
   replicates 68d8e79f5b4478dcd8143ef024607f17d02820c6
M: 68d8e79f5b4478dcd8143ef024607f17d02820c6 192.168.10.151:6379
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
S: d82924c43dd5c907fda4abf35ffe33ad2b295abf 192.168.10.153:6379
   slots: (0 slots) slave
   replicates f9a09e3ededa9767aafc6aca98fcaad8e28272b6
M: 508caf1dfeab313b2df0173dc015b62591b012fb 192.168.10.150:6379
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
[root@localhost ~]# 

查看hash槽位CLUSTER nodes

(1)验证从节点能不能读。不能

此处error不是报错,表明客户端尝试读取键值test1,但是实际槽位在4768,因此集群要求客户端移动到4768槽位所在的主机节点获取数据

(2)验证从节点能不能写。不能

(3)验证分配hash槽位后,不在相应的hash槽位上的主节点能不能写。不能,只能到指定节点上操作

模拟故障

任意一台服务器故障

主20.0.0.34——redis3故障,从20.0.0.44——redis4成为新主

恢复故障

恢复原主20.0.0.34——redis3

 monitor 查看哨兵ping命令

监控redis实时工作日志检测主从节点之间的心跳线

原文地址:https://blog.csdn.net/qq_61843057/article/details/134573730

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任

如若转载,请注明出处:http://www.7code.cn/show_14587.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱suwngjj01@126.com进行投诉反馈,一经查实,立即删除

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注