Redis高可用架构【五】

1. Replication（主从复制）

1.1. 概述

  主从复制指的是主节点复制数据给从节点，主从复制是单向的，只能由主节点同步数据给从节点。

1.2. 主从复制作用

  (1). 数据冗余，实现数据的热备份，容灾。
  (2). 读写分离，主节点提供写服务，从节点提供读服务。
  (3). 故障转移，当主节点挂了，可以手动将从节点转为主节点继续提供服务，用于快速的故障恢复。

1.3. 主从复制的流程

1.4. 主从复制的拓扑结构

  主从复制有三种拓扑结构，分别为一主一从、一主多从、树状主从。

  (1). 一主一从

  该结构主节点负责写数据，并将数据同步给从节点，从而达到主从数据一致。

  (2). 一主多从

  该结构一主拥有多个从节点，主提供写服务，从提供读服务，适用读多的场景。该结构优点是多个从节点都可以提供读服务，提高了读的并发能力；缺点是主节点需要同时将数据同步给三个从节点，主节点压力大。

  (3). 树状主从

  该结构是对一主多从的补充，主节点主只需同步一次数据给它的从节点（slave1、slave2），从节点（slave1，slave2）再同步数据给它的子节点（slave1-1，slave2-1），这样就将降低了主节点同步数据的压力。

1.5. 一主多从部署

1.5.1. 环境说明

服务器名	IP
master	10.1.200.37
slave1	10.1.200.40
slave2	10.1.200.41

备注： 关闭防火墙

1.5.2. master-slave配置

  (1). master配置

#修改配置如下
bind 0.0.0.0 #设置监控地址，0.0.0.0表示监听所有的地址
daemonize yes  #设置后台启动
masterauth 123456 #设置master认证密码
requirepass 123456 #设置认证密码

  (2). slave1配置

#修改配置如下
bind 0.0.0.0 #设置监控地址，0.0.0.0表示监听所有的地址
replicaof 10.1.200.37 6379 #设置master的Ip和端口号
daemonize yes  #设置后台启动
masterauth 123456 #设置master认证密码
requirepass 123456 #设置认证密码

  (3). slave2配置

#修改配置如下
bind 0.0.0.0 #设置监控地址，0.0.0.0表示监听所有的地址
replicaof 10.1.200.37 6379 #设置master的Ip和端口号
daemonize yes  #设置后台启动
masterauth 123456 #设置master认证密码
requirepass 123456 #设置认证密码

  修改完master、slave1、slave2配置之后，重启master、slave1、slave2的redis服务。

1.5.3. 查看master、slave1、slave2的状态

  查看master状态如下图：

  查看slave1、slave2状态如下图：

1.5.4. 验证主从复制

  在master中设置key1=hyc：

  查看slave1、slave2的key1值：

2. Sentinel（哨兵机制）

2.1. 概述

  主从复制无法实现故障的自动发现与转移，因此redis实现了哨兵机制来解决这个问题。
  Redis Sentinel是一个分布式系统，为Redis提供高可用的解决方案。可以在一个架构中运行多个Sentinel进程，这些进程使用流言协议（gossip protocol）来接收关于主服务器是否下线的消息，并使用投票协议（agreement protocol）来决定是否执行自动故障转移，以及选举那个Sentinel进程来进行故障转移工作。

2.2. 哨兵机制的作用

  (1). 监听： 实时监听主从服务器的工作状态。
  (2). 故障转移： 若监听到主服务器发生故障，就选举从服务器作为主服务器，实现故障恢复。
  (3). 通知： 当客户端来访问主服务器时，通知客户端新的主服务器地址，通过脚本可以通知用户主服务器发生故障。

2.3 哨兵机制工作流程

  (1). sentinel系统监控所有的主从服务。
  (2). 当其中一个sentinel监控到master服务不可达时，就认定master主观失效（sdown：subjectively down）。
  (3). 监控到master失效的sentinel会询问其他的sentinel，若此时超过一半以上的sentinel认定master失效，则判定master客观失效（odown：objectively down）。
  (4). sentinel系统内部会进行一轮投票，选举出负责故障转移工作的sentinel。
  (5). 从slave节点中选择出一个节点作为主节点，命令：slaveof no one。
  (6). 将其他的slave节点变成新主节点的从节点，命令：slaveof new master。
  (6). 通知客户端新主节点的地址。
  (7). 旧主节点变为新主节点的从节点，命令：slaveof new master。

2.4. 哨兵配置文件详解

#master-name： redis主节点的名称
# ip： 主节点IP
# port： 主节点端口
# quorum： 哨兵判断主节点是否发生故障的票数，
# 若设置为2，表示2个哨兵认为主节点失效，主节点就客观失效。一般设置为哨兵数/2+1
sentinel monitor <master-name> <ip> <port> <quorum>

#哨兵会定定期向redis节点发生ping命令来判断redis是否可达，
#若超过指定的times毫秒内还未得到pong回复，则判断该redis不可达
sentinel down-after-milliseconds <master-name> <times>

#当redis主节点节点挂了后，哨兵会选出新的master，
#此时，剩余的slave会向新的master发起同步数据，这个设置表示允许并行同步的slave个数
sentinel parallel-syncs <master-name> <nums>

#进行故障转移时，如果超过设置的times毫秒数，表示故障转移失败
sentinel failover-timeout <master-name>  <times>

#如果redis主节点设置了密码，则需要进行这个配置
sentinel auth-pass <master-name> <password>

2.5. 哨兵部署（三个哨兵、一主二从）

2.5.1. 环境说明

服务器名	IP	redis端口	sentinel端口
master	10.1.200.37	6379	26379
slave1	10.1.200.40	6379	26379
slave2	10.1.200.41	6379	26379

   备注：
  (1). 关闭防火墙。
  (2). 安装redis请查看该博客：点击，
  (3). redis一主二从部署请查看该博客的1.5章节

2.5.2. sentinel配置

  三个sentinel的配置是一样的，分别进入到master、slave1、slave2的redis目录中，修改sentinel.conf。

修改配置如下：

port 26379 #端口

daemonize yes # 后台运行

#日志文件，验证哨兵配置是否成功，就通过该日志文件，一定要设置。
logfile "/usr/redis/logs/sentinel.log" 

#配置master服务信息
sentinel monitor mymaster 10.1.200.37 6379 2

#配置master认证密码，由于redis的slave也有可能成功master，因此也必须设置requirepass
sentinel auth-pass mymaster 123456

#关闭保护模式
protected-mode no

2.5.3. 启动Sentinel

  依次启动master、slave1、slave2的Sentinel。

cd /usr/redis/redis-6.0.8 #进入redis目录

#启动sentinel
./src/redis-sentinel ./sentinel.conf

  master的sentinel启动日志:

  slave1的sentinel启动日志:

  slave2的sentinel启动日志:

  当在三个sentinel日志中都能看到监控到了master、slave1、slave2以及另外俩个sentinel时，恭喜您，说明Redis哨兵模式配置成功。

2.5.3. 验证

  (1). 关闭slave1的redis服务
  sentinel监控到slave1的redis服务失效。

  (2). 启动slave1的redis服务
  sentinel监控到slave1的redis服务已启动并生效。

  (3). 关闭master服务
  sentinel监控到master服务已失效，并重新选举slave2作为新master，并将master及slave1修改为slave2的slave。

自此，哨兵模式的高可用验证成功！

3. Cluster（集群）

后续更新