并发编程之Redis:Redis主从架构及哨兵架构

Posted 码霸霸

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了并发编程之Redis:Redis主从架构及哨兵架构相关的知识,希望对你有一定的参考价值。

并发编程之Redis:Redis主从架构及哨兵架构

思考

  • 如何让Redis能够带来更高的QPS? 十万+?百万+?亿并发?一个系统、一个软件的并发数,很难给他一个具体的值,因为有很多的因素会影响到;比如Redis,你存的单Key的数据量,保存数据的数据结构,CPU的性能,磁盘的性能等等...当我们需要承载更高访问量的时候,很容易想到的就以下的方式

redis扩容方式

  • 搞更好的机器(垂直扩容)

    • 优点:简单,只需要花钱配置一台更好的机器就可以了

    • 缺点:成本高,性能越好,机器越贵;很容易达到瓶颈,假如最好的单机能承载20万QPS,那我现在要达到40万,怎么办?;

  • 搞更多的机器(水平扩容)

    • 优点:成本低,很容易水平扩展,随便搞台机器,加上去就好了,按需添加;

    • 缺点:使用,维护成本更高,需要管理一个大的集群,需要维护更多的机器。

  • Redis针对扩展提供的方案

    • 方案一:主从架构(master slave)

    • 方案二:集群架构(cluster)

主从架构(master slave)

  • 基本结构图并发编程之Redis:Redis主从架构及哨兵架构

  • 作用

    • 实现读写分离,降低单点服务的压力;

    • 方便水平扩展,带来更高的吞吐量;

    • 为Redis的高可用打好基础;就单纯的主从架构是没法做到高可用的;

  • 特点

    1. master处理完消息之后,就立马对客户端进行响应

    2. 数据是通过异步的方式从master同步到slave

    3. slave复制数据的时候,不会阻塞master的服务

    4. slave复制数据的时候,也不会阻塞自己的读服务

    5. slave复制完成之后,将新的数据加载到内存期间,会将对外服务暂停

主从架构Redis的搭建

  • Redis安装(单机版) https://lupf.cn/articles/2020/04/06/1586153137483.html 当主从所有机器都按上面的方式安装好Redis,且保证Redis本机下能正常启动之后,就可以按以下当时做主从配置了

  • 主节点配置调整(6379.conf)

    // 1. 第一个参数 bind 就是redis绑定的ip,默认为127.0.0.1;意味着只能本机访问,其他机器访问不了
    // 将本机的ip添加进去
    bind 192.168.1.140 127.0.0.1

    // 2. 第二个参数,从节点只读,默认就是打开的,确认一下
    slave-read-only yes

    // 3. redis的认证密码
    requirepass 123456789
    // 设置之后,客户端可以通过-a参数指定密码连接:redis-cli -a 123456789
    // 或者进去之后通过指令:auth 123456789 进行认证

    // 4. redis的master节点的连接口令
    masterauth 123456789
  • 从节点配置调整

    // 从节点添加以上主节点的所有配置

    // 额外添加项
    // 设置主节点的ip端口
    // slaveof <masterip> <masterport>
    slaveof 192.168.1.140 6379
  • 检查防火墙

    // 第一种方式,将防火墙关了

    // 第二种方式,添加端口开放;如果防火墙开着,又不配置端口开放,从节点将无法连接主节点
    iptables -A INPUT -ptcp --dport 6379 -j ACCEPT
  • 启动服务;优先启动主节点,再次依次启动从节点并发编程之Redis:Redis主从架构及哨兵架构

  • 主备状态查看

    info replication

    并发编程之Redis:Redis主从架构及哨兵架构

  • 主备测试

    // 主节点修改,从节点查询

    并发编程之Redis:Redis主从架构及哨兵架构

  • 压测

    // redis自带提供了压测工具,位于:redis-4.0.1/src 下
    redis-benchmark -h 192.168.1.140

主从架构存在的问题

  • 问题分析 是不是我们做到上面这种架构之后,咱就可以应对基于redis的高并发、高可用了呢?其实不然!上面的这种架构只是解决了高并发的问题,一旦不够了,水平加上机器(slave)就可以了,但是还是会存在以下的问题:

    • 如果是海量数据的Redis存储,那就只能使用后面要说的Redis集群(Redis Cluster)

    • 如何解决呢?能不能master挂了之后,某个slave来接管呢?当然是可以的,这就是下面要说的 哨兵模式

    • 问题一,高可用 上面的架构并没有解决高可用的问题,假如说Master挂了,整个Redis等于是不可能了;虽然说还有从节点在,但是从节点只能读数据,没办法写数据;redis既然主要是用来做缓存的,缓存却没法更新了,那就等于是没法正常使用了;

    • 问题二,无法应对海量数据 从上面的测试来看,master和slave的数据是一样的,slave保存的是master的一个备份;这样也就意味着,master能存储多少数据,整个主从架构也就只能存储多少数据?无法满足大数据量的要求。

