Redis主从架构、哨兵集群原理实战

1.主从架构简介

  • 背景

    • 单机部署简单,但是可靠性低,且不能很好利用CPU多核处理能力
    • 生产环境必须要保证高可用,一般不可能单机部署
    • 读写分离是可用性要求不高、性能要求较高、数据规模小的情况
  • 目标

    • 读写分离,扩展主节点的读能力,分担主节点读压力
    • 容灾恢复,一旦主节点宕机,从节点作为主节点的备份可以随时顶上来
  • Redis主从架构介绍

    外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

2.Redis6.x主从复制一主二从实战搭建

  • 配置:6379端口为主节点,6380、6381为从节点

    # 新建配置文件目录
    mkdir -p /data/redis/master/data
    mkdir -p /data/redis/slave1/data
    mkdir -p /data/redis/slave2/data
    
    # 从节点开启只读模式(默认)
    replica-read-only yes
    # 从节点访问主节点的密码,和requirepass一样
    masterauth 123456
    # 哪个主节点进行复制
    replicaof 192.168.1.12 6379
    
  • 创建主节点配置文件vim /data/redis/master/data/master.conf

    bind 0.0.0.0
    port 6379
    daemonize yes
    requirepass 123456
    logfile "/usr/local/redis6/log/redis_master.log"
    dbfilename dump_master.rdb
    dir /usr/local/redis6/data
    appendonly yes
    appendfilename "appendonly_master.aof"
    masterauth 123456
    
  • 创建从节点1配置文件vim /data/redis/slave1/data/slave1.conf

    bind 0.0.0.0
    port 6380
    daemonize yes
    requirepass 123456
    logfile "/usr/local/redis6/log/redis_slave1.log"
    dbfilename dump_slave1.rdb
    dir /usr/local/redis6/data
    appendonly yes
    appendfilename "appendonly_slave1.aof"
    masterauth 123456
    replicaof 192.168.1.12 6379
    
  • 创建从节点2配置文件vim /data/redis/slave2/data/slave2.conf

    bind 0.0.0.0
    port 6381
    daemonize yes
    requirepass 123456
    logfile "/usr/local/redis6/log/redis_slave2.log"
    dbfilename dump_slave2.rdb
    dir /usr/local/redis6/data
    appendonly yes
    appendfilename "appendonly_slave2.aof"
    masterauth 123456
    replicaof 192.168.1.12 6379
    
  • 防火墙记得关闭,或者开放对应的端口;云服务器记得开放网络安全组

  • 启动服务

    # 启动主节点
    /usr/local/redis6/bin/redis-server /data/redis/master/data/master.conf
    # 启动从节点1
    /usr/local/redis6/bin/redis-server /data/redis/slave1/data/slave1.conf
    # 启动从节点2
    /usr/local/redis6/bin/redis-server /data/redis/slave2/data/slave2.conf
    
  • 客户端连接后info replication查看状态

3.主从架构-复制读写分离原理解析

  • 主从复制分两种(主从刚连接的时候,进行全量同步;全同步结束后,进行增量同步)

    • 全量复制
      • master服务器会开启一个后台进程用于将Redis中的数据生成一个RDB文件
      • 主服务器会缓存所有接收到的来自客户端的写命令,当后台保存进程处理完毕后,会将该RDB文件传递给slave服务器
      • slave服务器会将RDB文件保存在磁盘并通过读取该文件将数据加载到内存
      • 在此之后master服务器会将在此期间缓存的命令通过Redis传输协议发送给slave服务器
      • 然后slave服务器将这些命令依次作用于自己本地的数据集上,最终达成数据的一致性
    • 增量复制
      • slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程
      • 服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令
  • 特点

    • 主从复制对于 主/从 Redis服务器来说是非阻塞的,所以同步期间都可以正常处理外界请求
    • 一个主Redis可以含有多个从Redis,每个从Redis可以接收来自其他从Redis服务器的连接
    • 从节点不会让key过期,而是主节点的key过期删除后,成为del命令传输到从节点进行删除
      • 从节点开启sync看日志
  • 加速复制

    • 完全重新同步需要在磁盘上创建一个RDB文件,然后加载这个文件以便为从服务器发送数据
    • 在比较低速的磁盘,这种操作会给主服务器带来较大的压力
    • 新版支持无磁盘的复制,子进程直接将RDB通过网络发送给从服务器,不使用磁盘作为中间存储
    • repl-diskless-sync yes(默认是no)
  • 主从断开重连

    • 如果遭遇连接断开,重新连接之后可以从中断处继续进行复制,而不必重新同步
    • 2.8版本后,部分重新同步这个新特性内部使用psync命令,旧的实现中使用sync命令

