在本次比赛（天池）中， 我们采用"redis主从集群+哨兵"的策略实现数据持久化的高可用与分布式存储， 主从集群实现数据的分布式存储， 哨兵机制令集群更加高可用， 下面进行详细介绍。

一， redis主从集群

目前多数的数据持久化方案都不会使用单机结构了， 因为这样容易产生单机故障， 而且效率相对低下。 所以分布式集群成为我们进行数据持久化的更优方案， 所谓集群简单而言就是将多台机器应用于同一业务， 提高数据冗余， 避免单点故障， 同时也可以提高服务效率。以redis为例， redis集群分为主从集群和cluster集群， 主从集群可以增加数据冗余， 即主节点上的数据在多台子节点中存在数据副本， 可以避免单点故障， （但仅仅如此无法提升服务效率）。 cluster集群可以可以对数据进行分片， 利用更多的硬件资源提高服务效率， 即集群中的每一台机器都会存储数据的一部分（各不相同）， 但是无法应对单点故障。在硬件资源比较充裕的情况下， 项目中的正确的操作应该是"主从 + cluster"集群， 但在本次比赛中我们只要求做可靠分布式， 而且只有三台机器可以使用， 所以我们仅搭建了redis的主从集群。

主从集群其实就是一主多从的分布模式， 即集群中存在一个主节点，一个或多个从节点， 主节点连接集群中的所有从节点， 对外提供读写操作（为了性能， 我们在程序中只进行写操作）， 每个从节点连接到主节点，并从主节点备份数据， 对外提供读操作(不提供写操作)。主从节点之间赋值数据的原理如下：

Slave从节点服务启动并连接到Master之后，它将主动发送一个SYNC命令。Master服务主节点收到同步命令后将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中。此后，Master主节点继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。

image-20211011205547529.png

因为因为每一个节点存储的数据的都是一样的， 所以即便有某台机器宕机也不会影响集群的功能， 比如下面的情况：一台从节点宕机之后， 对整个集群构不成影响。

image-20211011205804869.png

上面描述的是某台从节点的死掉的情况， 那么如果主节点死掉了呢， 影响还是比较大的， 因为所有的从节点都需要从主节点复制数据， 而且只有主节点能提供些操作， 所以单纯的主从集群还不是高可用的。 主从集群需要搭配哨兵机制， 才能实现主节点的故障切换， 达到高可用的目的， 这在下一节中详细讲， 下面说一下主从集群的配置。

### **集群配置**

以下配置均在redis的配置文件(redis.conf)中进行, 主节点配置：

# mkdir -p /data/redis

# vim /usr/local/redis/redis.conf

#bind 192.168.30.128    #监听ip，多个ip用空格分隔, 默认监听所有ip
daemonize yes               #允许后台启动
logfile "/usr/local/redis/redis.log"                #日志路径
dir /data/redis                 #数据库备份文件存放目录
masterauth 123456           #slave连接master密码，master可省略
requirepass 123456          #设置master连接密码，slave可省略

appendonly yes                  #在/data/redis/目录生成appendonly.aof文件，将每一次写操作请求都追加到appendonly.aof 文件中

# echo 'vm.overcommit_memory=1' >> /etc/sysctl.conf

# sysctl -p 

从节点配置：

# mkdir -p /data/redis

# vim /usr/local/redis/redis.conf

bind 192.168.30.129
daemonize yes
logfile "/usr/local/redis/redis.log"
dir /data/redis
replicaof 192.168.30.128 6379        #监听主节点ip+port
masterauth 123456
requirepass 123456
appendonly yes

# echo 'vm.overcommit_memory=1' >> /etc/sysctl.conf

# sysctl -p

待配置好节点后启动， 在客户端登入任意节点执行info replication命令， 查看集群情况。

二，sentinel

Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案， sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

