图解Redis主从复制与Redis哨兵机制

2023-12-04 0 947
目录
  • 前言
  • 一、Redis复制是什么?
  • 二、Redis复制能干嘛?
  • 三、Redis复制的缺点
    • 1、复制延迟
    • 2、master宕机
  • 四、乐观复制策略
    • 五、Redis复制常用命令
      • 1、info replication
      • 2、replicaof 主库Ip 主库port
      • 3、slaveof 主库IP 主库port
      • 4、slaveof no one
    • 六、Redis复制工作流程
      • 七、Redis哨兵是什么?
        • 1、Redis哨兵的作用
        • 2、使用哨兵的注意事项:
      • 八、实战演练
        • 1、搭建3个哨兵服务器
        • 2、sentinel.conf参数选项说明
      • 九、哨兵运行流程和选举原理
        • 1、主观下线
        • 2、客观下线
        • 3、选举master三步走:
          • (1)先选出一个master服务器
          • (2)其它slave服务器连接到master服务器
          • (3)如果旧master服务器恢复正常了,也要成为新master服务器的slave从服务器。

      前言

      今天分享一下Redis的持久化、事务、管道相关的知识点,实现快速入门,丰富个人简历,提高面试level,给自己增加一点谈资,秒变面试小达人,BAT不是梦。

      图解Redis主从复制与Redis哨兵机制

      一、Redis复制是什么?

      Redis复制就是主从复制,当主服务器数据发生变化时,自动将新的数据同步到从数据库。

      读数据库可以进行读写操作,从数据库一般指用于读操作。

      Redis复制可以保证主数据库崩溃时可以进行数据恢复。

      二、Redis复制能干嘛?

    • 读写分离
    • 容灾恢复
    • 数据备份
    • 水平扩容支撑高并发
    • 三、Redis复制的缺点

      1、复制延迟

      由于所有的写操作都发生在master数据库,然后同步到slave数据库中,所以会有一定的数据延迟,当系统负担过重时,延迟越大,slave机器的增加也会增加数据延迟的时间。

      2、master宕机

      如果master宕机了,默认情况下不会将salve数据库自动升级为master数据库。

      四、乐观复制策略

      Redis采用乐观复制策略,容忍一段时间内主从数据库不一致,但保证最终一致性。这个策略保证了性能,在复制的时候,主数据库不会阻塞,可以继续提供服务。

      五、Redis复制常用命令

      1、info replication

      查看节点的主从关系和配置信息。

      2、replicaof 主库Ip 主库port

      在从数据库的redis.conf中配置。

      3、slaveof 主库IP 主库port

      在运行期间修改slave节点的信息,如果该数据库已经是其它主数据库的从数据库了,那么它会停止与其的主从关系,转而成为新配置的主库的从数据库。

      4、slaveof no one

      使当前数据库停止与其它数据库的同步,升级为主数据库。

      六、Redis复制工作流程

      1、slave启动成功后,会连接master数据库,发送一个sync命令,同步数据;如果是第一次连接,则会进行一次全量复制,slave自身的数据会被master数据覆盖清除;

      2、master数据库收到sync命令后,通过RDB开始保存快照,同时将所有接收到的用于修改数据库的命令缓存起来,master数据库执行完RDB持久化后,master将RBD文件和所有缓存的命令发送到所有的slave数据库,完成一次数据同步;

      3、slave收到RDB文件和命令缓存后,将其加载到内存中,从而完成复制初始化;

      4、repl-ping-replica-period 10,表示master发出ping包的周期默认是10秒;

      5、完成首次数据全量同步后,master继续将新的收集到的修改命令定期传给slave数据库,完成数据同步;

      6、如果从机重启了,master的backlog中会记录offset,master会将offset后面的数据复制给slave。

      7187:C 14 Mar 22:14:24.106 # nzbc Redis is starting nzbc
      7187:C 14 Mar 22:14:24.107 # Redis version=6.0.8, bits=64, commit=00000000, modified=0, pid=7187, just started
      7187:C 14 Mar 22:14:24.108 # Configuration loaded
      7188:S 14 Mar 22:14:24.110 * Increased maximum number of open files to 10032 (it was originally set to 256).
      _._
      _.-“__ \’\’-._
      _.-“ `. `_. \’\’-._ Redis 6.0.8 (00000000/0) 64 bit
      .-“ .-“`. “`\\/ _.,_ \’\’-._
      ( \’ , .-` | `, ) Running in standalone mode
      |`-._`-…-` __…-.“-._|\’` _.-\’| Port: 6380
      | `-._ `._ / _.-\’ | PID: 7188
      `-._ `-._ `-./ _.-\’ _.-\’
      |`-._`-._ `-.__.-\’ _.-\’_.-\’|
      | `-._`-._ _.-\’_.-\’ | http://redis.io
      `-._ `-._`-.__.-\’_.-\’ _.-\’
      |`-._`-._ `-.__.-\’ _.-\’_.-\’|
      | `-._`-._ _.-\’_.-\’ |
      `-._ `-._`-.__.-\’_.-\’ _.-\’
      `-._ `-.__.-\’ _.-\’
      `-._ _.-\’
      `-.__.-\’

      7188:S 14 Mar 22:14:24.120 # Server initialized
      7188:S 14 Mar 22:14:24.114 * DB loaded from disk: 0.000 seconds
      7188:S 14 Mar 22:14:24.122 * Before turning into a slave, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
      7188:S 14 Mar 22:14:24.122 * Ready to accept connections
      7188:S 14 Mar 22:14:24.123 * Connecting to MASTER 127.0.0.1:6379
      7188:S 14 Mar 22:14:24.123 * MASTER <-> SLAVE sync started
      7188:S 14 Mar 22:14:24.123 * Non blocking connect for SYNC fired the event.
      7188:S 14 Mar 22:14:24.124 * Master replied to PING, replication can continue…
      7188:S 14 Mar 22:14:24.124 * Trying a partial resynchronization (request 9b3cs5w9g6x3004fa9a0999361035b71ecf70ab4:30783).
      7188:S 14 Mar 22:14:24.130 * Full resync from master: cb4as85df693ad62f09ce4f486e0d43ec8f36334:0
      7188:S 14 Mar 22:14:24.130 * Discarding previously cached master state.
      7188:S 14 Mar 22:14:24.163 * MASTER <-> SLAVE sync: receiving 5484 bytes from master
      7188:S 14 Mar 22:14:24.165 * MASTER <-> SLAVE sync: Flushing old data
      7188:S 14 Mar 22:14:24.165 * MASTER <-> SLAVE sync: Loading DB in memory
      7188:S 14 Mar 22:14:24.167 * MASTER <-> SLAVE sync: Finished with success

      七、Redis哨兵是什么?

      Redis提供了哨兵sentinel机制来监控Redis的性能,如果主数据库宕机了,根据投票数自动将某一个从数据库提升为主数据库,继续对外提供服务。

      1、Redis哨兵的作用

      图解Redis主从复制与Redis哨兵机制

    • 主从监控,监控主从数据库是否运行正常;
    • 消息通知,哨兵可以将故障信息发送给客户端;
    • 故障转移,如果master异常。哨兵会进行主备切换,将其中一个slave转为master;
    • 配置中心,客户端通过连接哨兵获取Redis服务集群的主节点信息;
    • 2、使用哨兵的注意事项:

      图解Redis主从复制与Redis哨兵机制

      八、实战演练

      1、搭建3个哨兵服务器

      监控Redis主从服务器,不存放数据。

      图解Redis主从复制与Redis哨兵机制

      2、sentinel.conf参数选项说明

      bind 0.0.0.0
      daemonize yes
      protected-mode no
      port 6391
      logfile \”/myredis/sentinel1.log\”
      pidfile /var/run/redis-sentinel6391.pid
      dir /myredis
      sentinel monitor mymaster 127.0.0.1 6379 2
      sentinel auth-pass mymaster 123456

      图解Redis主从复制与Redis哨兵机制

      设置要监控的master服务器,quorum表示至少有几个哨兵认为客观下线,同意故障转移的法定票数,因此哨兵服务器一般为奇数个。

      sentinel monitor <master-name> 127.0.0.1 6379 <quorum>。

      master服务器设置了密码:

      sentinel auth-pass <master-name> <password>

      通过命令,完成哨兵sentinel的启动,两种方式,任选其一:

    • redis-sentinel /path/to/sentinel.conf
    • redis-server /path/to/sentinel.conf –sentinel
    • 九、哨兵运行流程和选举原理

      当一个主从配置中的master失效后,sentinel会选举出一个新的master用于接替原master的工作,其它slave服务器自动指向新master,实现数据同步。

      1、主观下线

      指定多少毫秒之后,主节点没有应答哨兵,此时哨兵会主观上认为主节点已经下线。

      sentinel down-after-millisecnds <master-name> <millisecnds>

      2、客观下线

      多个哨兵sentinel进行投票,根据投票结果才能确认一个master客观上已经宕机。

      3、选举master三步走:

      (1)先选出一个master服务器

      图解Redis主从复制与Redis哨兵机制

      当master数据库宕机后,各个哨兵sentinel节点会进行协商,先通过Raft算法选举出一个领导者哨兵节点,再由领导者进行master的选举。

      根据Redis.conf中,优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)。复制偏移位置offset最大的从节点;最小Run ID的从节点

      (2)其它slave服务器连接到master服务器

      执行slaveof no one命令会选举出新的master,并通过slaveof命令将其它从节点成为新master服务器的从节点。

      (3)如果旧master服务器恢复正常了,也要成为新master服务器的slave从服务器。

      到此这篇关于图解Redis主从复制Redis哨兵机制的文章就介绍到这了,更多相关Redis主从复制与哨兵机制内容请搜索悠久资源以前的文章或继续浏览下面的相关文章希望大家以后多多支持悠久资源!

      收藏 (0) 打赏

      感谢您的支持,我会继续努力的!

      打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
      点赞 (0)

      悠久资源 Redis 图解Redis主从复制与Redis哨兵机制 https://www.u-9.cn/database/redis/67852.html

      常见问题

      相关文章

      发表评论
      暂无评论
      官方客服团队

      为您解决烦忧 - 24小时在线 专业服务