redis-cluster集群

redis-cluster集群

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实时工作日志，检测主从节点之间的心跳线

主

从