欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

Redis集群的关闭与重启操作

程序员文章站 2022-04-12 22:53:29
redis集群关闭与重启1、注意[root@master bin]# ./redis-cli --cluster create 192.168.230.21:7001 192.168.230.21:7...

redis集群关闭与重启

1、注意

[root@master bin]# ./redis-cli --cluster create 192.168.230.21:7001 192.168.230.21:7002 192.168.230.21:7003 192.168.230.21:8001 192.168.230.21:8002 192.168.230.21:8003 --cluster-replicas 1 -a 123456

上面的命令只能在新创健集群的时候执行一次,目的是为了建立内部各个节点的对应关系,比如主从关系,这些关系仅且只能在一个集群中初始化时对应一次;

如果再此执行,则会出现如下错误:

[root@master bin]# ./redis-cli --cluster create 192.168.230.21:7001 192.168.230.21:7002 192.168.230.21:7003 192.168.230.21:8001 192.168.230.21:8002 192.168.230.21:8003 --cluster-replicas 1 -a 123456
warning: using a password with '-a' or '-u' option on the command line interface may not be safe.
[err] node 192.168.230.21:7001 is not empty. either the node already knows other nodes (check with cluster nodes) or contains some key in database 0.

2、集群关闭

集群关闭直接将各个节点的进程kill掉即可;

[root@master bin]# ps -ef | grep redis
root      11516      1  0 16:15 ?        00:00:10 ./redis-server 192.168.230.21:7002 [cluster]
root      11521      1  0 16:15 ?        00:00:09 ./redis-server 192.168.230.21:7003 [cluster]
root      11526      1  0 16:15 ?        00:00:10 ./redis-server 192.168.230.21:8001 [cluster]
root      11531      1  0 16:15 ?        00:00:10 ./redis-server 192.168.230.21:8002 [cluster]
root      11536      1  0 16:15 ?        00:00:10 ./redis-server 192.168.230.21:8003 [cluster]
root      11869      1  0 16:33 ?        00:00:07 ./redis-server 192.168.230.21:7001 [cluster]
root      12528   9737  0 17:39 pts/7    00:00:00 grep --color=auto redis
[root@master bin]# kill -9 11516
[root@master bin]# kill -9 11521
[root@master bin]# kill -9 11526
[root@master bin]# kill -9 11531
[root@master bin]# kill -9 11536
[root@master bin]# kill -9 11869
[root@master bin]# ps -ef | grep redis
root      12552   9737  0 17:40 pts/7    00:00:00 grep --color=auto redis

3、集群开启及连接

(1)集群开启

[root@master bin]# ./redis-server /opt/software/redis-cluster/redis01/redis.conf 
12553:c 31 mar 2020 17:40:59.875 # oo0ooo0ooo0oo redis is starting oo0ooo0ooo0oo
12553:c 31 mar 2020 17:40:59.875 # redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=12553, just started
12553:c 31 mar 2020 17:40:59.875 # configuration loaded
[root@master bin]# ./redis-server /opt/software/redis-cluster/redis02/redis.conf 
12558:c 31 mar 2020 17:41:03.697 # oo0ooo0ooo0oo redis is starting oo0ooo0ooo0oo
12558:c 31 mar 2020 17:41:03.697 # redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=12558, just started
12558:c 31 mar 2020 17:41:03.697 # configuration loaded
[root@master bin]# ./redis-server /opt/software/redis-cluster/redis03/redis.conf 
12563:c 31 mar 2020 17:41:06.702 # oo0ooo0ooo0oo redis is starting oo0ooo0ooo0oo
12563:c 31 mar 2020 17:41:06.702 # redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=12563, just started
12563:c 31 mar 2020 17:41:06.702 # configuration loaded
[root@master bin]# ./redis-server /opt/software/redis-cluster/redis04/redis.conf 
12568:c 31 mar 2020 17:41:09.742 # oo0ooo0ooo0oo redis is starting oo0ooo0ooo0oo
12568:c 31 mar 2020 17:41:09.742 # redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=12568, just started
12568:c 31 mar 2020 17:41:09.742 # configuration loaded
[root@master bin]# ./redis-server /opt/software/redis-cluster/redis05/redis.conf 
12574:c 31 mar 2020 17:41:12.760 # oo0ooo0ooo0oo redis is starting oo0ooo0ooo0oo
12574:c 31 mar 2020 17:41:12.760 # redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=12574, just started
12574:c 31 mar 2020 17:41:12.760 # configuration loaded
[root@master bin]# ./redis-server /opt/software/redis-cluster/redis06/redis.conf 
12580:c 31 mar 2020 17:41:16.406 # oo0ooo0ooo0oo redis is starting oo0ooo0ooo0oo
12580:c 31 mar 2020 17:41:16.406 # redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=12580, just started
12580:c 31 mar 2020 17:41:16.406 # configuration loaded
[root@master bin]# ps -ef | grep redis
root      12554      1  0 17:40 ?        00:00:00 ./redis-server 192.168.230.21:7001 [cluster]
root      12559      1  0 17:41 ?        00:00:00 ./redis-server 192.168.230.21:7002 [cluster]
root      12564      1  0 17:41 ?        00:00:00 ./redis-server 192.168.230.21:7003 [cluster]
root      12569      1  0 17:41 ?        00:00:00 ./redis-server 192.168.230.21:8001 [cluster]
root      12575      1  0 17:41 ?        00:00:00 ./redis-server 192.168.230.21:8002 [cluster]
root      12581      1  0 17:41 ?        00:00:00 ./redis-server 192.168.230.21:8003 [cluster]
root      12587   9737  0 17:41 pts/7    00:00:00 grep --color=auto redis

