Redis主从复制、哨兵

redis包含三种集群策略

  • 主从复制:主数据库主要负责写操作,从数据库负责读操作,也就是读写分离。
  • 哨兵:监控主从复制中主库状态,如果主库宕机,则将其中一个从库升级为主库,保证系统正常运行。
  • 集群

主从复制:

在主从复制中,数据库分为俩类,主数据库(master)和从数据库(slave)。其中主从复制有如下特点:

  1. 主数据库可以进行读写操作,当读写操作导致数据变化时会自动将数据同步给从数据库
  2. 从数据库一般都是只读的,并且接收主数据库同步过来的数据
  3. 一个master可以拥有多个slave,但是一个slave只能对应一个master 

主从复制工作机制:

当slave启动后,主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照(RDB持久化)和缓存保存快照这段时间的命令,然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。

复制初始化后,master每次接收到的写命令都会同步发送给slave,保证主从数据一致性。 

主从复制实现方式:

主从复制有两种实现方式:一种是命令行方式,另一种是配置文件方式。

1、命令行方式实现主从复制:

(1)首先启动三个节点6379、6380、6381,这之前要先修改对应redis.conf文件中的配置:daemonize yes,即后台启动redis服务。

redis-server redis6379.conf  #指定当前节点的配置文件
redis-cli -p 6379        # 开启当前redis服务的客户端,并指定端口号
redis-server redis6380.conf  
redis-cli -p 6380
redis-server redis6381.conf  
redis-cli -p 6381

这时我们开启了三个redis服务和对应的客户端,且三个窗口相同:

这时分别在三个窗口中输入: info replication

可以看到这时三个节点都是master节点,且没有salve节点。

(2)将6380、6381设置为6379的从节点

分别在6380和6381的客户端输入命令:

slaveof 127.0.0.1 6379

这时分别在6379、6380、6381客户端上输入:info replication

6379:(这里两个从节点的IP不同是因为redis.conf中bind绑定的IP地址不同)

6380、6381

至此主从复制模式创建完成。这里有几点需要注意:

  • master节点中的所有数据都可以在从节点中获取到,不论这些数据是在创建主从关系之后还是之前添加进库中的。
  • salve节点只能进行读操作,不能进行写操作
  • 如果slave节点宕机后重启,则重启后的节点不再是slave节点,如果需要将其继续设为slave节点,需要重新执行salveof命令。
  • 如果master节点宕机后重启,则重启后的节点依然是集群的master节点。

2、修改配置文件实现主从复制

这里我们依然启动6379、 6380、 6381三个节点,6379为master节点,其它为slave节点。

修改630和6381的配置文件,REPLICATION下的slaveof配置

关于其它配置的含义可以参考博文:Redis配置文件详解(Redis 4.0.8)

这里slaveof配置和命令行中输入的slaveof命令相同,相当于在slave节点客户端启动的时候就执行了该命令。

修改完配置后,分别启动6380、 6381两个服务和客户端

redis-server redis6380.conf
redis-cli -p 6380


redis-server redis6381.conf
redis-cli -p 6381

这是在6380、 6381客户端执行:info replication命令:

可以看出,两个配置后的slave节点,启动后直接附属到master节点上了,不论master节点是否存在。

这时我们启动master节点6379:,执行:info application命令:

哨兵模式:

哨兵的作用是监控 redis系统的运行状况,他的功能如下:

  • 监控主从数据库是否正常运行
  • master出现故障时,自动将slave转化为master
  • 多哨兵配置的时候,哨兵之间也会自动监控
  • 多个哨兵可以监控同一个redis

哨兵工作机制:

哨兵进程启动时会读取配置文件的内容,通过sentinel monitor master-name ip port quorum查找到master的ip端口。一个哨兵可以监控多个master数据库,只需要提供多个该配置项即可。同时配置文件还定义了与监控相关的参数,比如master多长时间无响应即即判定位为下线。

哨兵启动后,会与要监控的master建立俩条连接:

  • 一条连接用来订阅master的_sentinel_:hello频道与获取其他监控该master的哨兵节点信息
  • 另一条连接定期向master发送INFO等命令获取master本身的信息

