一、Redis哨兵模式搭建

1.1 Redis 的主从复制模式和 Sentinel 高可用架构的示意图

redis主从复制及sentinel高可用架构图

1.2 基于Docker换件搭建Redis哨兵模式

本次搭建Redis哨兵模式仅为测试使用，且因资源有限，在一台云主机上安装docker引擎，通过docker容器搭建哨兵模式。

1.2.1 安装环境

云主机配置：1核2G

所需软件及环境：docker， docker-compose， redis镜像

1.2.2 Redis主从复制

创建docker-compose.yml配置文件：

docker-compose.yml

version: '3'
services:
  master:
    image: redis
    container_name: redis-master
    command: redis-server --requirepass redis_hyk  --masterauth redis_hyk
    ports:
      - 6379:6379
  slave1:
    image: redis
    container_name: redis-slave-1
    ports:
      - 6380:6379
    command:  redis-server --slaveof 172.16.16.37 6379 --requirepass redis_hyk --masterauth redis_hyk --replica-announce-ip 172.16.16.37 --replica-announce-port 6380
  slave2:
    image: redis
    container_name: redis-slave-2
    ports:
      - 6381:6379
    command: redis-server --slaveof 172.16.16.37 6379 --requirepass redis_hyk --masterauth redis_hyk --replica-announce-ip 172.16.16.37 --replica-announce-port 6381

注意：使用dockers容器配置主从时，slave节点默认使用的时容器内部的ip，会导致在容器外部无法访问，可以通过以下配置指定ip及端口
详情参考：Redis官网 Replication
replica-announce-ip 172.16.16.37
replica-announce-port 6380

执行docker-compose up -d 启动容器。

1.2.3 Redis Sentinel

创建docker-compose.yml配置文件：

docker-compose.yml

version: '3'
services:
  sentinel1:
    image: redis
    container_name: redis-sentinel-1
    ports:
      - 26379:26379
    command: redis-sentinel /usr/local/etc/redis/sentinel.conf
    volumes:
      - ./sentinel1.conf:/usr/local/etc/redis/sentinel.conf
      - ./26379/:/usr/local/etc/redis/
  sentinel2:
    image: redis
    container_name: redis-sentinel-2
    ports:
    - 26380:26379
    command: redis-sentinel /usr/local/etc/redis/sentinel.conf
    volumes:
      - ./sentinel2.conf:/usr/local/etc/redis/sentinel.conf
      - ./26380/:/usr/local/etc/redis/
  sentinel3:
    image: redis
    container_name: redis-sentinel-3
    ports:
      - 26381:26379
    command: redis-sentinel /usr/local/etc/redis/sentinel.conf
    volumes:
      - ./sentinel3.conf:/usr/local/etc/redis/sentinel.conf
      - ./26381:/usr/local/etc/redis/
networks:
  default:
    external:
      name: redis_default

挂载Sentinel配置文件：

sentinel1.conf

port 26379
dir /tmp
# 172.18.0.3是redis的主节点ip
# 指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 172.18.0.3 （docker inspect [containerIP]可以获取） 端口号为 6379
# 将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）
sentinel monitor mymaster 172.18.0.3 6379 2
#
sentinel auth-pass mymaster redis_pwd
# 指定了 Sentinel 认为服务器已经断线所需的毫秒数。
sentinel down-after-milliseconds mymaster 30000
# 指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步，
# 这个数字越小， 完成故障转移所需的时间就越长。
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes

PS:由于sentinel启动会对sentinel.conf文件做修改，我们启动了3个sentinel节点，所以配置文件需要复制3份分别对应每一个节点

执行docker-compose up -d 启动容器。

1.2.4 验证

查看docker容器状态：

查看Reids Master节点状态：

查看sentinel节点状态：

sentinel节点状态2

1.3 Redis哨兵模式故障转移测试

1.3.1 新建SpringBoot项目连接到Redis

