世界杯积分榜_世界杯几年一届 - fjmzsy.com

上一节介绍了Redis Sentinel的基本架构，本节将介绍如何安装和部署 Redis Sentinel。 9.2.1 部署拓扑结构 下面将以3个Sentinel节点、1个主节点、2个从节点组成一个Redis Sentinel进行说明，拓扑结构如图9-13所示。

具体的物理部署如表9-2所示。

9.2.2 部署Redis数据节点 9.1节提到过，Redis Sentinel中Redis数据节点没有做任何特殊配置，按 照之前章节介绍的方法启动就可以，下面以一个比较简单的配置进行说明。 1.启动主节点 配置： redis-6379.conf port 6379 daemonize yes logfile "6379.log" dbfilename "dump-6379.rdb" dir "/opt/soft/redis/data/" 启动主节点： redis-server redis-6379.conf 确认是否启动。一般来说只需要ping命令检测一下就可以，确认Redis数 据节点是否已经启动。 $ redis-cli -h 127.0.0.1 -p 6379 ping PONG 此时拓扑结构如图9-14所示。

图9-14 启动主节点

2.启动两个从节点 配置： 两个从节点的配置是完全一样的，下面以一个从节点为例子进行说明， 和主节点的配置不一样的是添加了slaveof配置。 redis-6380.conf port 6380 daemonize yes logfile "6380.log" dbfilename "dump-6380.rdb" dir "/opt/soft/redis/data/" slaveof 127.0.0.1 6379 启动两个从节点： redis-server redis-6380.conf redis-server redis-6381.conf 验证： $ redis-cli -h 127.0.0.1 -p 6380 ping PONG $ redis-cli -h 127.0.0.1 -p 6381 ping PONG 3.确认主从关系 主节点的视角，它有两个从节点，分别是127.0.0.1：6380和127.0.0.1： 6381： $ redis-cli -h 127.0.0.1 -p 6379 info replication # Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6380,state=online,offset=281,lag=1 slave1:ip=127.0.0.1,port=6381,state=online,offset=281,lag=0 ................. 从节点的视角，它的主节点是127.0.0.1：6379： $ redis-cli -h 127.0.0.1 -p 6380 info replication # Replication role:slave master_host:127.0.0.1 master_port:6379 master_link_status:up ................. 此时拓扑结构如图9-15所示。

9.2.3 部署Sentinel节点 3个Sentinel节点的部署方法是完全一致的（端口不同），下面以 sentinel-1节点的部署为例子进行说明。 1.配置Sentinel节点 redis-sentinel-26379.conf port 26379 daemonize yes logfile "26379.log" dir /opt/soft/redis/data sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 1）Sentinel节点的默认端口是26379。 2）sentinel monitor mymaster127.0.0.163792配置代表sentinel-1节点需要监 控127.0.0.1：6379这个主节点，2代表判断主节点失败至少需要2个Sentinel节 点同意，mymaster是主节点的别名，其余Sentinel配置将在下一节进行详细说 明。 2.启动Sentinel节点 Sentinel节点的启动方法有两种： 方法一，使用redis-sentinel命令： redis-sentinel redis-sentinel-26379.conf 方法二，使用redis-server命令加--sentinel参数： redis-server redis-sentinel-26379.conf --sentinel 两种方法本质上是一样的。 3.确认 Sentinel节点本质上是一个特殊的Redis节点，所以也可以通过info命令 来查询它的相关信息，从下面info的Sentinel片段来看，Sentinel节点找到了主 节点127.0.0.1：6379，发现了它的两个从节点，同时发现Redis Sentinel一共 有3个Sentinel节点。这里只需要了解Sentinel节点能够彼此感知到对方，同时 能够感知到Redis数据节点就可以了： $ redis-cli -h 127.0.0.1 -p 26379 info Sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3 当三个Sentinel节点都启动后，整个拓扑结构如图9-16所示。 至此Redis Sentinel已经搭建起来了，整体上还是比较容易的，但是有2 点需要强调一下： 1）生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机 上。 2）Redis Sentinel中的数据节点和普通的Redis数据节点在配置上没有任 何区别，只不过是添加了一些Sentinel节点对它们进行监控。

