REDIS集群 -- 主从、哨兵和去中心化

一、REDIS的主从关系

二、如何搭建主从关系？

准备三台机器 （1 主节点   2 从节点） 为了节省资源 在一个虚拟机上启动三台redis 只是他们的端口号不同，

三、搭建主从的关系

配从不配主
（1）配置redis配置文件 6380(主)  6381（从）  6382（从）
（2）修改rdb持久化文件的路径以及端口

四、

分别设置端口号为80、81、82的三个redis

分别连接对应的redis服务，三个都连

用 info replication命令可以查看其主副

这时候三个服务器的角色均为master，然后用salveof IP 端口 命令修改角色，我们让6380端接口为主，6381和6382为辅：

这里6381的role已经变为salve,且可以看到其跟随6380接口，同理6382也是如此。

这里的6380已经有了个子链接。修改成功。通过测试我们知道 主节点可以负责读写操作，但是从节点只能负责读操作。

在这里需要思考一个问题：如果主节点（6380）宕机了，那么从节点会不会上位。还是等待老大的归来。[等待老大归来]

如果新增一个从节点，该从节点会从当前增加的不会添加数据还是会和所有节点数据同步？【同步】

通过测试，我们会发现主从关系的一个缺点：

如果主节点挂掉，则从节点无法上位，导致客户端无法进行写操作了。

四、搭建哨兵模式

如何设置哨兵模式？

这里为哨兵的配置文件：

修改配置文件：

启动哨兵：

让主节点6380宕机：

可以看到，节点6381已经上位成为主节点：

那当主节点6380重新启动之后，会不会恢复成为主节点？测试证明，已经上位的子节点6381不会让位，6380成为子节点。

五、Redis集群搭建--去中心化

从上边的测试可以看到，Redis传统集群都是基于主从复制+哨兵模式实现的，采用不同的主从复制策略(如一主多从、树状主从)搭建Redis集群实现高可用，使用哨兵模式来进行Redis主机宕机之后的投票选举，实现自动化故障发现和转移，从而更好地保护Redis集群，最大化保证集群高可用。

但是在传统Redis集群模式中，也存在一些问题：

1、浪费空间：一般都是使用一主多从或者树状主从的方式来搭建Redis集群的，始终只有一个Redis主机来接收和处理写请求，并且Redis主机和从机数据始终是保持完全同步的，随着业务复杂度升级，如果从机比较多的情况下，由于每个Redis从机本身的持久化机制，再加上Redis主机定时的数据同步，数据同步效率必然会降低，并且从机和主机数据始终是同步的，存在大量冗余数据，浪费内存空间，从而会对运行的Redis集群中的每个Redis服务器运行性能造成影响。

2、缓存雪崩，数据丢失：从上百年的根据主从复制的读写分离原则，主机只能负责写操作，传统Redis集群只有一个主机，如果是高并发请求的情况下，那么就会导致这个Redis主机写操作的压力非常大，同时还会加重同步数据到从机的负荷，并且Key也不能分摊到其他Redis主机，一旦出现缓存雪崩问题就会导致大量Key同时失效，丢失很多重要的数据。

去中心化集群运行简图

配置三对master和salve

1. 8001 8002 
2. 7001 7002
3. 9001 9002

修改对应虚拟机的redis的配置文件，需要修改内容如下：

port 8001
bind 0.0.0.0
daemonize yes
appendonly yes  必须有aof持久化 必须必须必须开启
# 开启集群
cluster-enabled yes             833行
# 集群的配置文件,该文件自动生成   
cluster-config-file nodes-8001.conf  841行
# 集群的超时时间
cluster-node-timeout 5000         847行

依次对8001--9002的配置文件进行修改。

使用redis-server redisxxxx.conf命令，启动redis服务：

为上面运行的redis分配主从关系和槽

-主节点后只有一个从节点

redis-cli --cluster create --cluster-replicas 1 192.168.223.128:7001 192.168.223.128:8001 192.168.223.128:9001  192.168.223.128:7002  192.168.223.128:8002 192.168.223.128:9002

必须保证AOF开启，保证redis中没有数据。

客户端访问测试：

redis-cli -c -h 127.0.0.1 -p 8001