redis为什么是cp_Redis【集群篇】

1 redis集群简介

1.1 集群的概念

所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态（高可用）。

1.1.1 使用redis集群的必要性

--问题：我们已经部署好了redis，并且能启动一个redis，实现数据的读写，为什么还需要redis集群？

[1] 单个redis存在不稳定性。当redis服务 宕机了，就没有可用的服务了。
[2] 单个redis的读写能力是有限的。

总结：redis集群是为了强化redis的读写能力、确保服务的高可用。

1.1.2 redis集群相关术语

[1] redis集群中，每一个redis称之为一个节点。
[2] redis集群中，有两种类型的节点：主节点（master）、从节点（slave）。
[3] redis集群，是基于redis 主从复制模式实现的。

因此，学习redis集群，就是从学习redis主从复制模式开始。

2 redis主从复制模式

2.1 概念

主从复制模式中，有多个redis节点。其中， 有且仅有一个为Master，而Slave可以有多个。并且只要网络连接正常，Master会一直将自己的数据 同步更新给Slaves，保持主从同步。

2.2 特点

[1] 主节点Master 可读、可写。
[2] 从节点Slave 只读。

因此，主从模式可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。

--主从模式架构图：

2.3 基于配置实现

2.3.1 准备

2.3.2 配置步骤

第一步：在/usr/local目录下，创建一个/redis/master-slave目录。

[root@node1 local]# mkdir -p redis/master-slave

第二步：在master-slave目录下，创建三个子目录6380、6381、6382

[root@node1 master-slave]# mkdir 6380 6381 6382

第三步：依次拷贝redis解压目录下的redis.conf配置文件，到这三个子目录中。

[root@node1 master-slave]# cp /usr/redis/redis-3.2.9/redis.conf ./6380/
[root@node1 master-slave]# cp /usr/redis/redis-3.2.9/redis.conf ./6381/
[root@node1 master-slave]# cp /usr/redis/redis-3.2.9/redis.conf ./6382/

第四步：进入6380目录，修改redis.conf，

[1] 将bind注释掉。
[2] 关闭保护模式。
[3] 并把port端口修改成6380。

第五步：进入6381目录，修改redis.conf。

[1] port端口改成6381。
[2] 开启主从复制模式。

第六步：进入6382目录，修改redis.conf，

[1] port端口改成6382。
[2] 开启主从复制模式。

2.3.3 测试

第一步：打开三个putty窗口，在每一个窗口中，启动一个redis节点。查看日志输出。（不要改成后台模式启动，看不到日志，不直观）。

[root@node1 master-slave]# cd ./6380 && redis-server ./redis.conf
[root@node1 master-slave]# cd ./6381 && redis-server ./redis.conf
[root@node1 master-slave]# cd ./6382 && redis-server ./redis.conf

第二步：另外再打开两个putty窗口，分别登陆Master和Slave。

[root@node1 ~]# redis-cli -p 6380
[root@node1 ~]# redis-cli -p 6381

第三步：在Slave上，进行读写操作，操作成功

127.0.0.1:6380> set user:name zs
OK
127.0.0.1:6380> get user:name
"zs"
127.0.0.1:6380>

第四步：在Slave上

**读操作执行成功，并且成功从6380上同步了数据

[root@node0719 ~]# redis-cli -p 6381
127.0.0.1:6381> get user:name
"zs"

**写操作执行失败（从节点，只能读，不能写）

127.0.0.1:6381> set user:age 18
(error) READONLY You can't write against a read only slave.

2.4 主从模式的缺陷

主从模式下，当Master宕机了，整个集群就没有可写的节点了。显然主从模式不是我们想要的集群方式。

因为Slave上备份了Master的所有数据，那在Master宕机的情况下，如果能够将Slave变成一个Master，是不是就可以解决这个问题了呢？

答：没错，这个就是 哨兵Sentinel的作用。

3 Sentinel哨兵模式

3.1 哨兵的任务

