nohup redis-server --port 6380 >> /usr/local/redis/data/log/6380.log 2>&1 &
nohup redis-server --port 6381 >> /usr/local/redis/data/log/6381.log 2>&1 &
nohup redis-server --port 6382 >> /usr/local/redis/data/log/6382.log 2>&1 &
[root@redis ~]# ps -ef |grep redis
root      16421  16314  0 03:01 pts/1    00:00:00 redis-server *:6380
root      16427  16314  0 03:01 pts/1    00:00:00 redis-server *:6381
root      16431  16314  0 03:01 pts/1    00:00:00 redis-server *:6382

2、连接数据库并设置主从复制

Gong-Dezhe-MBP:log gongdezhe$ redis-cli -p 6380
127.0.0.1:6380> 
Gong-Dezhe-MBP:~ gongdezhe$ redis-cli -p 6381
127.0.0.1:6381> slaveof 127.0.0.1 6380
OK
Gong-Dezhe-MBP:~ gongdezhe$ redis-cli -p 6382
127.0.0.1:6382> slaveof 127.0.0.1 6380
OK

主从配置完成后，主节点信息

从节点信息：

数据同步测试：

4、高可用方案-哨兵模式sentinel

搭建好的主从复制方案可以达到数据同步目的，但是当主服务器宕机后，需要手动将一个从服务器切换为主服务器，这个过程需要人工干预，同时切换会导致Redis的写入功能不可用。

需要一种能够自动完成master故障发现并能够将一个Slave切换为master，这个时候需要哨兵sentinel模式，哨兵模式可以自动切换主从节点。

5、哨兵模式简介

? ? ? ? ?当我们搭建好redis主从复制方案后会发现一个问题，那就是当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，同时在手动切过程中也会导致redis服务器写入功能不可用。所以需要一种方法可以完成Master故障后可以自动的将一个Slave切换为Master，这个时候就有了sentinel哨兵模式。通过哨兵机制可以自动切换主从节点。(自动选举老大)

? ? ? ? sentinel是官方提供的高可用方案，其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。同时 sentinel是一个分布式系统，可以在一个架构中运行多个Sentinel进程，可以做到sentinel的高可用。

5.1、sentinel工作过程：

通过向主服务器和从服务器发送ping命令，让服务器返回运行状态。
当哨兵监测到master宕机，会自动将一个slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

5.2、关于sentinel的三个定时任务：

每1秒每个sentinel对其他sentinel和redis节点执行ping操作，心跳检测。
每10秒每个sentinel会对master和slave执行info命令，目的是发现slave结点，确定主从关系。

每2秒每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个发布订阅的频道(sentinel:hello)。sentinel节点通过__sentinel__:hello频道进行信息交换(对节点的"看法"和自身的信息)，达成共识.

5.3、哨兵原理

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控，各个哨兵之间还会进行监控，这样就形成了多哨兵模式

sentinel是一个分布式系统，可以在一个架构中运行多个Sentinel进程。所以监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel网络，互相通信并交换彼此关于被监视服务器信息。

5.4、哨兵故障修复原理

5.4.1.主观下线：

当主服务器发生故障时，此时一个sentinel发现了故障，系统并不会马上进行failover过程（这个现象称为主观下线），它会向网络中的其他Sentinel进行确认。

5.4.2.客观下线：

接着其他Sentinel也陆续发现故障，这个时候其中一个Sentinel就会发起投票。一定数量的哨兵(在配置文件中指定)确认Master被标记为主观下线，此时将Master标记为客观下线。

5.4.3.sentinel的leader选举：

要想完成故障切换（将故障master剔除，并将一个slave提升为master）就必须先选举一个leader。最先发现故障的sentinel向其他哨兵发起请求成为leader，其他哨兵在没有同意别的哨兵的leader请求时，就会把票投给该sentinel。当半数以上的sentinel投票通过后就认定该sentinel为leader。接下来的故障切换有该leader完成。

5.4.4.master选举：

leader选好后将故障master剔除，从slave中挑选一个成为master。遵照的原则如下：

slave的优先级
slave从master那同步的数据量，那个slave多就优先。

5.4.5.新Master再通过发布订阅模式通知所有sentinel更新监控主机信息。

5.4.6.故障的主服务器修复后将成为从服务器继续工作。

示例图如下：

故障发生

故障切换

Master重新上线后

5.5、sentinel.conf配置讲解

