如何部署Redis集群？

一、Redis集群简介

Redis Cluster是一个无中心的结构，每个节点都保存数据和整个群集的状态。每个节点都会保存其他节点的信息，知道其他节点所负责的槽，并且会与其他节点定时发送心跳信息，能够及时感知群集中异常的节点。
Redis没有统一的路口，当客户端向群集中任一节点发送与数据库键有关的命令时，接受命令的节点会计算出命令要处理的数据库键属于哪个槽，并检查这个槽是否指派给了自己。如果键所在的槽正好指派给了当前节点，那么节点直接执行这个命令；如果键所在的槽并没有指派给当前节点，那么节点会向客户端返回一个MOVED错误，指引客户端转向（redirect）正确的节点，并再次发送之前想要执行的命令。

二、Redis集群概述

2.1Redis集群介绍

●Redis集群是一个提供在多个Redis间节点间共享数据的程序集
●Redis集群并不支持处理多个keys的命令，因为这需要在不同的节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会导致不可预料的错误
●Redis集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下可继续处理命令

2.2Redis集群的优势

●自动分割数据到不同的节点上
●整个集群的部分节点失败或者不可达的情况下能够继续处理命令

2.3Redis集群的实现方法

●有客户端分片
●代理分片
●服务器端分片
客户端分片：
寻址方式都在客户端，写在java或者python语言里面
代理分片：

服务端分片：

2.4Redis-Cluster数据分片

●Redis集群没有使用一致性hash，而是引入了哈希槽概念
●Redis集群有16384个哈希槽
●每个key通过CRC16校验后对16384取余来决定放置槽
●集群的每个节点负责一部分哈希槽
Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value
时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，
这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大
致均等的将哈希槽映射到不同的节点。
●数据分片
以3个节点组成的集群为例
节点A包含0到5500号哈希槽
节点B包含5501到11000号哈希槽
节点C包含11001到16384号哈希槽
支持添加或者删除节点
添加/删除节点无需停止服务（支持热状态）
例如：
如果想新添加个节点D，需要移动节点A,B,C中的部分槽到D上
如果想移除节点A，需要将A中的槽移到B和C节点上，再将没有任何槽的A节点从集群中移除

2.5Redis-Cluster的主从复制模型

●集群中具有A,B,C三个节点，如果节点B失败了，整个集群就会因缺少5501-11000这个范围的槽而不可用
●为每个节点添加一个从节点A1,B1,C1，整个集群便有三个master节点和三个slave节点组成，在节点B失败后，集群便会选举B1为新的主节点继续服务
●当B和B1都失败后，集群将不可用

三、搭建Redis集群

3.1案例环境

VMware虚拟机；6台Linux服务器安装Centos 7.6系统

3.2实验步骤

1.配置redis集群，所有节点操作，redis详细编译安装过程可查看如下博客
https://blog.csdn.net/chengu04/article/details/108479164

[[e-mail] utils]# vim /etc/redis/6379.conf
70行：bind 127.0.0.1   #注释掉bind项，选项默认监听所有网卡
89行：protected-mode no  #关闭保护模式
93行：port 6379
137行：daemonize yes   #以独立进程启动
833行：cluster-enabled yes  #开启群集功能
841行：cluster-config-file nodes-6379.conf   #群集名称文件设置
847行：cluster-node-timeout 15000  #群集超时时间设置
700行：appendonly yes   #开启aof持久化

2.正常启动后，/var/lib/redis/6379/目录下会多出三个文件，第一个是持久化文件appendonly.aof，第二个是RDB持久文件dump.rdb，另外一个是节点首次启动生成的nodes-6379.conf

[[e-mail] utils]# cd /var/lib/redis/6379/
[[e-mail] 6379]# ls
[[e-mail] 6379]# /etc/init.d/redis_6379 restart
[[e-mail] 6379]# ls
appendonly.aof  dump.rdb  nodes-6379.conf

仅在一台redis中操作，准备生成集群：
3.导入key文件

[[e-mail] 6379]# gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

4.执行脚本安装rvm集群控制软件，再次安装redis