Redis的Sentinel系统用于管理多个Redis服务器，该系统完成以下三个任务：

**监控（Monitoring）：Sentinel会不断地检查Master和Slave是否运作正常。 **提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。 **自动故障迁移（Automatic failover）： 当Master不能正常工作时，Sentinel会开始一次自动故障迁移操作，它会进行选举，将其中一个Slave升级为新的Master，其他的Slave改为新Master的Slave；当客户端试图连接失效的Master时，集群会向客户端返回新Master的地址，使得集群可以使用新Master代替失效Master。

3.1.1 监控（Monitoring）

[1] Sentinel可以监控任意多个Master和该Master下的Slaves。（即多个主从模式）。 [2] 同一个哨兵下的、不同主从模型，彼此之间相互独立。
[3] Sentinel会不断检查Master和Slave是否正常。

3.1.2 自动故障切换（Automatic failover）

3.1.2.1 Sentinel网络

监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel网络，互相通信并交换彼此关于被监视服务器的信息。下图中，三个监控Master-Slave的Sentinel，自动组成Sentinel网络结构。

--问题：为什么要使用sentinel网络呢？

答：当只有一个sentinel的时候，如果这个sentinel挂掉了，那么就无法实现自动故障切换了。在sentinel网络中，只要还有一个sentinel活着，就可以实现故障切换。

3.1.2.2 故障切换过程

第一步：投票（半数原则）

当任何一个Sentinel发现被监控的Master下线时，会通知其它的Sentinel开会，投票确定该Master是否下线（半数以上就会下线，因此sentinel通常配奇数个）。

第二步：选举

当Sentinel确定Maste下线后，会在所有的Slaves中，选举一个新的节点，升级成Master节点。其它Slaves节点，转为该节点的从节点。

第三步：原Master重新上线

当原Master节点重新上线后，自动转为当前Master节点的从节点。

3.2 哨兵模式部署

3.2.1 前提

[1] 已经存在一个正在运行的主从模式。
[2] 配置三个Sentinel实例，监控同一个Master节点。

3.2.2 配置Sentinel

第一步：在/usr/local/redis目录下，创建/sentinels/目录

[root@node1 redis]# mkdir sentinels

第二步：在/sentinels目录下，以次创建s1、s2、s3三个子目录

[root@node1 sentinels]# mkdir s1 s2 s3

第三步：依次拷贝redis解压目录下的sentinel.conf文件，到这三个子目录中

[root@node1 sentinels]# cp /usr/redis/redis-3.2.9/sentinel.conf ./s1/
[root@node1 sentinels]# cp /usr/redis/redis-3.2.9/sentinel.conf ./s2/
[root@node1 sentinels]# cp /usr/redis/redis-3.2.9/sentinel.conf ./s3/

第四步：依次修改s1、s2、s3子目录中的sentinel.conf文件，修改端口，并指定要监控的主节点。（从节点不需要指定，sentinel会自动识别）

注意：当服务器使用了静态ip时，哨兵的配置文件需要加上如下配置：

**S1哨兵配置如下：

**S2哨兵配置如下：

**S3哨兵配置如下：

第五步：再打开三个putty窗口，在每一个窗口中，启动一个哨兵实例，并观察日志输出

[root@node0719 sentinels]# redis-sentinel ./s1/sentinel.conf
[root@node0719 sentinels]# redis-sentinel ./s2/sentinel.conf
[root@node0719 sentinels]# redis-sentinel ./s3/sentinel.conf

--核心日志输出：

3.2.3 测试

第一步：先关闭6380节点。发现，确实重新指定了一个主节点

第二步：再次上线6380节点。发现，6380节点成为了新的主节点的从节点

3.3 结论

Sentinel哨兵模式，确实能实现自动故障切换，提供稳定的服务。

3.4 注意事项

如果哨兵和redis节点不在同一台服务器上，注意IP绑定的问题。

（1）主从模型，所有的节点，使用ip绑定

（2）所有的哨兵，也都使用ip去绑定主机