Sentinel是区别于redis的独立运行的进程， 在上文我们讲过redis的主从集群不具备高可用性，因为它不能进行主备切换， Sentinel的存在弥补了这样的缺点， Sentinel可以监控多个主从集群， 如果发现某个集群中的主节点宕机， 就会自动进行故障专转移， 将该主节点下合适的从节点提升为主节点， 继续进行服务。

image-20211012104256670.png

Sentinel节点在加入到集群中之后， 会自动连接到主节点（配置文件中有主节点的ip）， 然后通过主节点找到所有的从节点和Sentinel节点， 进行后续的监控和沟通。为了方便理解Sentinel的工作模式和原理， 下面介绍几个概念：

Sentinel的状态持久化

Sentinel会根据情况自动更新配置文件， 比如在发现其他从节点或者Sentinel之后， 就会在自己的配置文件中做出修改。所以安全的重启Sentinel， 但是需要注意， 如果集群中的配置有变化， 比如减少了一个Sentinel， 在重启之前的某个Sentinel时需要修改配置文件， 因为在它的配置文件中， Sentinel数量采用的之前集群的Sentinel数量。

Sentinel的三个定时任务

• 每10秒每个sentinel会对master和slave执行info命令，这个任务达到两个目的： a）发现slave节点 b）确认主从关系

  在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。 当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的PING 命令返回有效回复时， 主服务器的主管下线状态就会被移除

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

• 每1秒每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。

主观下线

所谓主观下线（Subjectively Down， 简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线。

Sentinel以每秒1次的频率向已经建立连接的实例发送ping命令， 然后根据对等实例回复是否超时或者无效判断该实例主观下线。sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down-after-milliseconds毫秒内未进行恢复，或者返回的都是无效回复，那么sentinel回认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。

客观下线

客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断，然后开启failover。换句话说， 当有多个Sentinel 将主服务器标记为主观下线之后， 该服务器就会被判定为客观下线。

当某一个Sentinel 实例第一次发现主节点宕机之后， 会向其他Sentinel 实例询问是否同意该主服务器宕机以及是否同意将自己选为leader Sentinel（领导哨兵）， 其他Sentinel 接收到该询问之后， 会作出这样的答复--“同意或不同意主节点宕机， 同意或不同意选询问节点为leader Sentinel ”， 当有足够的Sentinel 实例同意主节点宕机后， 主节点被判为可观下线， 同时， 如果有足够数量的Sentinel 选举询问节点为领导， 该节点会升级为leader Sentinel 进行故障切换（准备切换）。至于具体的选举方法， 我们在"Sentinel 仲裁会"中去描述。

根据上面的描述我们可以知道， 主观/客观下线是对于主节点而言的， 对于其他节点实例（从节点， Sentinel ）而言， 如果被发现下线， 会直接被判定位客观下线， 不需要与其他Sentinel 商量。

Sentinel仲裁会

在Sentinel的配置文件中有一项名为sentinel monitor <masterName> <ip> <port> <quorum>的配置， 用于指定要监控的主节点， 我们对这四个参数简单讲解一下：1，要监控的主机名 2，要监控的主机ip 3，端口 4，判断主节点客观下线的最少票数。

如上所述， 只要有"<quorum>"个sentinel同意主节点主观下线， 就可以判定主节点客观下线。选举leader sentinel的票数需要满足<quorum>和集群中sentinel数量的大多数两个要求，举个例子：如果一个集群中有5个sentinel， 那么大多数就是3， 假如quorum设置为2， 那么选举领头quorum所需票数最少为3， 如果quorum设置为4， 那么选举领头quorum所需票数最少为4。

sentinel通过发送 SENTINEL is-master-down-by-addr ip port current_epoch runid，（ip：主观下线的服务id，port：主观下线的服务端口，current_epoch：sentinel的纪元，runid：*表示检测服务下线状态，如果是sentinel 运行id，表示用来选举领头sentinel）来询问其它sentinel是否同意服务下线。一个sentinel接收另一个sentinel发来的is-master-down-by-addr后，提取参数，根据ip和端口，检测该主节点是否主观下线，并且回复is-master-down-by-addr，回复包含三个参数：down_state（1表示已下线，0表示未下线），leader_runid（领头sentinal id），leader_epoch（领头sentinel纪元）。