[[e-mail] ~]# ./rvm-installer.sh
#执行环境变量
[[e-mail] ~]# source /etc/profile.d/rvm.sh
#列出Ruby可安装的版本
[[e-mail] ~]# rvm list known
#安装Ruby2.4.10版本
[[e-mail] ~]# rvm install 2.4.10
#使用Ruby2.4.10版本
[[e-mail] ~]# rvm use 2.4.10
#查看当前Ruby2.4.10版本
[[e-mail] ~]# ruby -v
ruby 2.4.10p364 (2020-03-31 revision 67879) [x86_64-linux]
#再次安装redis
[[e-mail] ~]# gem install redis

5.创建集群
六个实例分为三组，每组一主一从，–replicas 1表示每组一个从，下面交互的时候需要输入yes才可以创建。

[[e-mail] profile.d]# redis-cli --cluster create 14.0.0.30:6379 14.0.0.10:6379 14.0.0.20:6379 14.0.0.40:6379 14.0.0.50:6379 14.0.0.60: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 14.0.0.50:6379 to 14.0.0.30:6379     #主从对应关系，前面是从，后面是主
Adding replica 14.0.0.60:6379 to 14.0.0.10:6379
Adding replica 14.0.0.40:6379 to 14.0.0.20:6379
M: 8a59412f89013609b200d6cf8ff256b1fd729610 14.0.0.30:6379
   slots:[0-5460] (5461 slots) master
M: 33708a660ebd3fadf9815037f066f3c3dad998d8 14.0.0.10:6379
   slots:[5461-10922] (5462 slots) master
M: d0a16331a86d1c7a519f70362b09dd3f8f938ee9 14.0.0.20:6379
   slots:[10923-16383] (5461 slots) master
S: 8d870587d63142e4aa61dbf5c1cd073bff0183fd 14.0.0.40:6379
   replicates d0a16331a86d1c7a519f70362b09dd3f8f938ee9
S: 45fb16a8c8de40e37e2d4d572c75defaa098c361 14.0.0.50:6379
   replicates 8a59412f89013609b200d6cf8ff256b1fd729610
S: 661c3f9acdfcb59080afca904bd0c4e94793d7d6 14.0.0.60:6379
   replicates 33708a660ebd3fadf9815037f066f3c3dad998d8

6.主从数据库验证

[[e-mail] 6379]# redis-cli -c -h 14.0.0.10   #master1写入键值
14.0.0.10:6379> set name tom
OK
14.0.0.10:6379> get name
"tom"
[[e-mail] ~]# redis-cli -c -h 14.0.0.50     #其他节点都能查看到数据，都是指向master1
14.0.0.50:6379> get name
-> Redirected to slot [5798] located at 14.0.0.10:6379
"tom"

#master1人为down掉,这时数据都是从slave1中读取到
[[e-mail] profile.d]# redis-cli -c -h 14.0.0.30
14.0.0.30:6379> get name
-> Redirected to slot [5798] located at 14.0.0.60:6379
"tom"

#master1挂了以后，slave1继承master1的哈希槽进行读写
[[e-mail] 6379]# redis-cli -c -h 14.0.0.50
14.0.0.50:6379> get ni
-> Redirected to slot [5546] located at 14.0.0.60:6379
"hao"
14.0.0.30:6379> set zhu cong
-> Redirected to slot [13176] located at 14.0.0.20:6379
OK
14.0.0.20:6379> set ji qun
-> Redirected to slot [6510] located at 14.0.0.60:6379
OK
#master1和slave1都down掉后，会显示群集已经down掉
[[e-mail] 6379]# redis-cli -c -h 14.0.0.50
14.0.0.50:6379> get ni
(error) CLUSTERDOWN The cluster is down

3.2实验总结

●导致群集down掉的两种情况
（1）三个master服务器全部宕机
（2）master1宕机，对应的slave1也发生了宕机
●在上述实验中，如果master1宕机，slave1会继承master1的哈希槽，成为master1，这时master1重新启动之后会变成slave节点，且就算刚才顶替上来的slave1节点关机掉，master1依然是slave节点。