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主从复制模型开始的。

1           redis主从复制

1.1        概念

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

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

 

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

 

 

1.1        特点

(1)主节点Master可读、可写.

(2)从节点Slave只读。(read-only)

 

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

 

1.1        基于配置实现

1.1.1       需求

主节点

6380

从节点(两个)

6381、6382

 

1.1.2       配置步骤

(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.1.1       测试

(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.

 

 

1           Sentinel哨兵模式

1.1        主从模式的缺陷

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

 

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

 

答:是的,这个就是Sentinel哨兵的作用。

 

1.2        哨兵的任务

Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务:

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

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

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

 

1.2.1       监控(Monitoring)

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

(2)同一个哨兵下的、不同主从模型,彼此之间相互独立。

(3)Sentinel会不断检查Master和Slaves是否正常。

 

 

 

1.2.2       自动故障切换(Automatic failover)

1.2.2.1    Sentinel网络

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

 

 

疑问:为什么要使用sentinel网络呢?

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

 

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

1.1.1.1    故障切换的过程

(1)投票(半数原则)

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

 

(2)选举

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

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

  

 

 

 

         (1)投票                                                                            (2)选举

 

(3)原Master重新上线

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

 

 

(3)原master重新上线

1.1        哨兵模式部署

1.1.1       需求

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

 

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

 

1.1.2       配置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节点成为了新的主节点的从节点。

 

 

 

1.2        结论

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

posted @ 2019-07-15 22:56  vietaKo  阅读(80631)  评论(6编辑  收藏  举报