9.2.4 配置优化 了解每个配置的含义有助于更加合理地使用Redis Sentinel，因此本节将 对每个配置的使用和优化进行详细介绍。Redis安装目录下有一个 sentinel.conf，是默认的Sentinel节点配置文件，下面就以它作为例子进行说 明。 1.配置说明和优化 port 26379 dir /opt/soft/redis/data sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 #sentinel auth-pass #sentinel notification-script #sentinel client-reconfig-script port和dir分别代表Sentinel节点的端口和工作目录，下面重点对sentinel相 关配置进行详细说明。 （1）sentinel monitor 配置如下： sentinel monitor Sentinel节点会定期监控主节点，所以从配置上必然也会有所体现，本 配置说明Sentinel节点要监控的是一个名字叫做，ip地址和端 口为的主节点。代表要判定主节点最终不可达所需要的 票数。但实际上Sentinel节点会对所有节点进行监控，但是在Sentinel节点的 配置中没有看到有关从节点和其余Sentinel节点的配置，那是因为Sentinel节 点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息，有关这 部分是如何实现的，将在9.5节介绍。 例如某个Sentinel初始节点配置如下： port 26379 daemonize yes logfile "26379.log" dir /opt/soft/redis/data sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 当所有节点启动后，配置文件中的内容发生了变化，体现在三个方面： ·Sentinel节点自动发现了从节点、其余Sentinel节点。 ·去掉了默认配置，例如parallel-syncs、failover-timeout参数。 ·添加了配置纪元相关参数。 启动后变化为：

port 26379

daemonize yes

logfile "26379.log"

dir "/opt/soft/redis/data"

sentinel monitor mymaster 127.0.0.1 6379 2

sentinel config-epoch mymaster 0

sentinel leader-epoch mymaster 0

# 发现两个 slave 节点

sentinel known-slave mymaster 127.0.0.1 6380

sentinel known-slave mymaster 127.0.0.1 6381

# 发现两个 sentinel 节点

sentinel known-sentinel mymaster 127.0.0.1 26380 282a70ff56c36ed56e8f7ee6ada741

24140d6f53

sentinel known-sentinel mymaster 127.0.0.1 26381 f714470d30a61a8e39ae031192f1fe

ae7eb5b2be

sentinel current-epoch 0

参数用于故障发现和判定，例如将quorum配置为2，代表至少 有2个Sentinel节点认为主节点不可达，那么这个不可达的判定才是客观的。 对于设置的越小，那么达到下线的条件越宽松，反之越严格。一 般建议将其设置为Sentinel节点的一半加1。 同时还与Sentinel节点的领导者选举有关，至少要有 max（quorum，num（sentinels）/2+1）个Sentinel节点参与选举，才能选出领 导者Sentinel，从而完成故障转移。例如有5个Sentinel节点，quorum=4，那么 至少要有max（quorum，num（sentinels）/2+1）=4个在线Sentinel节点才可以 进行领导者选举。 （2）sentinel down-after-milliseconds 配置如下： sentinel down-after-milliseconds 每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其 余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没 有有效的回复，则判定节点不可达，（单位为毫秒）就是超时时 间。这个配置是对节点失败判定的重要依据。 优化说明：down-after-milliseconds越大，代表Sentinel节点对于节点不可 达的条件越宽松，反之越严格。条件宽松有可能带来的问题是节点确实不可 达了，那么应用方需要等待故障转移的时间越长，也就意味着应用方故障时 间可能越长。条件严格虽然可以及时发现故障完成故障转移，但是也存在一 定的误判率。 运维提示 down-after-milliseconds虽然以为参数，但实际上对 Sentinel节点、主节点、从节点的失败判定同时有效。 （3）sentinel parallel-syncs 配置如下： sentinel parallel-syncs 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点 会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复 制操作，parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节 点发起复制操作的从节点个数。如果这个参数配置的比较大，那么多个从节 点会向新的主节点同时发起复制操作，尽管复制操作通常不会阻塞主节点， 但是同时向主节点发起复制，必然会对主节点所在的机器造成一定的网络和 磁盘IO开销。图9-17展示parallel-syncs=3和parallel-syncs=1的效果，parallel- syncs=3会同时发起复制，parallel-syncs=1时从节点会轮询发起复制。 （4）sentinel failover-timeout 配置如下： sentinel failover-timeout