创建一个SpringBoot项目，添加Redis依赖：

   <dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.commons</groupId>
	<artifactId>commons-pool2</artifactId>
</dependency>

配置Redis

spring:
  redis:
    password: redis_hyk
    sentinel:
      master: mymaster
      nodes: 172.16.16.37:26379,172.16.16.37:26380,172.16.16.37:26381

在SpringBoot项目中持续进行写入操作

@Component
public class RedisService {

    @Autowired
    private RedisTemplate<String, String> stringRedisTemplate;

    @PostConstruct
    public void writeRedis() {
        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss SSS");
        while(true) {
            try {
                String time = ZonedDateTime.now().format(formatter);
                stringRedisTemplate.opsForValue().set("master-failover", time);
                Thread.sleep(1000);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
}

停止掉Redis的Master节点

docker container stop 881

SpringBoot项目日志输入

20:02:59.584  INFO 15128 --- [xecutorLoop-1-3] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was /172.16.16.37:6379
20:03:01.657  WARN 15128 --- [ioEventLoop-4-4] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [172.16.16.37:6379]: Connection refused: no further information: /172.16.16.37:6379
20:03:05.957  INFO 15128 --- [xecutorLoop-1-2] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 172.16.16.37:6379
20:03:07.997  WARN 15128 --- [ioEventLoop-4-2] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [172.16.16.37:6379]: Connection refused: no further information: /172.16.16.37:6379
20:03:12.464  INFO 15128 --- [xecutorLoop-1-4] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 172.16.16.37:6379
20:03:14.517  WARN 15128 --- [ioEventLoop-4-4] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [172.16.16.37:6379]: Connection refused: no further information: /172.16.16.37:6379
20:03:19.659  INFO 15128 --- [xecutorLoop-1-2] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 172.16.16.37:6379
20:03:21.714  WARN 15128 --- [ioEventLoop-4-2] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [172.16.16.37:6379]: Connection refused: no further information: /172.16.16.37:6379
20:03:26.961  INFO 15128 --- [xecutorLoop-1-2] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 172.16.16.37:6379
20:03:29.030  WARN 15128 --- [ioEventLoop-4-2] i.l.core.protocol.ConnectionWatchdog     : Cannot reconnect to [172.16.16.37:6379]: Connection refused: no further information: /172.16.16.37:6379
20:03:33.167  INFO 15128 --- [xecutorLoop-1-4] i.l.core.protocol.ConnectionWatchdog     : Reconnecting, last destination was 172.16.16.37:6379
20:03:33.184  INFO 15128 --- [ioEventLoop-4-4] i.l.core.protocol.ReconnectionHandler    : Reconnected to 172.16.16.37:6381

Sentinel节点日志输出

04:01:34.181 # +sdown master mymaster 172.16.16.37 6379
04:01:34.309 # +new-epoch 1
04:01:34.325 # +vote-for-leader a1d392603fe93637b2194b0f67f38cf1946efdc2 1
04:01:35.280 # +odown master mymaster 172.16.16.37 6379 #quorum 3/2
04:01:35.281 # Next failover delay: I will not start a failover before 04:07:35 2021
04:01:35.449 # +config-update-from sentinel a1d392603fe93637b2194b0f67f38cf1946efdc2 172.16.16.37 26380 @ mymaster 172.16.16.37 6379
04:01:35.449 # +switch-master mymaster 172.16.16.37 6379 172.16.16.37 6381
04:01:35.449 * +slave slave 172.16.16.37:6380 172.16.16.37 6380 @ mymaster 172.16.16.37 6381
04:01:35.449 * +slave slave 172.16.16.37:6379 172.16.16.37 6379 @ mymaster 172.16.16.37 6381
04:02:05.508 # +sdown slave 172.16.16.37:6379 172.16.16.37 6379 @ mymaster 172.16.16.37 6381

总结

根据日志输出可以看到redis哨兵模式在3分内完成了故障转移操作。
sentinel failover-timeout mymaster 180000

二、Redis集群模式搭建

2.1Redis集群模式架构图

Redis集群模式架构图

Redis的集群实现方案：
(1)官方的 redis cluster 的方案
(2)类 codis 的架构

2.2 虚拟机环境下搭建Redis集群模式

2.2.1 下载编译Redis

从redis官网下载Redis源码并进行编译。Redis官网：https://redis.io/download

注意：在Centos7上编译Redis6.x需要gcc的版本在5.0以上，Centos7默认的gcc版本为4.8.5。gcc目前最新版本为9.3.1

2.2.2 搭建Redis集群模式

根据Redis官方文档，测试搭建Redis集群模式：

（1）手动创建redis.conf配置文件启动redis实例，最后通过redis-cli 的集群命令创建集群

（2）通过Redis源码包下的utils工具包下的脚本创建（脚本创建更方便，但是手动创建有助于了解集群创建的过程）

关于集群创建的操作步骤可以参考Redis的官方文档：https://redis.io/topics/cluster-tutorial

2.3 Redis集群总结

（1）Redis集群拓扑结构
Redis集群是一个网状结构，每个节点都通过TCP连接跟其它每个节点连接。

在一个有N个节点的集群中，每个节点都有N-1个流出的TCP连接和N-1个流入的TCP连接，这些TCP连接会永久保持，并不是按需创建的

（2）Redis 集群的数据分片
Redis集群的实现方案：

客户端分区，代表为 Redis Sharding
代理分区方案，主流实现的有方案有 Twemproxy 和 Codis
查询路由方案，Redis默认实现方案。

Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念.

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:

节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.

（3）Redis集群的主从复制模型
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品.

在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.

然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了

不过当B和B1 都失败后，集群是不可用的.

（4）Redis集群的一致性保证
Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作.

第一个原因是因为集群是用了异步复制. 写操作过程:

客户端向主节点B写入一条命令.
主节点B向客户端回复命令状态.
主节点将写操作复制给他得从节点 B1, B2 和 B3.
主节点对命令的复制工作发生在返回命令回复之后，因为如果每次处理命令请求都需要等待复制操作完成的话，那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。注意：Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区，并且一个客户端与至少包括一个主节点在内的少数实例被孤立。

举个例子假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点，其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点，还有一个客户端 Z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1 .

Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了.

注意，在网络分裂出现期间，客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的，这一时间限制称为节点超时时间（node timeout），是 Redis 集群的一个重要的配置选项。

（5）Redis集群在线重配置
Redis 集群支持在集群运行过程中添加或移除节点。实际上，添加或移除节点都被抽象为同一个操作，那就是把哈希槽从一个节点移到另一个节点。

向集群添加一个新节点，就是把一个空节点加入到集群中并把某些哈希槽从已存在的节点移到新节点上。
从集群中移除一个节点，就是把该节点上的哈希槽移到其他已存在的节点上。
所以实现这个的核心是能把哈希槽移来移去。从实际角度看，哈希槽就只是一堆键，所以 Redis 集群在重组碎片（reshard）时做的就是把键从一个节点移到另一个节点。
为了理解这是怎么工作的，我们需要介绍 CLUSTER 的子命令，这些命令是用来操作 Redis 集群节点上的哈希槽转换表（slots translation table）。

以下是可用的子命令：

CLUSTER ADDSLOTS slot1 [slot2] … [slotN]
CLUSTER DELSLOTS slot1 [slot2] … [slotN]
CLUSTER SETSLOT slot NODE node
CLUSTER SETSLOT slot MIGRATING node
CLUSTER SETSLOT slot IMPORTING node
头两个命令，ADDSLOTS 和 DELSLOTS，就是简单地用来给一个 Redis 节点指派（assign）或移除哈希槽。在哈希槽被指派后，节点会将这个消息通过 gossip 协议向整个集群传播。ADDSLOTS 命令通常是用于在一个集群刚建立的时候快速给所有节点指派哈希槽。
当 SETSLOT 子命令使用 NODE 形式的时候，用来给指定 ID 的节点指派哈希槽。除此之外哈希槽能通过两个特殊的状态来设定，MIGRATING 和 IMPORTING：

当一个槽被设置为 MIGRATING，原来持有该哈希槽的节点仍会接受所有跟这个哈希槽有关的请求，但只有当查询的键还存在原节点时，原节点会处理该请求，否则这个查询会通过一个 -ASK 重定向（-ASK redirection）转发到迁移的目标节点。
当一个槽被设置为 IMPORTING，只有在接受到 ASKING 命令之后节点才会接受所有查询这个哈希槽的请求。如果客户端一直没有发送 ASKING 命令，那么查询都会通过 -MOVED 重定向错误转发到真正处理这个哈希槽的节点那里。
这么讲可能显得有点奇怪，现在我们用实例让它更清晰些。假设我们有两个 Redis 节点，称为 A 和 B。我们想要把哈希槽 8 从节点A 移到节点B，所以我们发送了这样的命令：

我们向节点B 发送：CLUSTER SETSLOT 8 IMPORTING A
我们向节点A 发送：CLUSTER SETSLOT 8 MIGRATING B
其他所有节点在每次被询问到的一个键是属于哈希槽 8 的时候，都会把客户端引向节点”A”。具体如下：

所有关于已存在的键的查询都由节点”A”处理。
所有关于不存在于节点 A 的键都由节点”B”处理。
这种方式让我们可以不用在节点 A 中创建新的键。同时，一个叫做 redis-trib 的特殊客户端，它也是 Redis 集群的配置程序（configuration utility），会确保把已存在的键从节点 A 移到节点 B。这通过以下命令实现：

CLUSTER GETKEYSINSLOT slot count
上面这个命令会返回指定的哈希槽中 count 个键。对于每个返回的键，redis-trib 向节点 A 发送一个 MIGRATE 命令，这样会以原子性的方式（在移动键的过程中两个节点都被锁住，以免出现竞争状况）把指定的键从节点 A 移到节点 B。以下是 MIGRATE 的工作原理：

MIGRATE target_host target_port key target_database id timeout
执行 MIGRATE 命令的节点会连接到目标节点，把序列化后的 key 发送过去，一旦收到 OK 回复就会从它自己的数据集中删除老的 key。所以从一个外部客户端看来，在某个时间点，一个 key 要不就存在于节点 A 中要不就存在于节点 B 中。

在 Redis 集群中，不需要指定一个除了 0 号之外的数据库，但 MIGRATE 命令能用于其他跟 Redis 集群无关的的任务，所以它是一个足够通用的命令。MIGRATE 命令被优化了，使得即使在移动像长列表这样的复杂键仍然能做到快速。不过当在重配置一个拥有很多键且键的数据量都很大的集群的时候，这个过程就并不那么好了，对于使用数据库的应用程序来说就会有延时这个限制。

（6）Redis集群失效检测
Redis 集群失效检测是用来识别出大多数节点何时无法访问某一个主节点或从节点。当这个事件发生时，就提升一个从节点来做主节点；若如果无法提升从节点来做主节点的话，那么整个集群就置为错误状态并停止接收客户端的查询。

每个节点都有一份跟其他已知节点相关的标识列表。其中有两个标识是用于失效检测，分别是 PFAIL 和 FAIL。PFAIL 表示可能失效（Possible failure），这是一个非公认的（non acknowledged）失效类型。FAIL 表示一个节点已经失效，而且这个情况已经被大多数主节点在某段固定时间内确认过的了。

参考文章：

https://redis.io/topics/cluster-tutorial

docker-compose快速搭建redis哨兵模式高可用集群

深入剖析Redis系列(二) - Redis哨兵模式与高可用集群

redis cluster集群模式总结