（3）所有的哨兵，都是通过主节点的ip，去监控主从模型

3.5 哨兵模式的缺陷

在哨兵模式中，仍然只有一个Master节点。当并发写请求较大时，哨兵模式并不能缓解写压力。

我们知道只有主节点才具有写能力，那如果在一个集群中，能够配置多个主节点，是不是就可以缓解写压力了呢？

答：是的。这个就是redis-cluster集群模式

4 Redis-cluster集群

4.1 Redis-cluster集群概念

（1）由多个Redis服务器组成的分布式网络服务集群
（2）集群之中有多个Master主节点，每一个主节点都可读可写
（3）节点之间会互相通信，两两相连
（4）Redis集群无中心节点（去中心化）

--如下：

4.2 集群节点复制

在Redis-Cluster集群中，可以给每一个主节点添加从节点，主节点和从节点之间遵循主从模式的特性。

当用户需要处理更多读请求的时候，添加从节点可以扩展系统的读性能。

4.3 故障转移

Redis集群的主节点内置了类似Sentinel的节点故障检测和自动故障转移功能，当集群中的某个主节点下线时，集群中的其他在线主节点会注意到这一点，并对已下线的主节点进行故障转移。

集群进行故障转移的方法和Sentinel进行故障转移的方法基本一样，不同的是，在集群里面，故障转移是由集群中其他在线的主节点负责进行的，所以集群不必另外使用Sentinel。

4.4 集群分片策略

（1）Redis-cluster分片策略，是用来解决key存储位置的。
（2）集群将db0分为16384个槽位slot，所有key-value数据都存储在这些slot中的某一个上，一个slot可以存放多个数据。
（3）key的槽位计算公式为：slot_number=crc16(key)%16384，其中crc16为16位的循环冗余校验和函数。
（4）集群中的每个主节点都可以处理0个至16383个槽，当16384个槽都有某个节点在负责处理时，集群进入 上线状态，并开始处理客户端发送的数据命令请求。 （5）在集群的情况下不支持使用select命令来切换db，因为Redis集群模式下只有一个db0。

4.5 集群redirect转向

由于Redis集群无中心节点，请求会随机发给任意主节点。主节点只会处理自己负责槽位的命令请求，其它槽位的命令请求，该主节点会返回客户端一个转向错误。客户端根据错误中包含的地址和端口重新向正确的负责的主节点发起命令请求。

4.6 集群搭建

4.6.1 准备工作

第一步：安装ruby环境

redis集群管理工具redis-trib.rb依赖ruby环境，首先需要安装ruby环境：

yum -y install ruby
yum -y install rubygems

第二步：安装ruby和redis的接口程序

[1] 下载url： https://gems.ruby-china.com/gems/redis/versions（选择版本下载）
[2] 拷贝redis-3.0.0.gem至/opt/soft目录下
[3] 进入/opt/soft目录，执行安装指令
gem install redis-3.0.0.gem

4.6.2 集群规划

第一步：准备节点

[1] cluster集群最少需要6个节点，可以分布在一台或者多台主机上。
[2] 本文在一台主机上创建 伪分布式集群，不同的端口表示不同的redis节点，如下：
主节点：192.168.81.3:7001 192.168.81.3:7002 192.168.81.3:7003
从节点：192.168.81.3:7004 192.168.81.3:7005 192.168.81.3:7006

第二步：在/usr/local/redis下创建redis-cluster目录，其下创建7001、7002...7006目录，如下：

第三步：将redis解压路径下的配置文件redis.conf，依次拷贝到每个700X目录内，并修改每个700X目录下的redis.conf配置文件。

**拷贝命令：

[root@node1 redis-cluster]# cp /usr/redis/redis-3.2.9/redis.conf ./700 X

**配置信息：

--必选配置：
port 700 X （配置端口）
bind 192.168.81.3 （绑定IP地址）
protected-mode no（关闭保护模式，若不关闭，jedis连接会受到影响） cluster-enabled yes（开启cluster集群） --建议配置：
daemonize yes （后台模式）
logfile “/usr/local/redis/redis-cluster/700 X/node700 X.log” （日志信息输出到文件）