4.Sentinel哨兵模式

  • 哨兵模式介绍

    • Redis提供了哨兵的命令,是一个独立的进程
    • 原理:哨兵通过发送命令给多个节点,等待Redis服务器响应,从而监控运行的多个Redis实例的运行情况
    • 当哨兵监测到master宕机,会自动将slave切换成master通过通知其他的从服务器,修改配置文件切换主机
  • Sentinel三大工作任务

    • 监控(Monitoring)
      • Sentinel会不断地检查你的主服务器和从服务器是否运行正常
    • 提醒(Notification)
      • 当被监控的某个Redis服务器出现问题时,Sentinel可以通过API向管理员或者其他应用程序发送通知
    • 自动故障迁移(Automatic failover)
      • 当一个主服务器不能正常工作时,Sentinel会开始一次自动故障迁移操作,它会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务区改为复制新的主服务器
      • 当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器代替失效服务器
  • 问题:一个哨兵进程对Redis服务器进行监控,可能会出现问题;一般是使用多个哨兵进行监控,各个哨兵之间还会进行监控,形成多哨兵模式

  • 多哨兵模式下线名词介绍

    • 主观下线(Subjectively Down,简称SDOWN)
      • 是单个Sentinel实例对服务器做出的下线判断,比如网络问题接收不到通知等
      • 一个服务器没有在down-after-milliseconds选项所指定的时间内,对向它发送PING命令的Sentinel返回一个有效回复(valid reply),那么Sentinel就会将这个服务器标记为主观下线
    • 客观下线(Objectively Down,简称ODOWN)
      • 指的是多个Sentinel实例在对同一个服务器做出SDOWN判断,并且通过Sentinel is-master-down-by-addr命令互相交流之后,得出的服务器下线判断
      • 一个Sentinel可以通过向另一个Sentinel发送Sentinel is-master-down-by-addr命令来询问对方是否认为给定的服务器已下线
      • 客观下线条件只适用于主服务器
    • 仲裁(qurum)
      • Sentinel在给定的时间范围内,从其他Sentinel那里接收到了【足够数量】的主服务器下线报告,那么Sentinel就会将主服务器的状态从主观下线改变为客观下线
      • 这个【足够数量】就是配置文件里面的值,一般是Sentinel个数的一半+1,比如3个Sentinel则就设置为2
      • down-after-milliseconds是一个哨兵在超过规定时间依旧没有得到响应后,会自己认为主机不可用
      • 当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时,就会发起一次投票,进行failover