(2)集群连接

[root@master bin]# ./redis-cli -p 7001 -a 123456 -h 192.168.230.21 -a 123456 -c
warning: using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.230.21:7001> dbsize
(integer) 2
192.168.230.21:7001> keys *
1) "aa"
2) "ss"
192.168.230.21:7001> set str str
-> redirected to slot [6928] located at 192.168.230.21:7002
ok
192.168.230.21:7002>

redis的三种集群方式

redis有三种集群方式:主从复制,哨兵模式和集群。

1.主从复制

主从复制原理:

  • 从服务器连接主服务器,发送sync命令;
  • 主服务器接收到sync命名后,开始执行bgsave命令生成rdb文件并使用缓冲区记录此后执行的所有写命令;
  • 主服务器bgsave执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令;
  • 从服务器收到快照文件后丢弃所有旧数据,载入收到的快照;
  • 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;
  • 从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;(从服务器初始化完成)
  • 主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令(从服务器初始化完成后的操作)

主从复制优缺点:

优点:

  • 支持主从复制,主机会自动将数据同步到从机,可以进行读写分离
  • 为了分载master的读操作压力,slave服务器可以为客户端提供只读操作的服务,写服务仍然必须由master来完成
  • slave同样可以接受其它slaves的连接和同步请求,这样可以有效的分载master的同步压力。
  • master server是以非阻塞的方式为slaves提供服务。所以在master-slave同步期间,客户端仍然可以提交查询或修改请求。
  • slave server同样是以非阻塞的方式完成数据同步。在同步期间,如果有客户端提交查询请求,redis则返回同步之前的数据

缺点:

  • redis不具备自动容错和恢复功能,主机从机的宕机都会导致前端部分读写请求失败,需要等待机器重启或者手动切换前端的ip才能恢复。
  • 主机宕机,宕机前有部分数据未能及时同步到从机,切换ip后还会引入数据不一致的问题,降低了系统的可用性。
  • redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。

2.哨兵模式

当主服务器中断服务后,可以将一个从服务器升级为主服务器,以便继续提供服务,但是这个过程需要人工手动来操作。 为此,redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的作用就是监控redis系统的运行状况。它的功能包括以下两个。

(1)监控主服务器和从服务器是否正常运行。

(2)主服务器出现故障时自动将从服务器转换为主服务器。

哨兵的工作方式:

  • 每个sentinel(哨兵)进程以每秒钟一次的频率向整个集群中的master主服务器,slave从服务器以及其他sentinel(哨兵)进程发送一个 ping 命令。
  • 如果一个实例(instance)距离最后一次有效回复 ping 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 sentinel(哨兵)进程标记为主观下线(sdown)
  • 如果一个master主服务器被标记为主观下线(sdown),则正在监视这个master主服务器的所有 sentinel(哨兵)进程要以每秒一次的频率确认master主服务器的确进入了主观下线状态
  • 当有足够数量的 sentinel(哨兵)进程(大于等于配置文件指定的值)在指定的时间范围内确认master主服务器进入了主观下线状态(sdown), 则master主服务器会被标记为客观下线(odown)
  • 在一般情况下, 每个 sentinel(哨兵)进程会以每 10 秒一次的频率向集群中的所有master主服务器、slave从服务器发送 info 命令。
  • 当master主服务器被 sentinel(哨兵)进程标记为客观下线(odown)时,sentinel(哨兵)进程向下线的 master主服务器的所有 slave从服务器发送 info 命令的频率会从 10 秒一次改为每秒一次。
  • 若没有足够数量的 sentinel(哨兵)进程同意 master主服务器下线, master主服务器的客观下线状态就会被移除。若 master主服务器重新向 sentinel(哨兵)进程发送 ping 命令返回有效回复,master主服务器的主观下线状态就会被移除。

哨兵模式的优缺点

优点:

  • 哨兵模式是基于主从模式的,所有主从的优点,哨兵模式都具有。
  • 主从可以自动切换,系统更健壮,可用性更高。

缺点:

  • redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。

3.redis-cluster集群

redis的哨兵模式基本已经可以实现高可用,读写分离 ,但是在这种模式下每台redis服务器都存储相同的数据,很浪费内存,所以在redis3.0上加入了cluster模式,实现的redis的分布式存储,也就是说每台redis节点上存储不同的内容。

redis-cluster采用无中心结构,它的特点如下:

  • 所有的redis节点彼此互联(ping-pong机制),内部使用二进制协议优化传输速度和带宽。
  • 节点的fail是通过集群中超过半数的节点检测失效时才生效。
  • 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

工作方式:

在redis的每一个节点上,都有这么两个东西,一个是插槽(slot),它的的取值范围是:0-16383。还有一个就是cluster,可以理解为是一个集群管理的插件。当我们的存取的key到达的时候,redis会根据crc16的算法得出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,通过这个值,去找到对应的插槽所对应的节点,然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用,redis-cluster集群引入了主从模式,一个主节点对应一个或者多个从节点,当主节点宕机的时候,就会启用从节点。当其它主节点ping一个主节点a时,如果半数以上的主节点与a通信超时,那么认为主节点a宕机了。如果主节点a和它的从节点a1都宕机了,那么该集群就无法再提供服务了。

以上为个人经验,希望能给大家一个参考,也希望大家多多支持。