第四步：启动每个结点redis服务

依次进入700 X目录下，使用redis.conf，启动redis节点。
[root@node1 700 X]# redis-server redis.conf

说明：必须指定redis.conf文件，因为redis是根据配置文件启动的。

第五步：执行创建集群命令

进入到redis源码存放目录/usr/redis/redis-3.2.9/src下，执行 redis-trib.rb，此脚本是ruby脚本，它依赖ruby环境。

**进入目录命令：

[root@node1 ~]# cd /usr/redis/redis-3.2.9/src

**创建集群命令：

[root@node1 src]# ./redis-trib.rb create --replicas 1 192.168.81.3:7001 192.168.81.3:7002 192.168.81.3:7003 192.168.81.3:7004 192.168.81.3:7005 192.168.81.3:7006

**创建过程如下：

4.6.5 查询集群信息

集群创建成功登陆任意redis结点查询集群中的节点情况。

**登录redis客户端命令：

[root@node1 src]# ./redis-cli -c -h 192.168.81.3 -p 7001

**查看集群信息命令：

192.168.81.3:7001> cluster nodes

指令说明： ./redis-cli -c -h 192.168.56.3 -p 7001 ， 其中: -c表示以集群方式连接redis （cluster） -h指定ip地址 （host） -p指定端口号 （port） cluster nodes 查询集群结点信息。 cluster info 查询集群状态信息。

4.7 集群管理

4.7.1 添加主节点

4.7.1.1 节点规划

集群创建成功后可以向集群中添加节点，下面是添加一个Master：7007节点

第一步：添加7007新节点

[1] 在/usr/local/redis/redis-cluster目录下创建“7007目录”

[root@node1 redis-cluster]# mkdir 7007

[2] 拷贝/usr/redis/redis-3.2.9/redis.conf文件到7007目录中

[root@node1 redis-cluster]# cp /usr/redis/redis-3.2.9/redis.conf /usr/local/redis/redis-cluster/7007/redis.conf

[3] 配置redis.conf信息，如下：

必选配置：
port 7007 （配置端口）
bind 192.168.81.3 （绑定IP地址）
protected-mode no（关闭保护模式，若不关闭，jedis连接会受到影响）
cluster-enabled yes（开启cluster集群）
建议配置：
daemonize yes （后台模式）
logfile “/usr/local/redis/redis-cluster/7007/node7007.log” （日志信息输出到文件）

[4] 进入7007目录启动7004节点

[root@node1 7007]# redis-server redis.conf

第二步：添加节点到集群中

进入redis的源码目录（/usr/redis/redis-3.2.9/src/）使用命令：
[root@node1 src]# ./redis-trib.rb add-node 192.168.81.3:7007 192.168.81.3:7001

第三步：查看集群结点信息

**登录7001节点命令：
[root@node1 src]# ./redis-cli -c -h 192.168.81.3 -p 7001
**查看集群信息命令：
192.168.81.3:7001> cluster nodes

4.7.1.2 hash槽重新分配

添加完新的主节点后，需要对主节点进行hash槽分配，这样该主节才可以存储数据。
redis集群有16384个槽，被所有的主节点共同分配，通过查看集群结点可以看到槽占用情况。

**给刚添加的7007结点分配槽：

第一步：连接上集群（连接集群中任意一个可用节点都行）

[root@node1 src]# ./redis-trib.rb reshard 192.168.81.3:7001

第二步：输入要分配的槽数量

说明：输入 500表示要分配500个槽

第三步：输入接收槽的结点id

说明：这里准备给7007分配槽，通过cluster nodes查看7007结点id：9a95fa831de98deaa2f714f5943ed963a9600aa8
输入：9a95fa831de98deaa2f714f5943ed963a9600aa8

第四步：输入源结点id