哨兵(sentinal)架构

  • 哨兵的功能

    1. 集群监控;负责监控master和slave是否健康存在

    2. 消息通知;当存在节点不可用时,哨兵将消息通知给管理员

    3. 故障迁移;当master挂了之后,哨兵会选举一个slave替代master,实现故障迁移

哨兵部署
  • 创建配置

    // 创建用于保存哨兵配置文件的目录
    mkdir -p /etc/sentinal
    mkdir -p /var/sentinal/26379

    // 拷贝哨兵
    cp /usr/local/redis-4.0.1/sentinel.conf /etc/sentinal/26379.conf

    vim /etc/sentinal/26379.conf

    // 修改一下配置
    // 以守护进程允许
    daemonize yes
    # 绑定的端口
    port 26379
    # 绑定的ip 本机IP
    bind 192.168.1.140
    # 持久化的目录
    dir /var/sentinal/26379/
    # 这里需要注意的是 所有哨兵节点的IP都是填master的地址
    sentinel monitor mymaster 192.168.1.142 6379 2
    sentinel down-after-milliseconds mymaster 30000
    sentinel failover-timeout mymaster 60000
    sentinel parallel-syncs mymaster 1
    sentinel auth-pass mymaster 123456789
    // 在其他两台机器上采用以上相同的方式配置,除了IP配置成本机
    • monitor 参数说明

      mymaster 给监控的master设置一个别名;一个哨兵可以监控多个master
      192.168.1.142 标识当前主节点
      quorum
      1. 至少达到多少个哨兵达成一致,认为master挂了,才做故障迁移
      2. quorum只是作为一个故障识别,最终的选举还是有哨兵集群一起完成的
    • down-after-milliseconds

      超过多久没连上master,哨兵就主观认为他挂了
    • failover-timeout

      故障迁移,切换新的master的超时时间
    • parallel-syncs

      当新的master选出来之后,每次有多少个slaves去连接master做同步
  • 启动

    redis-sentinel /etc/sentinal/26379.conf
    // 或者
    redis-server /etc/sentinal/26379.conf --sentinel

    并发编程之Redis:Redis主从架构及哨兵架构

  • Sentinel命令

    • PING sentinel回复PONG

    • SENTINEL masters 显示被监控的所有master以及它们的状态.

    • SENTINEL master <master name> 显示指定master的信息和状态

    • SENTINEL slaves <master name> 显示指定master的所有slave以及它们的状态

    • SENTINEL get-master-addr-by-name <master name> 返回指定master的ip和端口,如果正在进行failover或者failover已经完成,将会显示被提升为master的slave的ip和端口

    • SENTINEL reset <pattern> 重置名字匹配该正则表达式的所有的master的状态信息,清楚其之前的状态信息,以及slaves信息

    • SENTINEL failover <master name> 强制sentinel执行failover,并且不需要得到其他sentinel的同意。但是failover后会将最新的配置发送给其他sentinel

故障演练

当前192.168.1.142为master节点,现在我们将其手动停掉,用来测试故障迁移

redis-cli -h 192.168.1.142 -a 123456789 shutdown
  • 故障迁移的步骤

    • 第一步,单个哨兵主观认为Master挂了(sdown);不排除因为网络抖动导致误认为挂了

    • 第二步,当达到quorum数量的哨兵都认为Master挂了之后,哨兵集群客观认为Master挂了

    • 第三步,准备开始做故障迁移

    • 第四步,哨兵集群开始投票选举新的Master

    • 第五步,故障迁移至新的Master

    • 第六步,根据parallel-syncs开始做从节点挂载,故障迁移完成并发编程之Redis:Redis主从架构及哨兵架构可以看到,master已经成功迁移到了新的节点;

主备切换带来的数据丢失问题

异步复制

并发编程之Redis:Redis主从架构及哨兵架构

  • 当客户端想master写了一条数据

  • 异步同步还没有做,master挂了

  • 当哨兵集群发现并做了故障迁移

  • 新的master中因为异步同步的原因,导致了部分数据的丢失

脑裂问题

解决方式
  min-slaves-to-write 1
min-slaves-max-lag 10
// 表示,至少有一个salve,数据复制和同步的延迟不能超过10s,一旦超过,master就停止接受任何写请求

码字不易,感谢您的点赞!关注!评论!!!



以上是关于并发编程之Redis:Redis主从架构及哨兵架构的主要内容,如果未能解决你的问题,请参考以下文章

redis主从架构及哨兵模式

Redis哨兵集群工作原理及架构部署 #yyds干货盘点#

Centos7部署redis主从复制及哨兵架构

三分钟带你入门-redis-高可用架构之哨兵

高并发架构Redis缓存高并发之-主从架构

Redis主从与哨兵架构详解 Redis主从架构 如何在同一台机器搭建主从架构 Redis主从工作原理 数据部分复制 Jedis使用 Redis的管道(Pipeline) Redis Lua脚本(代码