Redis 集群的三种方案

一、主从复制（手动）

环境准备

数据库ip	数据库端口	数据库角色
127.0.0.1	6379	master
127.0.0.1	6380	slave(slaveof 127.0.0.1 6379)
127.0.0.1	6381	slave(slaveof 127.0.0.1 6379)

# 配置主从
slaveof 127.0.0.1 6379
# 去掉主从
slaveof no one
# 主从状态信息查看
info replication

1. 配置前

启动好三个redis，端口分别为6379，6380,6381。

6379：

6380：

6381：

2.配置从机（配从不配主）

特点：

（1）主节点Master可读、可写.

（2）从节点Slave只读。（read-only）

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

配置6380

配置6381

查看master （6379），插入一些数据

到从机查看数据是否得到同步，查看到数据已经由master同步到两台slave

优点：主写，从读，降低读的压力

缺点：Master的写的压力难以降低（只能在master写，slave为只读模式）；主节点宕机，无法继续使用；从节点失去连接需要手动重连

优点：

一个Master可以同步多个Slaves

Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构

Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求

Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高

Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作

支持主从复制，主机会自动将数据同步到从机，可以进行读写分离

 缺点：

Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复

主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性

Redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦

Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费

二、哨兵模式（Sentinel）

（哨兵）可以自动检测主库是否故障，如果主库发生故障，则通过投票从剩余的正常机器中选取一台机器作为主库。

Redis Sentinel是Redis高可用的实现方案。Sentinel是一个管理多个Redis实例的工具，它可以实现对Redis的监控、通知、自动故障转移。

Sentinel的主要功能包括主节点存活检测、主从运行情况检测、自动故障转移（failover）、主从切换。Redis的Sentinel最小配置是一主一从。 Redis的Sentinel系统可以用来管理多个Redis服务器，该系统可以执行以下四个任务：

监控（Monitoring）

Sentinel会不断的检查主服务器和从服务器是否正常运行。
提醒（Notification）

当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）

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

在Redis Sentinel模式下，客户端应用在初始化时连接的是Sentinel节点集合，从中获取主节点的信息。

哨兵模式实践

环境准备

数据库ip	数据库端口	数据库角色
127.0.0.1	6379	master
127.0.0.1	6380	slave(slaveof 127.0.0.1 6379)
127.0.0.1	6381	slave(slaveof 127.0.0.1 6379)

(1) 新增一个名为sentinel.conf 的文件，并写入如下配置

sentinel monitor redis-master 127.0.0.1 6379 1

Sentinel 监视一个被命名为 redis-master 的 master，可指定为任何名字
Master IP为127.0.0.1 ，端口号为 6379 ，
这个master判断为失效至少需要 1 个 Sentinel 同意（只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）
注意: 无论你设置多少个 Sentinel 同意才能判断一个服务器失效，一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持，才能发起一次自动故障迁移

(2) 启动哨兵

./redis-sentinel sentinel.conf

(3) 关闭master查看自动切换master

哨兵发现异常，开始投票选举

最终选举了6381作为master，sentinel.conf 里面的配置也被修改了

6381：

6380：

(4) 原来的master 6379回来之后，只能当slave

其他配置

sentinel down-after-milliseconds mymaster 30000
down-after-milliseconds 指定了 Sentinel 认为master已经断线所需的毫秒数

sentinel parallel-syncs mymaster 1
parallel-syncs 指定了在执行故障转移时，最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成故障转移所需的时间就越长

sentinel failover-timeout mymaster 180000
failover-timeout 指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟

启动sentinel
# ./redis-sentinel sentinel.conf

查看状态
# redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=-redis-master,status=ok,address=127.0.0.1:6380,slaves=1,sentinels=1

至此，配置sentinel工作完成

Sentinel 相关命令
• INFO sentinel的基本状态信息
• PING ：返回 PONG
• SENTINEL masters ：列出所有被监视的master，以及这些master的当前状态
• SENTINEL slaves <master name> ：列出给定master的所有slave服务器，以及这些slave的当前状态
• SENTINEL get-master-addr-by-name <master name> ：返回给定名字的master的 IP 地址和端口号。如果这个master正在执行故障转移操作，或者针对这个master的故障转移操作已经完成，那么这个命令返回新的master的 IP 地址和端口号。
• SENTINEL reset <pattern> ：重置所有名字和给定模式 pattern 相匹配的master。 pattern 参数是一个 Glob 风格的模式。重置操作清除master目前的所有状态，包括正在执行中的故障转移，并移除目前已经发现和关联的，master的所有slave和 Sentinel
• SENTINEL failover <master name> ：当master失效时，在不询问其他 Sentinel 意见的情况下，强制开始一次自动故障迁移（不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。

三、集群（Cluster）

1. redis集群简介

Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。

redis集群结构特点：

所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
redis-cluster把所有的物理节点映射到[0-16383]slot上（不一定是平均分配）,cluster 负责维护node<->slot<->value。
Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中。

（1）redis cluster节点分配:
现在我们是三个主节点分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：

节点A覆盖0－5460;
节点B覆盖5461－10922;
节点C覆盖10923－16383.

新增一个节点D，redis cluster的这种做法是从各个节点的前面各拿取一部分slot到D上。大致就会变成这样：

节点A覆盖1365-5460
节点B覆盖6827-10922
节点C覆盖12288-16383
节点D覆盖0-1364,5461-6826,10923-12287

同样删除一个节点也是类似，移动完成后就可以删除这个节点了。

（2）Redis Cluster主从模式：
redis cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉

上面那个例子里, 集群有ABC三个主节点, 如果这3个节点都没有加入从节点，如果B挂掉了，我们就无法访问整个集群了。A和C的slot也无法访问。

所以我们在集群建立的时候，一定要为每个主节点都添加了从节点, 比如像这样, 集群包含主节点A、B、C, 以及从节点A1、B1、C1, 那么即使B挂掉系统也可以继续正确工作。

B1节点替代了B节点，所以Redis集群将会选择B1节点作为新的主节点，集群将会继续正确地提供服务。当B重新开启后，它就会变成B1的从节点。

不过需要注意，如果节点B和B1同时挂了，Redis集群就无法继续正确地提供服务了。

2. redis集群部署

（1）处理配置文件

在redis-cluster下，复制redis.conf配置文件，分别命名为redis_6079.conf、redis_6080.conf、redis_6081.conf，修改配置文件内容如下：

daemonize yes  #后台启动
port 6379 #修改端口号，分别为6379,6380,6381
appendonly yes #持久化方式

pidfile "/var/run/redis_6379.pid"
logfile redis_6379.log
dbfilename "dump_6379.rdb"
appendfilename "appendonly_6379.aof"


cluster-enabled yes #开启cluster
cluster-config-file nodes-6380.conf
cluster-node-timeout 15000  #节点通信时间
cluster-slave-validity-factor 10
cluster-migration-barrier 1
cluster-require-full-coverage yes

（2）启动所有的redis节点
可以写一个命令脚本startup-redis-cluster.sh

./redis-server redis_6379.conf
./redis-server redis_6380.conf
./redis-server redis_6381.conf
./redis-server redis_6382.conf
./redis-server redis_6383.conf
./redis-server redis_6384.conf

（3）启动所有redis

sh startup-redis-cluster.sh

（4）创建集群

./redis-cli --cluster create --cluster-replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384

（5）查看集群状态