与master建立连接后,哨兵会执行三个操作,这三个操作的发送频率都可以在配置文件中配置:

  • 定期向master和slave发送INFO命令
  • 定期向master个slave的_sentinel_:hello频道发送自己的信息
  • 定期向master、slave和其他哨兵发送PING命令

通过INFO命令,哨兵可以获取主从数据库的最新信息,并进行相应的操作,比如角色变更等。

接下来哨兵向主从数据库的_sentinel_:hello频道发送信息与同样监控这些数据库的哨兵共享自己的信息,发送内容为哨兵的ip端口、运行id、配置版本、master名字、master的ip端口还有master的配置版本。这些信息有以下用处:

  • 其他哨兵可以通过该信息判断发送者是否是新发现的哨兵,如果是的话会创建一个到该哨兵的连接用于发送PIN命令。
  • 其他哨兵通过该信息可以判断master的版本,如果该版本高于直接记录的版本,将会更新。
  • 当实现了自动发现slave和其他哨兵节点后,哨兵就可以通过定期发送PING命令定时监控这些数据库和节点有没有停止服务。发送频率可以配置,但是最长间隔时间为1s,可以通过sentinel down-after-milliseconds mymaster 600设置。

如果被ping的数据库或者节点超时未回复,哨兵任务其主观下线。如果下线的是master,哨兵会向其他哨兵点发送命令询问他们是否也认为该master主观下线,如果达到一定数目(即配置文件中的quorum)投票,哨兵会认为该master已经客观下线,并选举领头的哨兵节点对主从系统发起故障恢复。

哨兵认为master客观下线后,故障恢复的操作需要由选举的领头哨兵执行,选举采用Raft算法:

  • 发现master下线的哨兵节点(我们称他为A)向每个哨兵发送命令,要求对方选自己为领头哨兵
  • 如果目标哨兵节点没有选过其他人,则会同意选举A为领头哨兵
  • 如果有超过一半的哨兵同意选举A为领头,则A当选
  • 如果有多个哨兵节点同时参选领头,此时有可能存在一轮投票无竞选者胜出,此时每个参选的节点等待一个随机时间后再次发起参选请求,进行下一轮投票精选,直至选举出领头哨兵

选出领头哨兵后,领头者开始进行故障恢复,从出现故障的master的从数据库中挑选一个来当选新的master,规则如下:

  • 所有在线的slave中选择优先级最高的,优先级可以通过slave-priority配置
  • 如果有多个最高优先级的slave,则选取复制偏移量最大(即复制越完整)的当选
  • 如果以上条件都一样,选取id最小的slave

挑选出需要继任的slaver后,领头哨兵向该数据库发送命令使其升格为master,然后再向其他slave发送命令接受新的master,最后更新数据。将已经停止的旧的master更新为新的master的从数据库,使其恢复服务后以slave的身份继续运行。 

哨兵模式实现:

1、新建或修改一个sentinel.conf文件,添加如下配置:

sentinel monitor masterName masterIP masterPort num

sentinel monitor 命令后面的参数代表的含义分别为:主节点名(任意),主节点IP ,主节点端口号,票数(用于重现选取主节点)。

这里我们将配置设置为:sentinel monitor master6379 127.0.0.1 6379 1

2、启动redis的三个节点,注意这里的三个节点已经在配置文件中配置了主从关系。

3、启动哨兵模式:

redis-sentinel sentinel.conf

这是redis的三个节点依然是以6379 为master节点,6380和6381是slave节点。

4、验证哨兵模式,将master节点6379停掉:shutdown

停掉6379节点后,观察哨兵模式开启的界面,并在6380和6381中执行:info replication命令。

637刚刚停止时,可能6380和6381依然是附属在6379下的从节点,但是当哨兵模式探测到6379宕机后,会从存活的slave节点中重新选择master节点,并分配主从关系。

而这时,6380节点下的:info replication 输出的信息为:

而6380节点下的:info replication 输出的信息为:

5、重新启动6379节点,查看主从关系:

可以看到6379重新启动后,不再是master节点,而是slave节点,而他的master是哨兵模式选中的6381节点。

 

综合以上可以看出,主从复制可以提高redis的性能,而哨兵模式则保证了了主从复制的高可用性。

发布了74 篇原创文章 · 获赞 19 · 访问量 5万+

猜你喜欢

转载自blog.csdn.net/zhoushimiao1990/article/details/98782230