Redis的集群

Posted 2022-06-28 406070989senlin

集群的概念

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

 使用redis集群的必要性

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

答：（1）单个redis存在不稳定性。当redis服务宕机了，就没有可用的服务了。

（2）单个redis的读写能力是有限的。

 

总结：redis集群是为了强化redis的读写能力。

如何学习redis集群

--说明：（1）redis集群中，每一个redis称之为一个节点。

  （2）redis集群中，有两种类型的节点：主节点(master)、从节点(slave)。

 （3）redis集群，是基于redis主从复制实现。

 

所以，学习redis集群，就是从学习redis主从复制模型开始的。

 

 

 

 redis主从复制

概念

 主从复制模型中，有多个redis节点。

 其中，有且仅有一个为主节点Master。从节点Slave可以有多个。

 

只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。

 

特点

（1）主节点Master可读、可写.

（2）从节点Slave只读。（read-only）

 

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

 

 基于配置实现

 

 需求

 

主节点	6380
从节点（两个）	6381、6382

 

 

 

 配置步骤

 

（1）在/usr/local目录下，创建一个/redis/master-slave目录

 

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

 

 

 

（2）在master-slave目录下，创建三个子目录6380、6381、6382

 

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

 

 

 

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

 

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

 

 

 

（4）进入6380目录，修改redis.conf，将port端口修改成6380即可。

 

[root@node0719 master-slave]# cd ./6380 [root@node0719 6380]# vim redis.conf

 

 

（5）进入6381目录，修改redis.conf，将port端口改成6381，同时指定开启主从复制。

[root@node0719 6380]# cd ../6381 [root@node0719 6381]# vim redis.conf

 

（6）进入6382目录，修改redis.conf，将port端口改成6382，同时指定开启主从复制。

[root@node0719 6380]# cd ../6382 [root@node0719 6381]# vim redis.conf

 

测试

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

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

 

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

 

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

 

 

 

（2）另外再打开三个xshell窗口，在每一个窗口中，登陆一个redis节点

[root@node0719 ~]# redis-cli -p 6380

 

[root@node0719 ~]# redis-cli -p 6381

 

[root@node0719 ~]# redis-cli -p 6382

 

（3）在主节点6380上，进行读写操作，操作成功

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

 

（4）在从节点6381上

读操作执行成功，并且成功从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.

 

 Sentinel哨兵模式

 主从模式的缺陷

当主节点宕机了，整个集群就没有可写的节点了。

 

由于从节点上备份了主节点的所有数据，那在主节点宕机的情况下，如果能够将从节点变成一个主节点，是不是就可以解决这个问题了呢？

 

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

 

 哨兵的任务

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会进行选举，将其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

 

监控（Monitoring）

（1）Sentinel可以监控任意多个Master和该Master下的Slaves。（即多个主从模式）

（2）同一个哨兵下的、不同主从模型，彼此之间相互独立。

（3）Sentinel会不断检查Master和Slaves是否正常。

 

自动故障切换（Automatic failover）

 Sentinel网络

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

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

答：当只有一个sentinel的时候，如果这个sentinel挂掉了，那么就无法实现自动故障切换了。

 

在sentinel网络中，只要还有一个sentinel活着，就可以实现故障切换。

 

故障切换的过程

（1）投票（半数原则）

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

 

（2）选举

当Sentinel确定Master下线后，会在所有的Slaves中，选举一个新的节点，升级成Master节点。

其它Slaves节点，转为该节点的从节点。

（1）投票                              （2）选举

 

（3）原Master重新上线

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

（3）原master重新上线

 

 哨兵模式部署

 需求

前提：已经存在一个正在运行的主从模式。

 

另外，配置三个Sentinel实例，监控同一个Master节点。

 

 配置Sentinel

（1）在/usr/local目录下，创建/redis/sentinels/目录

[root@node0719 local]# mkdir -p redis/sentinels

 

（2）在/sentinels目录下，以次创建s1、s2、s3三个子目录中

[root@node0719 sentinels]# mkdir s1 s2 s3

 

（3）依次拷贝redis解压目录下的sentinel.conf文件，到这三个子目录中

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

 

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

 

S1哨兵配置如下：

 

S2哨兵配置如下：

 

S3哨兵配置如下：

 

（5）再打开三个xshell窗口，在每一个窗口中，启动一个哨兵实例，并观察日志输出

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

 

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

 

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

 

核心日志输出：

 

1.1.3 测试

（1）先关闭6380节点。发现，确实重新指定了一个主节点

 

（2）再次上线6380节点。发现，6380节点成为了新的主节点的从节点。

 

结论 

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

 

注意事项

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

 

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

 

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

 

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