Redis集群的关闭与重启操作
更新时间：2021年07月07日 11:36:11 作者：郝少
这篇文章主要介绍了Redis集群的关闭与重启操作，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
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都宕机了，那么该集群就无法再提供服务了。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。
相关文章
本文将详细分析Redis的数据恢复机制,持久化策略及其特点,并讨论选择持久化策略时需要考虑的因素,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2024-06-06
这篇文章主要介绍了Redis如何一键部署脚本，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2021-04-04
本文主要是基于 redis 6.2 源码进行分析定时事件的数据结构和常见操作，文中通过示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2022-03-03
本文主要介绍了缓存问题及其解决方案,包括缓存穿透、缓存击穿、缓存雪崩等问题的成因以及相应的预防和解决方法,同时,还详细探讨了缓存更新机制,包括不同情况下的缓存更新策略和内存淘汰机制,并对比了它们的优缺点2025-01-01
这篇文章主要重点介绍了Redis的LRU与LFU算法实现，并分析总结了两种算法的实现效果以及存在的问题，并阐述其优劣特性，感兴趣的小伙伴跟着小编一起来看看吧2023-07-07
此篇文章主要对Redis的5种基本数据类型，即字符串(String)、列表(List)、散列(Hash)、集合(Set)、有序集合(Sorted Set)，从使用场景和底层结构出发，进行多维度深入分析。对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下2021-11-11
这篇文章主要为大家介绍了小白也能看懂的Redis遍历键和数据库管理详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪2022-10-10
这篇文章主要介绍了Redis结合SpringBoot的秒杀案例,本文通过实例代码给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下2021-09-09
因为redis数据是基于内存的,然而内存是非常宝贵的资源,然后我们就会对一些不常用或者只用一次的数据进行存活时间设置,这样才能提高内存的使用效率,下面这篇文章主要给大家介绍了关于Redis中过期键与内存淘汰策略,需要的朋友可以参考下2022-11-11
Redis集群是Redis官方推出的分布式解决方案,它允许将数据分布在多个Redis节点中,从而提高Redis的性能和可扩展性,本文给大家介绍了Redis集群部署的过程步骤,需要的朋友可以参考下2024-06-06
最新评论