选举领头sentinel（即领导者选举）

一个redis服务被判断为客观下线时，多个监视该服务的sentinel协商，选举一个领头sentinel，对该redis服务进行故障转移操作。选举领头sentinel遵循以下规则： 1）所有的sentinel都有公平被选举成领头的资格。 2）所有的sentinel都有且只有一次将某个sentinel选举成领头的机会（在一轮选举中），一旦选举某个sentinel为领头，不能更改。 3）sentinel设置领头sentinel是先到先得，一旦当前sentinel设置了领头sentinel，以后要求设置sentinel为领头请求都会被拒绝。 4）每个发现服务主观下线的sentinel，都会要求其他sentinel将自己设置成领头。 5）当一个sentinel（源sentinel）向另一个sentinel（目sentinel）发送is-master-down-by-addr ip port current_epoch runid命令的时候，runid参数不是*，而是sentinel运行id，就表示源sentinel要求目标sentinel选举其为领头。 6）源sentinel会检查目标sentinel对其要求设置成领头的回复，如果回复的leader_runid和leader_epoch为源sentinel，表示目标sentinel同意将源sentinel设置成领头。 7）如果某个sentinel被半数以上的sentinel设置成领头，那么该sentinel既为领头。 8）如果在限定时间内，没有选举出领头sentinel，暂定一段时间，再选举。

对于leader sentinel的选举需要注意以下几点：

• 每次只有一个sentinel（leader sentinel）去执行故障转移操作

• 每个做主观下线的sentinel节点向其他sentinel节点发送上面那条命令，要求将它设置为领导者。

• 收到命令的sentinel节点如果还没有同意过其他的sentinel发送的命令（还未投过票），那么就会同意，否则拒绝

• 如果该sentinel节点发现自己的票数已经过半且达到了quorum的值，就会成为领导者

• 如果这个过程出现多个sentinel成为领导者，则会等待一段时间重新选举

Slave选举与优先级

当一个sentinel准备好了要进行failover，并且收到了其他sentinel的授权，那么就需要选举出一个合适的slave来做为新的master。

slave的选举主要会评估slave的以下几个方面： 1）与master断开连接的次数 2）Slave的优先级 3）数据复制的下标(用来评估slave当前拥有多少master的数据) 4）进程ID

