Redis集群与实验

Redis集群

主从复制

主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多

机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷:故障恢复无法自动化;写操作无法负载均衡;存储能

力受到单机的限制。

哨兵

在主从复制的基础上，哨兵实现了自动化的故障恢复。

缺陷:写操作无法负载均衡;存储能力受到单机的限制;哨兵无法对从节点进行自动故障转移，在读写分离场景下，从

节点故障会导致读服务不可用，需要对从节点做额外的监控、切换操作。

Cluster集群

通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

Redis集群概述

Redis集群是一个提供在多个Redis间节点间共享数据的程序集

Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,丛而达不到像Redis那样的性能,在高

负载的情况下可能会导致不可预料的错误

Redis集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下可继续处理命令

主从复制的作用

数据冗余:主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

故障恢复:当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复:实际上是一种服务的冗余。

负载均衡:在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据

时应用连接主节点，读Redis数据时应用连接从节点)，分担服务器负载;尤其是在写少读多的场景下，通过多个从

节点分担读负载，可以大大提高Redis服务器的并发量。

高可用基石:除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制流程

(1）若启动一个slave机器进程，则它会向Master机器发送一个"sync command"命令，请求同步连接。

(2）无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照保存到数据文件中（执行

rdb操作），商时Master还会记录修改数据的所有命令并缓存在数据文件中。

(3）后台进程完成缓存操作之后，Master机器就会向slave机器发送数据文件，Slave端机器将数据文件保存到硬盘

上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给slave端机器。若Slave出现

故障导致宕机，则恢复正常后会自动重新连接。

(4) Master机器收到Sslave端机器的连接后，将其完整的数据文件发送给slave端机器，如果Mater同时收到多个

slave发来的同步请求，则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，

确保所有的slave端机器都正常。

哨兵模式

是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将

slave连接到新的master。所以整个运行哨兵的集群的数量不得少于三个节点。

哨兵模式的作用

监控：哨兵会不断地检查Redis数据库主节点和从节点是否正常运行

自动故障转移：当主节点不能正常工作时，哨兵会开始自动故障转移操作，他会将失效主节点的其中一个从节点升

级为主节点，并让其他从节点改为复制新的主节点

通知：哨兵可以将故障转移的结果发送给客户端

故障转移机制

1.由哨兵节点定期监控发现主节点是否出现了故障

每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。如果主节点在一定

时间范围内不回复或者是回复一个错误消息，那么这个哨兵就会认为这个主节点主观下线了(单方面的）。当超过

半数哨兵节点认为该主节点主观下线了，这样就客观下线了。

2.当主节点出现故障，此时哨兵节点会通过Raft算法（选举算法）实现选举机制共同选举出一个哨兵节点为

leader，来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。

3.由leader哨兵节点执行故障转移，过程如下:

●将某一个从节点升级为新的主节点，让其它从节点指向新的主节点;

●若原主节点恢复也变成从节点，并指向新的主节点;

●通知客户端主节点己经更换。

需要特别注意的是，客观下线是主节点才有的概念;如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再

有后续的客观下线和故障转移操作。

主节点的选举

1.过滤掉不健康的（已下线的），没有回复哨兵ping 响应的从节点。

2.选择配置文件中从节点优先级配置最高的。(replica-priority，默认值为100)

3.选择复制偏移量最大，也就是复制最完整的从节点。

哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式

Redis集群

集群是由多个节点组成，Redis的数据分布在这些节点中。集群的节点分为主节点和从节点：只有主节点负责读写

请求和集群信息的维护，从节点只进行主节点数据和状态信息的复制。

集群的作用

(1）数据分区:数据分区(或称数据分片)是集群最核心的功能。

集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加;另一方面每个主节点都

可以对外提供读服务和写服务，大大提高了集群的响应能力。

Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及;例如，如果单机内存太大，bgsave和

bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量

复制阶段主节点的复制缓中区可能溢出。

(2）高可用:集群支持主从复制和主节点的自动故障转移（与哨兵类似)﹔当任一节点发生故障时，集群仍然可以对

外提供服务。

Redis集群实验

1.创建节点服务器

[root@localhost redis-5.0.7]# cd /etc/redis
[root@localhost redis]# mkdir -p redis-cluster/redis600{1..6}
[root@localhost redis]# ls
6379.conf  redis-cluster
[root@localhost redis]# cd redis-cluster/
[root@localhost redis-cluster]# ls
redis6001  redis6002  redis6003  redis6004  redis6005  redis6006   #六个节点服务器
[root@localhost redis-cluster]# for i in {1..6}
> do
> cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
> cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
> done             #做一个for循环

2.修改各个节点服务器的配置文件，每个节点服务器除了端口号其他配置一样

[root@localhost redis6001]# cd /etc/redis/redis-cluster/redis6001
[root@localhost redis6001]# ls
redis-cli  redis.conf  redis-server
[root@localhost redis6001]# vim redis.con
  69 #bind 127.0.0.1
  88 protected-mode no
  92 port 6001     #端口号 每个配置都要修改
 136 daemonize yes
 832 cluster-enabled yes   #取消注释
 840 cluster-config-file nodes-6001.conf  #取消注释，修改端口号
 846 cluster-node-timeout 15000
 699 appendonly yes
修改完成，分别修改其他五个节点的配置文件
[root@localhost redis-cluster]# cd redis6002
[root@localhost redis6002]# ls
redis-cli  redis.conf  redis-server
[root@localhost redis6002]# vim redis.conf 
[root@localhost redis6002]# vim ../redis6003/redis.conf 
[root@localhost redis6002]# vim ../redis6004/redis.conf 
[root@localhost redis6002]# vim ../redis6005/redis.conf 
[root@localhost redis6002]# vim ../redis6006/redis.conf 

3.启动六个节点服务器

[root@localhost redis6001]# for d in {1..6}
> do
> cd /etc/redis/redis-cluster/redis600$d
> redis-server redis.conf
> done
启动完之后查看节点服务器端口状态，是否成功启动
[root@localhost redis6006]# ps -ef | grep redis
root      76571      1  0 00:13 ?        00:00:58 /usr/local/redis/bin/redis-server 127.0.0.1:6379
root      82393  79759  0 04:31 pts/0    00:00:00 redis-cli
root      90249      1  0 16:23 ?        00:00:00 redis-server *:6001 [cluster]
root      90251      1  0 16:23 ?        00:00:00 redis-server *:6002 [cluster]
root      90256      1  0 16:23 ?        00:00:00 redis-server *:6003 [cluster]
root      90262      1  0 16:23 ?        00:00:00 redis-server *:6004 [cluster]
root      90266      1  0 16:23 ?        00:00:00 redis-server *:6005 [cluster]
root      90274      1  0 16:23 ?        00:00:00 redis-server *:6006 [cluster]
root      90279  89943  0 16:23 pts/1    00:00:00 grep --color=auto redis

4.启动集群并测试

[root@localhost redis6006]# redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 127.0.0.1:6005 to 127.0.0.1:6001
Adding replica 127.0.0.1:6006 to 127.0.0.1:6002
Adding replica 127.0.0.1:6004 to 127.0.0.1:6003
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: d379c0aa3b3e8246a186a02199f03bb97f4b55ec 127.0.0.1:6001
   slots:[0-5460] (5461 slots) master
M: ddd86b675f82496c06bdcad11cfad2e260814fe8 127.0.0.1:6002
   slots:[5461-10922] (5462 slots) master
M: f6bff7e3af1357c84112b61bcd37e824544bb211 127.0.0.1:6003
   slots:[10923-16383] (5461 slots) master
S: 5ff375214b2ffbe99f1ff35822c09a334525a0bb 127.0.0.1:6004
   replicates d379c0aa3b3e8246a186a02199f03bb97f4b55ec
S: b4e38a1b4d00c4592007099c96fdc12904558a9d 127.0.0.1:6005
   replicates ddd86b675f82496c06bdcad11cfad2e260814fe8
S: f8f29f6ec7ac20333c753614b08ddc44b45093bf 127.0.0.1:6006
   replicates f6bff7e3af1357c84112b61bcd37e824544bb211
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.....
>>> Performing Cluster Check (using node 127.0.0.1:6001)
M: d379c0aa3b3e8246a186a02199f03bb97f4b55ec 127.0.0.1:6001
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
S: b4e38a1b4d00c4592007099c96fdc12904558a9d 127.0.0.1:6005
   slots: (0 slots) slave
   replicates ddd86b675f82496c06bdcad11cfad2e260814fe8
M: f6bff7e3af1357c84112b61bcd37e824544bb211 127.0.0.1:6003
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
S: f8f29f6ec7ac20333c753614b08ddc44b45093bf 127.0.0.1:6006
   slots: (0 slots) slave
   replicates f6bff7e3af1357c84112b61bcd37e824544bb211
M: ddd86b675f82496c06bdcad11cfad2e260814fe8 127.0.0.1:6002
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: 5ff375214b2ffbe99f1ff35822c09a334525a0bb 127.0.0.1:6004
   slots: (0 slots) slave
   replicates d379c0aa3b3e8246a186a02199f03bb97f4b55ec
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
测试集群
[root@localhost redis6006]# redis-cli -p 6001 -c
127.0.0.1:6001> cluster slots
1) 1) (integer) 0
   2) (integer) 5460
   3) 1) "127.0.0.1"
      2) (integer) 6001
      3) "d379c0aa3b3e8246a186a02199f03bb97f4b55ec"
   4) 1) "127.0.0.1"
      2) (integer) 6004
      3) "5ff375214b2ffbe99f1ff35822c09a334525a0bb"
2) 1) (integer) 10923
   2) (integer) 16383
   3) 1) "127.0.0.1"
      2) (integer) 6003
      3) "f6bff7e3af1357c84112b61bcd37e824544bb211"
   4) 1) "127.0.0.1"
      2) (integer) 6006
      3) "f8f29f6ec7ac20333c753614b08ddc44b45093bf"
3) 1) (integer) 5461
   2) (integer) 10922
   3) 1) "127.0.0.1"
      2) (integer) 6002
      3) "ddd86b675f82496c06bdcad11cfad2e260814fe8"
   4) 1) "127.0.0.1"
      2) (integer) 6005
      3) "b4e38a1b4d00c4592007099c96fdc12904558a9d"
集群已经成功创建