5.Sentinel哨兵模式流程解析和实战

  • 核心流程解析

    • 每秒ping,超过时间不响应则认为主观下线
    • 满足多个主观下线则认为是客观下线
    • 投票选择主节点
    • 如果没有足够的节点同意master下线,则状态会被移除
  • 环境准备

    • 配置3个哨兵,每个哨兵的配置都是一样的
    • 启动顺序,先启动主节点再启动从节点,最后启动3个哨兵
    • 哨兵端口记得开放
    # 不限制IP
    bind 0.0.0.0
    # 后台运行
    daemonize yes
    # 配置监听的主服务器,mymaster代表服务器的名称,自定义;2代表只有两个或两个以上的哨兵认为主服务器不可用的时候才会进行failover操作
    sentinel monitor mymaster 192.168.1.12 6379 2
    # 定义服务的密码
    sentinel auth-pass mymaster 123456
    # 超过5秒master还没有连接上,则认为master已经停止
    sentinel down-after-milliseconds mymaster 5000
    # 如果该时间内没完成failover操作,则认为本次failover失败
    sentinel failover-timeout mymaster 30000
    
  • vim /data/redis/sentinel1.conf

    port 26379
    bind 0.0.0.0
    daemonize yes
    sentinel monitor mymaster 192.168.1.12 6379 2
    sentinel auth-pass mymaster 123456
    sentinel down-after-milliseconds mymaster 5000
    sentinel failover-timeout mymaster 30000
    pidfile /var/run/redis_sentinel1.pid
    logfile "/usr/local/redis6/log/redis_sentinel1.log"
    dir /usr/local/redis6/data
    
  • vim /data/redis/sentinel2.conf

    port 26380
    bind 0.0.0.0
    daemonize yes
    sentinel monitor mymaster 192.168.1.12 6379 2
    sentinel auth-pass mymaster 123456
    sentinel down-after-milliseconds mymaster 5000
    sentinel failover-timeout mymaster 30000
    pidfile /var/run/redis_sentinel2.pid
    logfile "/usr/local/redis6/log/redis_sentinel2.log"
    dir /usr/local/redis6/data
    
  • vim /data/redis/sentinel3.conf

    port 26381
    bind 0.0.0.0
    daemonize yes
    sentinel monitor mymaster 192.168.1.12 6379 2
    sentinel auth-pass mymaster 123456
    sentinel down-after-milliseconds mymaster 5000
    sentinel failover-timeout mymaster 30000
    pidfile /var/run/redis_sentinel3.pid
    logfile "/usr/local/redis6/log/redis_sentinel3.log"
    dir /usr/local/redis6/data
    
  • 启动哨兵集群

    /usr/local/redis6/bin/redis-server /data/redis/sentinel1.conf --sentinel
    /usr/local/redis6/bin/redis-server /data/redis/sentinel2.conf --sentinel
    /usr/local/redis6/bin/redis-server /data/redis/sentinel3.conf --sentinel
    
  • 优点:主从可以自动切换,可用性更高

  • 缺点:主从切换会丢失短暂数据;主节点的写能力和存储能力受限

6.SpringCloud整合Redis哨兵模式

  • 配置文件

    spring:
      redis:
        password: 123456
        sentinel:
          master: mymaster
          nodes: 192.168.1.12:26379,192.168.1.12:26380,192.168.1.12:26381
    
  • 22
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
Redis是一个基于内存的高性能键值存储系统,支持多种数据结构。在实际应用中,为了保证Redis的高可用性,可以采用主从复制、哨兵集群等方式。 1. 主从复制 主从复制的原理是将一台Redis服务器的数据复制到其他多个Redis服务器上,其中主节点是读写节点,从节点只能读取数据。主节点将自己的数据变化通过异步的方式发送给从节点,从而实现数据同步。主从复制可以提高Redis的可用性和性能,并且可以支持读写分离,从而减轻主节点的压力。 2. 哨兵 哨兵是一种特殊的Redis服务器,用于监控主从复制的状态,并在主节点故障时自动将从节点切换为主节点。哨兵可以自动发现Redis服务器,并监控它们的状态,当发现主节点宕机时,会通过投票的方式选举新的主节点,并将从节点切换为新的主节点的从节点。哨兵可以保证Redis的高可用性,并且可以自动完成主从切换,从而减少人工干预的工作量。 3. 集群 Redis集群是一种分布式的Redis系统,可以将多个Redis服务器组成一个逻辑上的整体,并支持横向扩展。Redis集群采用分片的方式存储数据,将数据分散到多个节点上,从而提高Redis的可用性和性能。Redis集群可以自动完成节点的发现和管理,并支持数据的备份和恢复,从而保证Redis的高可用性和数据的安全性。 总之,主从复制、哨兵集群Redis实现高可用性的重要手段,可以提高Redis的可用性和性能,并保证数据的安全性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

水宝的滚动歌词

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值