如果一个slave与master失去联系超过10次，并且每次都超过了配置的最大失联时间(down-after-milliseconds)，如果sentinel在进行failover时发现slave失联，那么这个slave就会被sentinel认为不适合用来做新master的。 更严格的定义是，如果一个slave持续断开连接的时间超过 (down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state 就会被认为失去选举资格。

符合上述条件的slave才会被列入master候选人列表，并根据以下顺序来进行排序： 1）sentinel首先会根据slaves的优先级来进行排序，优先级越小排名越靠前。 2）如果优先级相同，则查看复制的下标，哪个从master接收的复制数据多，哪个就靠前。 3）如果优先级和下标都相同，就选择进程ID较小的那个。

一个redis无论是master还是slave，都必须在配置中指定一个slave优先级。要注意到master也是有可能通过failover变成slave的。 如果一个redis的slave优先级配置为0，那么它将永远不会被选为master。但是它依然会从master哪里复制数据。

故障转移的过程

当主节点被判定为客观下线并且leader sentinel通过选举诞生之后， leader sentinel会对该主节点进行故障切换， 即选举适当的Slave（从节点）提升为主节点， 并通知所有实例更新配置。

通知各实例更新配置的方式如下：

• 向被选中的从服务器发送 SLAVEOF NO ONE 命令，让它转变为主服务器。

• 通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ， 其他 Sentinel 对它们自己的配置进行更新。 向已下线主服务器的从服务器发送 SLAVEOF 命令， 让它们去复制新的主服务器。

• 当所有从服务器都已经开始复制新的主服务器时， 领头 Sentinel 终止这次故障迁移操作。

需要注意的是， Sentinel 实例之间进行通信的时候， 会自带当前集群的版本号， 如果执行完了一次failover（故障迁移）， 版本号是会自增的， 其他Sentinel 收到领头Sentinel 的通知之后发现信息中携带的版本号高于自己所知， 那么当前Sentinel 就会自动更新配置。

Sentinel 选取主服务器的具体规则：

• 在失效主服务器属下的从服务器当中， 那些被标记为主观下线、已断线、或者最后一次回复 PING 命令的时间大于五秒钟的从服务器都会被淘汰。

• 在失效主服务器属下的从服务器当中， 那些与失效主服务器连接断开的时长超过 down-after 选项指定的时长十倍的从服务器都会被淘汰。

• 在经历了以上两轮淘汰之后剩下来的从服务器中， 我们选出复制偏移量（replication offset）最大的那个从服务器作为新的主服务器； 如果复制偏移量不可用， 或者从服务器的复制偏移量相同， 那么带有最小运行 ID 的那个从服务器成为新的主服务器。

配置文件

sentinel.conf文件配置参数解释：

sentinel monitor mymaster 192.168.10.202 6379 2
Sentine监听的maste地址，第一个参数是给master起的名字，第二个参数为master IP，第三个为master端口，第四个为当该master挂了的时候，若想将该master判为失效，
在Sentine集群中必须至少2个Sentine同意才行，只要该数量不达标，则就不会发生故障迁移。也就是说只要有2个sentinel认为master下线，就认为该master客观下线，
启动failover并选举产生新的master。通常最后一个参数不能多于启动的sentinel实例数。

这个配置是sentinel需要监控的master/slaver信息，格式为sentinel monitor <mastername> <masterIP> <masterPort> <quorum> 
其中<quorum>应该小于集群中slave的个数，当失效的节点数超过了<quorum>,则认为整个体系结构失效

不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移，
并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。

换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。
-----------------------------------------------------------------------------------------------
2）sentinel down-after-milliseconds mymaster 30000
表示master被当前sentinel实例认定为失效的间隔时间。
master在多长时间内一直没有给Sentine返回有效信息，则认定该master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。

如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线
（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
-----------------------------------------------------------------------------------------------
3）sentinel parallel-syncs mymaster 2
当在执行故障转移时，设置几个slave同时进行切换master，该值越大，则可能就有越多的slave在切换master时不可用，可以将该值设置为1，即一个一个来，这样在某个
slave进行切换master同步数据时，其余的slave还能正常工作，以此保证每次只有一个从服务器处于不能处理命令请求的状态。

parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。

如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求，
因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主
服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。

当新master产生时，同时进行"slaveof"到新master并进行"SYNC"的slave个数。 
默认为1,建议保持默认值 
在salve执行salveof与同步时，将会终止客户端请求。 
此值较大，意味着"集群"终止客户端请求的时间总和和较大。 
此值较小,意味着"集群"在故障转移期间，多个salve向客户端提供服务时仍然使用旧数据。 
-----------------------------------------------------------------------------------------------
4）sentinel can-failover mymaster yes
在sentinel检测到O_DOWN后，是否对这台redis启动failover机制
-----------------------------------------------------------------------------------------------
5）sentinel auth-pass mymaster 20180408
设置sentinel连接的master和slave的密码，这个需要和redis.conf文件中设置的密码一样
-----------------------------------------------------------------------------------------------
6）sentinel failover-timeout mymaster 180000
failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。 
执行故障迁移超时时间，即在指定时间内没有大多数的sentinel 反馈master下线，该故障迁移计划则失效
-----------------------------------------------------------------------------------------------
7）sentinel config-epoch mymaster 0
选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步。这个数字越小， 完成故障转移所需的时间就越长。
-----------------------------------------------------------------------------------------------
8）sentinel notification-script mymaster /var/redis/notify.sh
当failover时，可以指定一个"通知"脚本用来告知当前集群的情况。
脚本被允许执行的最大时间为60秒，如果超时，脚本将会被终止(KILL)
-----------------------------------------------------------------------------------------------
9）sentinel leader-epoch mymaster 0
同时一时间最多0个slave可同时更新配置,建议数字不要太大,以免影响正常对外提供服务。

3, shell脚本

最后附上我们自己编写的自动下载安装redis与配置rei第三集群的脚本。

redis安装

resdis.sh:

#!/bin/sh

res="$(pwd)/res.txt"

cd /home/
mkdir redis && cd redis
wget http://download.redis.io/releases/redis-5.0.5.tar.gz
sleep 1
tar -zxvf redis-5.0.5.tar.gz -C /usr/local/
cd /usr/local/redis-5.0.5/
make
mkdir bin
cp src/redis-server src/redis-cli bin
sleep 2

sed -i 's/daemonize no/daemonize yes/g' redis.conf
sed -i 's/# requirepass foobared/requirepass 123456/g' redis.conf

cat $res | while read line
do
echo $line >> /etc/init.d/redis
done

chmod a+x /etc/init.d/redis
chkconfig redis on

service redis start 

res.txt:

#!/bin/sh 
# chkconfig:   345 86 14
# description:  Redis is a persistent key-value database

PATH=/usr/local/redis-5.0.5/bin:/sbin:/usr/bin:/bin    
REDISPORT=6379 
EXEC=/usr/local/redis-5.0.5/bin/redis-server
REDIS_CLI=/usr/local/redis-5.0.5/bin/redis-cli    
PIDFILE=/var/run/redis_6379.pid
CONF="/usr/local/redis-5.0.5/redis.conf"

case "$1" in
 start) 
 if [ -f $PIDFILE ] 
 then
 echo "$PIDFILE exists, process is already running or crashed"
 else
 echo "Starting Redis server..."
 $EXEC $CONF 
 fi
 if [ "$?"="0" ]
 then
 echo "Redis is running..."
 fi
 ;; 
 stop) 
 if [ ! -f $PIDFILE ] 
 then
 echo "$PIDFILE does not exist, process is not running"
 else
 PID=$(cat $PIDFILE) 
 echo "Stopping ..."
 $REDIS_CLI -p $REDISPORT SHUTDOWN 
 while [ -x ${PIDFILE} ] 
 do
 echo "Waiting for Redis to shutdown ..."
 sleep 1 
 done
 echo "Redis stopped"
 fi
 ;; 
 restart|force-reload) 
 ${0} stop 
 ${0} start 
 ;; 
 *) 
 echo "Usage: /etc/init.d/redis {start|stop|restart|force-reload}" >&2 
 exit 1 
