项目已经在github上传，欢迎指教。redis-cluster-docker

首先先把基础概念内容相对理一遍：

哨兵

1.基本概念

在这边先对几个名词进行说明：

Red Sentinel是Redis的高可用实现方案。

1.1.主从复制的问题

Redis的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：第一，作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备顶上来，并且保证数据尽量不丢失（主从复制是最终一致性）。第二，从节点可以扩展主节点的读能力。

1.2.高可用

Redis主从复制模式下，一旦主节点出现了故障不可达，就需要Redis Sentinel自动完成发现和故障转移，并且通知应用方，从而实现真正的高可用。

Redis Sentinel是一个分布式架构，其中包括若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当他发现节点不可达时，会对节点做下线标识。如果被标志的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时候，它们回选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。整个过程是完全自动的，不需要人工来介入。

因此，可以总结Redis Sentinel具有以下几个功能：

• 监控：Sentinel节点会定期检测Redis数据节点，其余Sentinel节点是否可达。
• 通知：Sentinel节点会将故障转移的结果通知给应用方。
• 主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。
• 配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。

同时看到，Redis Sentinel包含若干个Sentinel节点，这样做也带来了两个好处：

• 对于节点的故障判断是由多个Sentinel节点共同完成的，这样可以有效地防止误判。
• Sentinel节点集合是由若干Sentinel节点组成的，这样即使个别Sentinel节点不可用，整个Sentinel节点集合依然是健壮的。

注意，Sentinel节点本身就是独立的Redis节点，只不过它们有一点特殊，它们不存储任何数据，只支持部分命令。

2.实现原理

Redis Sentinel的基本实现原理，具体包含以下几个方面：

1. Redis Sentinel的三个定时任务
2. 主观下线和客观下线
3. Sentinel领导选举
4. 故障转移。

2.1.三个定时任务

1.每隔10s，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。如：

# Replication
role:master
connected_salves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=4917,lag=1
slave1:ip=127.0.0.1,port=6380,state=online,offset=4917,lag=1
复制代码

Sentinel节点通过对上述结果进行解析就可以找到相应的从节点。具体表现在：

• 通过向主节点执行info命令，获取从节点的信息，这也是为什么Sentinel节点不需要显示配置监控从节点。
• 当有新的从节点加入时都可以立刻感知出来。
• 节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信息。

2. 每隔2秒，每个Sentinel节点会向Redis数据节点的**__sentinel__:hello**频道上发送该节点对于主节点的判断以及当前Sentinel节点的信息，同时每隔Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及他们对主节点的判断，所以这个定时任务可以完成以下两个工作：
   • 发现新的Sentinel节点
   • Sentinel节点之前交换主节点的状态（作为后面客观下线以及领导者选举的依据）
3. 每隔1秒，每个Sentinel节点会向主节点，从节点，其余Sentinel节点发送一条ping命令做心跳检测，来确认当前节点是否可达。

简单总结：

1)每隔10秒，会向主从节点发送info获取拓扑信息。2)每隔2秒，向*__sentinel__:hello频道发送对主节点判断和当前Sentinel信息，也就是自己的汇报结果。3)每隔1秒，向其余所有**节点发送ping，保持联系。*

2.2.主观下线和客观下线

1. 主观下线：就像前面说的第三个定时任务，每个Sentinel节点每隔1s对主、从节点、其他Sentinel节点发送ping做心跳检测。当这些节点超过配置的时长没有收到有效的恢复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线。

   可以看出是一家之言，有误判的可能。

2. 客观下线：当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过Sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过个数，Sentinel节点认为主节点确实有问题，这时候Sentinel会做出客观下线的决定，这样客观下线的含义是比较明显了。

上面指的是对主节点客观下线的，注意，从节点、Sentinel节点在主观下线后，没有后续的故障转移操作。

2.4.领导者Sentinel节点选举

故障转移的工作只需要一个Sentinel节点来完成即可，所以Sentinel节点之间会做一个领导者选举的工作，选一个Sentinel节点作为领导者进行故障转移的工作。而采用的就是Raft算法。这边讲解一下Redis Sentinel进行领导者选举的大致思路：

