REDIS集群
目录
前言
一、概述
二、架构细节
三、选举过程
四、搭建
前言
Redis集群是指将多个Redis节点组成一个集群，通过节点间的数据分布和协调来提供高可用性和性能的数据库解决方案。每个节点可以存储数据，处理请求，并与其他节点进行通信，以实现数据的拷贝和复制。
Redis集群的主要特点包括：
1. 数据分片：将数据分成多个片段并存储在不同的节点上，以提高性能和负载均衡。
2. 数据复制：每个主节点都会有多个从节点，用于数据的备份和复制，以增加数据的可靠性和容错性。
3. 节点协调：有一个特殊的节点作为集群的主节点，负责监控和协调其他节点的状态和数据分布，以保持集群的正常运行。
4. 故障转移：当主节点发生故障时，从节点会自动选举一个新的主节点来接管服务，以实现高可用性和容错性。
5. 节点间通信：节点之间通过内部的二进制协议进行通信，以传输数据和同步状态。
使用Redis集群可以实现数据的高可用性和性能的提升，因为数据被分布在多个节点上，可以并行处理请求，同时通过数据的复制和故障转移，可以提供持久性和容错性。此外，Redis集群还支持自动的故障检测和修复机制，可以在节点故障或网络分区的情况下保持服务的可用性。
一、概述
Redis3.0版本以上开始支持cluster，采用的是hashslot（hash槽），可以将多个Redis实例整合在一起，形成一个群集，也就是将数据分散到群集的多台机器上。
当客户端向群集中任一节点发送与数据库键有关的命令时，接收命令的节点会计算出命令要处理的数据库键属于哪个槽，并检查这个槽是否指派给了自己。如果键所在的槽正好指派给了当前节点，那么节点直接执行这个命令；如果键所在的槽并没有指派给当前节点，那么节点会向客户端返回一个MOVED错误，指引客户端转向（redirect）正确的节点，并再次发送之前想要执行的命令.
群集角色有Master和Slave.Master之间分配slots，一共16384个slot，Slave向它指定的Master 同步数据，实现备份。当其中的一个Master无法提供服务时，该Master的Slave将提升为Mester，以保证群集间 slot 的完整性，当其中的某一个Master和它的Slave都失效，导致了slot不完整，群集失效，这时就需要人工去处理了。
群集搭建好后，群集中的每个节点都会定期地向其他节点发送PING消息，如果接收PONG消息的节点没有在规定的时间内返回PONG 消息，那么发送PNG消息的节点就会将其标记为疑似下线（probable fail，PFAL）。各个节点会通过互相发送消息的方式来交换群集中各个节点的状态信息。如果在一个群集里面，半数以上的主节点都将某个主节点×报告为疑似下线，那么这个主节点×将被标记为已下线（FAL），同时会向群集广播一条关于主节点×的FAL消息，所有收到这条FAL消息的节点都会立即将主节点×标记为已下线。
当需要减少或者增加群集中的机器时，我们需要将已经指派给某个节点（源节点）的槽改为指派给另一个节点（目标节点），并且将相关槽所属的键值对从源节点移动到目标节点。
Redis群集的重新分片操作是由Redis的群集管理软件redis—trib负责执行的，不支持自动的分片，而且需要自己计算从哪些节点上迁移多少 Slot。在重新分片的过程中，群集不需要下线，并且源节点和目标节点都可以继续处理命令请求。
Redis Cluster是一个无中心的结构，每个节点都保存数据和整个群集的状态。每个节点都会保存其他节点的信息，知道其他节点所负责的槽，并且会与其他节点定时发送心跳信息，能够及时感知群集中异常的节点。
二、架构细节
架构细节：
（1）所有的redis节点彼此互联（PING-PONG机制），内部使用二进制协议优化传输速度和带宽。
（2）节点的失效（fail）在群集中超过半数的主（master）节点检测失效时才生效。
（3）客户端与 redis 节点直连，不需要中间代理（proxy）层，客户端不需要连接群集所有节点，连接群集中任何一个可用节点即可。
（4）redis-cluster 把所有的物理节点映射到【0-16383】slot 上，cluster 负责维护 node<->slot<->key。
三、选举过程
1.选举过程是群集中所有master参与，如果半数以上master节点与当前 master 节点通信超时（cluster—node—timeout），认为当前 master 节点挂掉。以下两种情况为整个群集不可用（cluster_state：fail），当群集不可用时，所有对群集的操作都不可用，收到(（error）CLUSTEFDOWN The cluster is down）错误。
2.如果群集任意 master挂掉，且当前 master 没有 slave，则群集进入 fail状态，也可以理解成群集的slot映射【0 ~16383】不完整时进入fail状态。
3.如果群集中超过半数的master挂掉，无论是否有slave，群集都进入 fail状态。
4.默认情况下，每个群集的节点都使用两个TCP端口.一个是6379，一个是16379；6379服务于客户端的连接，16379 用于群集总线，即使用二进制协议的节点到节点通信通道。节点使用群集总线进行故障检测、配置更新、故障转移授权等。如果开启了防火墙，需要开放这两个端口。
四、搭建
这里我以分布式搭建的形式来搭建：
1、准备三台主机IP分别设置为192.168.115.128 ；192.168.115.129 ； 192.168.115.130
2、分别设置防火墙、selinux、图形化，并且互相测试通联性
3、三台主机上安装REDIS
yum -y install epel-release.noarch
yum -y install redis4、在每台主机上配置REDIS
| 复制配置文件/etc/redis.conf |
mkdir /etc/redis
cp /etc/redis.conf /etc/redis1_6379.conf
cp /etc/redis.conf /etc/redis2_6380.conf
#####在其他主机上也是一样的的操作，不过我们需要注意的是修改文件名用来区分：例如在192.168.115.129主机上可以
cp /etc/redis.conf /etc/redis3_6379.conf
cp /etc/redis.conf /etc/redis4_6379.conf5、 分别编辑复制的配置文件
vim /etc/redis1_6379.conf
vim /etc/redis2_6380.conf 在这里我们需要修改的地方如下：
protected-mode yes
port 对应的端口号
bind 192.168.115.128 修改对应的监听地址
daemonize yes允许后台启动
dir /var/lib/redis/redis1_6379/ 修改目录，并在命令行创建对应的新目录
修改完成后我们修改/etc/redis2_6380.conf 包括其他主机上对应的配置文件，都按照此方法进行配置（注意端口、ip地址）
6、启动服务验证是否正常
启动：
redis-server /etc/redis/redis1_6379.conf
redis-server /etc/redis/redis2_6380.conf
验证：
netstat -anput | grep redis
同理验证其他主机上的REDIS是否正常启动：
由此可验证所有服务启动正常，可以进行下一步试验
7、修改配置文件，开启集群功能
与上步一样，依次修改我们的配置文件
vim /etc/redis1_6379.conf
vim /etc/redis2_6380.conf主要修改位置
cluster-enabled yes 开启集群功能
cluster-config-file nodes-6379.conf 修改我们的配置文件名
cluster-node-timeout 15000 超时时间
通过此步骤修改我们所有的其他配置文件，并且要注意文件名要修改成对应的
8、重启REDIS
kill REDIS的进程号
重启：
redis-server /etc/redis/redis1_6379.conf
redis-server /etc/redis/redis2_6380.conf
查看端口：
192.168.115.128
192.168.115.129
192.168.115.130
9、在192.168.115.128的6379端口登录并将其他的REDIS端加入集群
登录：redis-cli -h 192.168.115.128 -p 6379 把除了当前登录状态之外的REDIS加入集群（REDIS内操作）：
CLUSTER MEET 192.168.115.128 6380
10、按照要求为master分配哈希槽
在命令行操作：
redis-cli -h 192.168.115.128 -p 6379 cluster addslots {0..5461}
redis-cli -h 192.168.115.129 -p 6380 cluster addslots {5462..10922}
redis-cli -h 192.168.115.130 -p 6380 cluster addslots {10923..16383}
11、依据实验要求建立主从关系
登录REDIS：
redis-cli -h 192.168.115.128 -p 6379
查看UUID号：
cluster nodes
根据UUID进行配对：
redis-cli -h IP地址 -p端口号 cluster replicate UUID号 ##（IP写slave的 UUID写master）
12、登录REDIS进行查看
登录：
redis-cli -h 192.168.115.128 -p 6379
查看：
cluster info
翻译结果如下：
集群状态：正常
已分配的槽位数量：16384
正常的槽位数量：16384
故障预测的槽位数量：0
失败的槽位数量：0
已知节点数量：6
集群大小：3
当前集群纪元：5
我的集群纪元：1
发送的ping消息数量：5841
发送的pong消息数量：5764
发送的meet消息数量：5
发送的消息总数：11610
接收的ping消息数量：5764
接收的pong消息数量：5846
接收的消息总数：1610
查看：cluster nodes
查看端口：
##如果此处操作有误，主从建立有误使用cluster reset重置集群
测试：
配置完成。
总结
在进行配置时要注意的是每完成一步验证一步，这样就算出错了也能找出在哪一个环节。另外修改配置文件时重复性高，要仔细一些；在分配哈希槽时是分配给master，确立主从关系时要注意我们的关系要捋清楚。