failover-timeout通常被解释成故障转移超时时间，但实际上它作用于故 障转移的各个阶段： a）选出合适从节点。 b）晋升选出的从节点为主节点。 c）命令其余从节点复制新的主节点。 d）等待原主节点恢复后命令它去复制新的主节点。 failover-timeout的作用具体体现在四个方面： 1）如果Redis Sentinel对一个主节点故障转移失败，那么下次再对该主 节点做故障转移的起始时间是failover-timeout的2倍。 2）在b）阶段时，如果Sentinel节点向a）阶段选出来的从节点执行

slaveof no one一直失败（例如该从节点此时出现故障），当此过程超过 failover-timeout时，则故障转移失败。 3）在b）阶段如果执行成功，Sentinel节点还会执行info命令来确认a） 阶段选出来的节点确实晋升为主节点，如果此过程执行时间超过failover- timeout时，则故障转移失败。 4）如果c）阶段执行时间超过了failover-timeout（不包含复制时间）， 则故障转移失败。注意即使超过了这个时间，Sentinel节点也会最终配置从 节点去同步最新的主节点。 （5）sentinel auth-pass 配置如下： sentinel auth-pass 如果Sentinel监控的主节点配置了密码，sentinel auth-pass配置通过添加 主节点的密码，防止Sentinel节点对主节点无法监控。 （6）sentinel notification-script 配置如下： sentinel notification-script sentinel notification-script的作用是在故障转移期间，当一些警告级别的 Sentinel事件发生（指重要事件，例如-sdown：客观下线、-odown：主观下 线）时，会触发对应路径的脚本，并向脚本发送相应的事件参数。 例如在/opt/redis/scripts/下配置了notification.sh，该脚本会接收每个 Sentinel节点传过来的事件参数，可以利用这些参数作为邮件或者短信报警 依据： #!/bin/sh # 获取所有参数 msg=$* # 报警脚本或者接口，将 msg 作为参数 exit 0 如果需要该功能，就可以在Sentinel节点添加如下配置（=mymaster）： sentinel notification-script mymaster /opt/redis/scripts/notification.sh 例如下面就是某个Sentinel节点对主节点做了主观下线（有关主观下线 的概念将在9.5节进行详细介绍）后脚本收到的参数： （7）sentinel client-reconfig-script 配置如下： sentinel client-reconfig-script sentinel client-reconfig-script的作用是在故障转移结束后，会触发对应路 径的脚本，并向脚本发送故障转移结果的相关参数。和notification-script类 似，可以在/opt/redis/scripts/下配置了client-reconfig.sh，该脚本会接收每个 Sentinel节点传过来的故障转移结果参数，并触发类似短信和邮件报警： #!/bin/sh # 获取所有参数 msg=$* # 报警脚本或者接口，将 msg 作为参数 exit 0 如果需要该功能，就可以在Sentinel节点添加如下配置（=mymaster）： sentinel client-reconfig-script mymaster /opt/redis/scripts/client-reconfig.sh 当故障转移结束，每个Sentinel节点会将故障转移的结果发送给对应的 脚本，具体参数如下： ·：主节点名。 ·：Sentinel节点的角色，分别是leader和observer，leader代表当前 Sentinel节点是领导者，是它进行的故障转移；observer是其余Sentinel节点。 ·：原主节点的ip地址。 ·：原主节点的端口。 ·：新主节点的ip地址。 ·：新主节点的端口。 例如以下内容分别是三个Sentinel节点发送给脚本的，其中一个是 leader，另外两个是observer： mymaster leader start 127.0.0.1 6379 127.0.0.1 6380 mymaster observer start 127.0.0.1 6379 127.0.0.1 6380 mymaster observer start 127.0.0.1 6379 127.0.0.1 6380 有关sentinel notification-script和sentinel client-reconfig-script有几点需要 注意： ·必须有可执行权限。 ·开头必须包含shell脚本头（例如#！/bin/sh），否则事件发 生时Redis将无法执行脚本产生如下错误： -script-error /opt/sentinel/notification.sh 0 2 ·Redis规定脚本的最大执行时间不能超过60秒，超过后脚本将被杀掉。 ·如果shell脚本以exit 1结束，那么脚本稍后重试执行。如果以exit 2或者 更高的值结束，那么脚本不会重试。正常返回值是exit 0。 ·如果需要运维的Redis Sentinel比较多，建议不要使用这种脚本的形式 来进行通知，这样会增加部署的成本。 2.如何监控多个主节点 Redis Sentinel可以同时监控多个主节点，具体拓扑图类似于图9-18。 配置方法也比较简单，只需要指定多个masterName来区分不同的主节点 即可，例如下面的配置监控monitor master-business-1（10.10.xx.1：6379）和 monitor master-business-2（10.10.xx.2：6379）两个主节点：