5.5.1、配置哨兵配置文件 sentinel.conf

6、哨兵模式配置

本实验在一台机器上完成，创建不同端口的redis实例。

6.1.创建redis实例

nohup redis-server --port 6380 >> /usr/local/redis/data/log/6380.log 2>&1 & nohup redis-server --port 6381 >> /usr/local/redis/data/log/6381.log 2>&1 & nohup redis-server --port 6382 >> /usr/local/redis/data/log/6382.log 2>&1 & [root@redis ~]# ps -ef |grep redis root 16421 16314 0 03:01 pts/1 00:00:00 redis-server *:6380 root 16427 16314 0 03:01 pts/1 00:00:00 redis-server *:6381 root 16431 16314 0 03:01 pts/1 00:00:00 redis-server *:6382 root 16436 16314 0 03:01 pts/1 00:00:00 grep --color=auto redis

6.2.连接数据库并设置主从复制

[root@redis ~]# redis-cli -p 6380 127.0.0.1:6380> [root@redis ~]# redis-cli -p 6381 127.0.0.1:6381> SLAVEOF 127.0.0.1 6380 #将6380设置为master OK [root@redis ~]# redis-cli -p 6382 127.0.0.1:6382> SLAVEOF 127.0.0.1 6380 OK

6.3.搭建哨兵模式集群

创建sentinel配置文件

[root@redis conf]# cat sentinel1.conf port 26300 #指定sentinel进程端口号 sentinel monitor redis1 127.0.0.1 6380 2 #Sentinel monitor <name> <ip> <port> <quorum> [root@redis conf]# cat sentinel2.conf port 26301 sentinel monitor redis1 127.0.0.1 6380 2

name ：redis主服务名称，可以自行命名，但是在一个sentinel网络中，一个redis主服务只能有一个名称；
ip和port ：redis主服务的IP地址和端口号.

quorum ：表示要将这个主服务器判断为失效并下线至少需要2个sentinel同意
protected-mode ：关闭保护模式（默认情况下，redis node和sentinel的protected-mode都是yes，在搭建集群时，若想从远程连接redis集群，需要将redis node和sentinel的protected-mode修改为no，若只修改redis node，从远程连接sentinel后，依然是无法正常使用的，且sentinel的配置文件中没有protected-mode配置项，需要手工添加。依据redis文档的说明，若protected-mode设置为no后，需要增加密码证或是IP限制等保护机制，否则是极度危险的。）

启动sentinel

[root@redis ~]# nohup redis-sentinel /usr/local/redis/data/config/sentinel>>/usr/local/redis/data/log/sentinel1.log 2 >&1 & [1] 16522 [root@redis ~]# nohup redis-sentinel /usr/local/redis/data/config/sentinel2.conf>>/usr/local/redis/data/log/sentinel2.log 2 >&1 & [2] 16526 [root@redis ~]# ps -ef |grep sentinel root 16522 16440 0 03:55 pts/2 00:00:00 redis-sentinel *:26300 [sentinel] root 16526 16440 0 03:55 pts/2 00:00:00 redis-sentinel *:26301 [sentinel]

6.4.测试。模拟主节点故障，查看故障后主从环境改变

关闭主节点

[root@redis ~]# ps -ef |grep redis-server root 16604 16440 0 04:12 pts/2 00:00:02 redis-server *:6381 root 16608 16440 0 04:12 pts/2 00:00:03 redis-server *:6382 root 16702 16314 0 04:46 pts/1 00:00:00 redis-server *:6380 [root@redis ~]# kill 16702

此时查看6381和6382的日志文件，在6382的日志文件中发现了如下内容，说明此时已经将6381切换为主节点。

再次启动6380时，6380成为slave，6381时master

最后查看一下sentinel配置文件：

cat /data/redis/conf/sentinel2.conf port 26301 sentinel myid 74cdfbb5ae55a77ad4d05d5d9d50fd64725e192a # Generated by CONFIG REWRITE dir "/root" protected-mode no sentinel deny-scripts-reconfig yes sentinel monitor redis1 127.0.0.1 6381 1 #主节点 sentinel config-epoch redis1 1 sentinel leader-epoch redis1 1 sentinel known-replica redis1 127.0.0.1 6382 #从节点 sentinel known-replica redis1 127.0.0.1 6380 sentinel known-sentinel redis1 127.0.0.1 26300 9539652da78b0385479a827e753deceaef864989 sentinel current-epoch 1