说明：[1]这里从7001获取Slot，通过cluster nodes查看7001节点id：f2c3fa30487a5aa4e30082b406d2ae5acee4662。
[2] 指定分配的ID后，使用done结束。

**注意事项：

[1] 输入all，表示从其它主节点中分配。
[2] 分配后的Slot在源节点中就不存在了。 第五步：输入yes开始移动槽到目标结点id

4.7.2 添加从节点

集群创建成功后可以向集群中添加节点，下面是添加一个Slave。

说明：添加7008从结点，将7008作为7007的从结点。

第一步：添加7008节点，具体参考7007节点的添加步骤

第二步：执行命令添加从节点

**新增从节点命令格式： ./redis-trib.rb add-node --slave --master-id masterID newNodIP:port MasterIP:port 说明： masterID （主节点id，从cluster nodes信息中查看） newNodIP:port （新增节点的ip：端口） MasterIP:port （主节点的ip：端口）

**进入/usr/redis/redis-3.2.9/src/目录，执行如下命令：

[root@node1 src]# ./redis-trib.rb add-node --slave --master-id 9a95fa831de98deaa2f714f5943ed963a9600aa8 192.168.81.3:7008 192.168.81.3:7007

说明：9a95fa831de98deaa2f714f5943ed963a9600aa8 是7007结点的id，可通过cluster nodes查看。

**注意：如果原来该结点在集群中的配置信息已经生成cluster-config-file指定的配置文件中（如果cluster-config-file没有指定则默认为nodes.conf），这时可能会报错：

[ERR] Node XXXXXX is not empty. Either the node already knows other nodes (check with CLUSTER NODES) or contains some key in database 0

**解决方法：删除生成的配置文件nodes.conf，删除后再执行./redis-trib.rb add-node指令。

第三步：查看集群中的结点，刚添加的7008为7007的从节点

4.7.3 删除节点

删除节点命令格式：./redis-trib.rb del-node nodeIP:port nodeID 说明： nodeIP:port 待删除节点的ip:端口 nodeID 待删除节点的id，从cluster node中查看

**注意，删除已经占有hash槽的结点会失败，报错如下：

[ERR] Node 192.168.81.3:7005 is not empty! Reshard data away and try again.

因此需要将该结点占用的hash槽分配出去（参考hash槽重新分配章节）

第一步：将7007节点的Slot分配给7001（参考hash槽重新分配章节）

注意事项：设置完源节点后，需要done。

第二步：执行删除命令

[root@node1 src]# ./redis-trib.rb del-node 192.168.81.3:7007 9a95fa831de98deaa2f714f5943ed963a9600aa8

5 java程序连接redis集群

5.1 连接步骤

第一步：创建项目，导入Jedis依赖

    redis.clients
    jedis
    3.1.0

第二步：创建redis集群的客户端

@Test
public void testJedisCluster() {
    // [1] 创建JedisCluster客户端
    // 创建一个Set集合，用来封装redis节点的信息
    HashSet nodes = new HashSet<>();
    String host = "192.168.81.3";
    nodes.add(new HostAndPort(host, 7001));
    nodes.add(new HostAndPort(host, 7002));
    nodes.add(new HostAndPort(host, 7003));
    nodes.add(new HostAndPort(host, 7004));
    nodes.add(new HostAndPort(host, 7005));
    nodes.add(new HostAndPort(host, 7006));

    JedisCluster cluster = new JedisCluster(nodes);

    // [2] 操作集群
    cluster.set("user:id:1:username", "brick");
    cluster.set("user:id:1:address", "广东广州");
    String username = cluster.get("user:id:1:username");
    String address = cluster.get("user:id:1:address");
    System.out.println("username：" + username);
    System.out.println("address：" + address);
}

第三步：开启集群节点端口号（7001-7006）

连接Redis集群时，需要修改防火墙，开放每一个redis节点的端口。

如果要开放一个范围的端口，可以使用冒号来分割，即：7001:7008，表示开放7001-7008之间所有的端口

第四步：测试

访问Redis-cluster集群成功！！！