esac

请将上面两个文件放到一个文件夹下在执行shell脚本， res.txt 文件用于设置开机自启， 如果设置失败（可能linux版本有问题）， 也可以通过systemctl设置开机自启， 详情见博客：

https://blog.csdn.net/renfeigui0/article/details/103256965

主从集群搭建

redisma.sh:

#!/bin/bash

## kill redis进程 
ps -ef | grep redis-server | grep -v grep | awk '{print $2}' | xargs kill -9

echo "-----------------设置redis主从集群配置--------------------"

if [ -z $1 ];then
echo "节点角色不可为空"
exit
fi

if [ ! -e /usr/local/redis-4.0.5/redis.log ];then
echo "正在生成日志文件"
touch /usr/local/redis-5.0.5/redis.log
fi

if [ ! -d /usr/local/redis-5.0.5/redisworkplace ];then
echo "正在生成工作目录"
mkdir /usr/local/redis-5.0.5/redisworkplace
fi

sed -i 's/bind 127.0.0.1/# bind 127.0.0.1/g' /usr/local/redis-5.0.5/redis.conf
sed -i 's/daemonize no/daemonize yes/g' /usr/local/redis-5.0.5/redis.conf
sed -i 's/# requirepass foobared/requirepass 123456/g' /usr/local/redis-5.0.5/redis.conf
sed -i 's/logfile ""/logfile "\/usr\/local\/redis-5.0.5\/reids.log"/g' /usr/local/redis-5.0.5/redis.conf
sed -i 's/dir \.\//dir "\/usr\/local\/redis-5.0.5\/redisworkplace"/g' /usr/local/redis-5.0.5/redis.conf
sed -i 's/# masterauth <master-password>/masterauth 123456/g' /usr/local/redis-5.0.5/redis.conf
sed -i 's/protected-mode yes/protected-mode no/g' /usr/local/redis-5.0.5/redis.conf