sentinel monitor master-business-1 10.10.xx.1 6379 2

sentinel down-after-milliseconds master-business-1 60000

sentinel failover-timeout master-business-1 180000

sentinel parallel-syncs master-business-1 1

sentinel monitor master-business-2 10.16.xx.2 6380 2

sentinel down-after-milliseconds master-business-2 10000

sentinel failover-timeout master-business-2 180000

sentinel parallel-syncs master-business-2 1

3.调整配置 和普通的Redis数据节点一样，Sentinel节点也支持动态地设置参数，而 且和普通的Redis数据节点一样并不是支持所有的参数，具体使用方法如 下：

sentinel set

表9-3是sentinel set命令支持的参数。

有几点需要注意一下： 1）sentinel set命令只对当前Sentinel节点有效。 2）sentinel set命令如果执行成功会立即刷新配置文件，这点和Redis普 通数据节点设置配置需要执行config rewrite刷新到配置文件不同。 3）建议所有Sentinel节点的配置尽可能一致，这样在故障发现和转移时 比较容易达成一致。 4）表9-3中为sentinel set支持的参数，具体可以参考源码中的sentinel.c的 sentinelSetCommand函数。 5）Sentinel对外不支持config命令。 9.2.5 部署技巧 到现在有关Redis Sentinel的配置和部署方法相信读者已经基本掌握了， 但在实际生产环境中都有哪些部署的技巧？本节将总结一下。 1）Sentinel节点不应该部署在一台物理“机器”上。 这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较 流行的容器，它们虽然有不同的IP地址，但实际上它们都是同一台物理机， 同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到 影响，为了实现Sentinel节点集合真正的高可用，请勿将Sentinel节点部署在 同一台物理机器上。 2）部署至少三个且奇数个的Sentinel节点。 3个以上是通过增加Sentinel节点的个数提高对于故障判定的准确性，因 为领导者选举需要至少一半加1个节点，奇数个节点可以在满足该条件的基 础上节省一个节点。有关Sentinel节点如何判断节点失败，如何选举出一个 Sentinel节点进行故障转移将在9.5节进行介绍。 4）只有一套Sentinel，还是每个主节点配置一套Sentinel？ Sentinel节点集合可以只监控一个主节点，也可以监控多个主节点，也 就意味着部署拓扑可能是图9-19和图9-20两种情况。

图9-20 多套Sentine节点集合

那么在实际生产环境中更偏向于哪一种部署方式呢，下面分别分析两种 方案的优缺点。 方案一：一套Sentinel，很明显这种方案在一定程度上降低了维护成 本，因为只需要维护固定个数的Sentinel节点，集中对多个Redis数据节点进 行管理就可以了。但是这同时也是它的缺点，如果这套Sentinel节点集合出 现异常，可能会对多个Redis数据节点造成影响。还有如果监控的Redis数据 节点较多，会造成Sentinel节点产生过多的网络连接，也会有一定的影响。 方案二：多套Sentinel，显然这种方案的优点和缺点和上面是相反的， 每个Redis主节点都有自己的Sentinel节点集合，会造成资源浪费。但是优点 也很明显，每套Redis Sentinel都是彼此隔离的。 运维提示 如果Sentinel节点集合监控的是同一个业务的多个主节点集合，那么使 用方案一、否则一般建议采用方案二。