1. 每个Sentinel节点都有资格成为领导者。按照前面所说的：当他确认主节点主观下线时候，会向其他Sentinel节点发送Sentinel is-master-down-by-addr命令，这条的作用，也有要求将自己设置为领导者。
2. 收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的Sentinel is-master-down-by-addr命令，将同意该请求，否则拒绝。
3. 如果该Sentinel节点发现自己的票数已经大于等于max(quorum,num(sentinels)/2+1)。那么它将成为领导。
4. 如果此过程没有选举出领导者，将进行下一次选举。

**简单来说：**在客观下线确认的同时，就会请求当领导者的同意。

超过半数Sentinel节点同意，或者配置时候的同意下线人数同意。

2.5.故障转移

从刚刚选举出的领导者Sentinel节点，他来进行故障转移：

1. 在从节点列表中选出一个节点作为新的主节点，选择方法如下：

   • 过滤不健康的（在心跳检测等等连接中表现不好的）
   • 尽量选择（有的话）salve-priority（从节点优先级）最高的从节点列表。

2. 对第一部选出来的从节点执行slaveof no one命令让它成为主节点。

3. Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点，复制规则和parallel-syncs参数有关。

   也就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。（避免对主节点造成过度网络和磁盘IO的开销）

4. Sentinel节点集合会将原理的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点。

   原主节点在重新上线后会被要求去复制新的主节点。也就是说，Sentinel节点依然会对这些下线节点进行定期监控，这是Redis Sentinel设计思路决定的。

前提：本试验环境已经提前安装了docker和docker-compose

说明：本次部署是单机伪集群，想要部署真正的集群，修改ip地址拆分配置到各个主机上部署即可。

部署

这边先说一些部署技巧:

部署至少3个且奇数个的Sentinel节点：

1. 3个以上是通过Sentinel节点的个数提高对于故障断定的准确性，因为领导者选举需要至少一般加1个的节点，奇数个节点可以在满足该条件的基础上节省一个节点。详情见前面提及的概念内容。
2. Sentinel节点集合可以只监控一个主节点，也可以监控多个主节点。

项目分成两个目录，一个是redis目录。主要存放redis主从节点的docke-compose文件。

1. 在redis文件夹下创建redis目录，主要是为了持久化redis。（RDB和AOF路径一样）

2. 在同文件夹下新建 docker-compose.yml文件。

   ├── data
   │   ├── master
   │   ├── slave1
   │   └── slave2
   └── docker-compose.yml
   复制代码

3. 这边简单说重要的配置项：

   ...
       container_name: redis-master
   ...
       volumes:
         - ./data/master:/data
       command: redis-server --port 6379 --requirepass 123
       
    ...
       container_name: redis-slave-1
   ...
       volumes:
         - ./data/slave1:/data
       command: redis-server --slaveof 192.168.0.107 6379 --port 6380 --requirepass 1234 --masterauth 123
       
   复制代码

   需要配置好对应验证密码和容器命以便从节点连接主节点。注意从节点连接不能用127.0.0.1连接上主服务器。这个的原因就是redis主服务器绑定了127.0.0.1，那么跨服务器IP的访问就会失败，从服务器用IP和端口访问主的时候，主服务器发现本机6379端口绑在了127.0.0.1上，也就是只能本机才能访问，外部请求会被过滤。这边我修改为ifconfig获取的网卡地址，如果是线上生产环境建议绑定IP地址。

接下来是在跟目录下建立文件夹sentinel：

1. 在文件夹下建立配置文件夹conf。对于3个配置文件：slave1.conf，slave2.conf，slave3.conf内容相同：

sentinel monitor mymaster 192.168.0.107 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster 1234
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
复制代码

2. 在文件夹下新建docker-compose.yml。现在sentinel文件夹结构如下：

   ├── conf
   │   ├── sentinel1.conf
   │   ├── sentinel2.conf
   │   └── sentinel3.conf
   └── docker-compose.yml
   复制代码

3. 配置项重点是以下2条（注意配置文件每次成功运行后会自动更新一些节点信息）：

   #自定义集群名，其中 192.168.8.188 为 redis-master 的 ip，6379 为 redis-master 的端口，2 为最小投票数（因为有 3 台 Sentinel 所以可以设置成 2）
   sentinel monitor mymaster 192.168.8.188 6379 2
   # 每个Sentinel节点都要通过定期发送ping命令来判断redis数据节点和其余Sentinel节点是否可达，超过down-after-milliseconds即为不可达。
   sentinel down-after-milliseconds mymaster 30000
   复制代码