if [ "$1" = "master" ];then
echo "主节点设置完成"
elif [ "$1" = "slave" ];then
if [ -z  $2 ];then
echo "master ip不可为空"
exit
fi
sed -i 's/# replicaof <masterip> <masterport>/replicaof '$2' 6379/g' /usr/local/redis-5.0.5/redis.conf
echo "从节点设置完成, $2"
else
echo "参数错误"
fi

echo "正在启动redis"
rm -rf /var/run/redis_6379.pid
/usr/local/redis-5.0.5/bin/redis-server /usr/local/redis-5.0.5/redis.conf
echo "--------------启动成功--------------"

上面的脚本需要传入参数， 参数格式为"master"或者"slave master_ip",如果输入参数为"master"表示将当前主机设置为主节点， 如果输入"slave master_ip"表示当前节点设置为从节点， 并告知主节点ip， 进行绑定。

sentinel配置

redissen.sh:

#!/bin/bash

echo "--------------配置Sentinel------------------"
if [ ! -d /usr/local/redis-5.0.5/sentinel ];then
echo "正在创建工作目录"
mkdir /usr/local/redis-5.0.5/sentinel
fi

if [ ! -e /usr/local/redis-5.0.5/sentinel.log ];then
echo "正在创建日志文件"
touch /usr/local/redis-5.0.5/sentinel.log
fi

if [ -z $1 ];then
echo "erro: 主节点ip不可为空"
exit
fi

sed -i 's/daemonize no/daemonize yes/g' /usr/local/redis-5.0.5/sentinel.conf
sed -i 's/logfile ""/logfile "\/usr\/local\/redis-5.0.5\/sentinel.log"/g' /usr/local/redis-5.0.5/sentinel.conf
sed -i 's/dir \/tmp/dir \/usr\/local\/redis-5.0.5\/sentinel/g' /usr/local/redis-5.0.5/sentinel.conf
sed -i 's/sentinel monitor mymaster 127.0.0.1 6379 2/sentinel monitor mymaster '$1' 6379 2/g' /usr/local/redis-5.0.5/sentinel.conf
sed -i 's/# sentinel auth-pass <master-name> <password>/sentinel auth-pass mymaster 123456/g' /usr/local/redis-5.0.5/sentinel.conf
sed -i 's/sentinel down-after-milliseconds mymaster 30000/sentinel down-after-milliseconds mymaster 3000/g' /usr/local/redis-5.0.5/sentinel.conf
sed -i 's/# sentinel failover-timeout <master-name> <milliseconds>/sentinel failover-timeout mymaster 5000/g' /usr/local/redis-5.0.5/sentinel.conf


echo "Sentinel配置完毕"
echo "正在启动Sentinel"
rm -rf /var/run/redis-sentinel.pid
/usr/local/redis-5.0.5/bin/redis-sentinel /usr/local/redis-5.0.5/sentinel.conf
echo "-------------启动成功---------------"

上面的脚本需要传入主节点ip作为参数。