远方的灯塔 - 专注于服务端技术分享 远方的灯塔 - 专注于服务端技术分享
首页
  • Java SE
  • Struts2
  • Hibernate
  • MyBatis
  • JAX-WS
  • 并发
  • 分布式
  • Git
  • 《C程序设计语言》
心情随笔
  • 文章分类
  • 文章标签
  • 文章归档
友情链接
关于我
GitHub (opens new window)

Terwer Green

一个后端老菜鸟
首页
  • Java SE
  • Struts2
  • Hibernate
  • MyBatis
  • JAX-WS
  • 并发
  • 分布式
  • Git
  • 《C程序设计语言》
心情随笔
  • 文章分类
  • 文章标签
  • 文章归档
友情链接
关于我
GitHub (opens new window)
  • JavaSE

  • 开源框架

  • Linux

  • Struts2

  • Hibernate

  • Webservice

  • 分布式

    • RPC架构设计及IO模型
    • NIO编程及其三大核心原理
    • NIO三大核心之缓冲区(Buffer)
    • NIO三大核心之通道(Channel)
    • NIO三大核心之选择器(Selector)
    • Netty核心原理
    • 线程模型以及传统IO阻塞模型
    • Reactor模型
    • Netty线程模型
    • Netty核心API介绍
    • Netty入门与异步模型
    • Netty高级进阶之Netty编解码器
    • Netty高级进阶之基于Netty的群聊天室案例
    • Netty高级进阶之基于Netty的HTTP服务器开发
    • Netty高级进阶之基于Netty的Websocket开发网页聊天室
    • Netty高级进阶之Netty中的粘包和拆包的解决方案
    • Netty源码剖析
    • 自定义RPC框架之分布式架构网络通信理论
    • 自定义RPC框架之基于Netty实现RPC框架
    • 分布式架构理论
    • 分布式理论之数据一致性
    • 分布式理论之CAP定理
    • 分布式理论之BASE定理
    • 分布式一致性协议之两阶段提交协议(2PC)
    • 分布式一致性协议之三阶段提交协议(3PC)
    • 分布式一致性协议之NWR协议
    • 分布式一致性协议之Gossip协议
    • 分布式一致性协议之Paxos协议
    • 分布式一致性协议之Raft协议
    • 分布式一致性协议之Lease机制
    • 分布式系统设计策略之心跳检测
    • 分布式系统设计策略之高可用
      • 分布式系统设计策略之容错性
      • 分布式系统设计策略之负载均衡
      • 分布式架构服务调用
      • 分布式服务治理之服务协调
      • 分布式服务治理之服务削峰
      • 分布式服务治理之服务降级
      • 分布式服务治理之服务限流
      • 分布式服务治理之服务熔断
      • 分布式服务治理之服务链路追踪
      • 架构设计基本原则之开闭原则(OCP)
      • 架构设计基本原则之单一职责原则(SRP)
      • 架构设计基本原则之接口隔离原则(ISP)
      • 架构设计基本原则之里式替换原则(LSP)
      • 架构设计基本原则之依赖倒置原则(DIP)
      • 架构设计基本原则知识扩展
      • 分布式架构知识拓展与总结
    • 分布式框架

    • 后端开发
    • 分布式
    terwer
    2022-05-04
    目录

    分布式系统设计策略之高可用

    # 高可用

    # 高可用HA设计

    高可用(Hign Availability)是系统架构中必须考虑的因素之一,指的是,经过设计来减少系统不能提供服务的时间。

    image-20220410230934957

    系统高可用性的设计模式通常有三种:主备(master-slave)、互备(active-active)和集群(cluster)。

    1. 主备模式

      主备模式是Active-Standby模式,当主机宕机时,备机接管主机的一切工作。

      待主机回复正常之后,按照使用者的设定以自动(热备)或者手动(冷备)方式将服务器切换到主机上运行。

      在数据库部分,习惯成为M-S模式。MS模式就是Master-Slave模式,这在数据库高可用方案中比较常用,例如MySQL、Redis等就是采用MS模式实现主从复制,保证包可用。

      image-20220411195614832

    2. 互备模式

      互备模式指的是两台主机同时运行各自的服务,且相互监测的情况。

      在数据库高可用部分,常见的互备是MM模式。

      MM模式是Multi-Master模式,指一个系统中存在多个master,每个master都有read-write的能力,会根据时间戳或者业务逻辑合并版本。

      image-20220411202659518

    3. 集群模式

      集群模式指的是多个节点运行,同时可以通过主控节点分担服务请求。

      集群模式需要解决主控节点本身的高可用问题,一般采用主备模式。

    # 高可用HA模式下的“脑裂问题”

    1. 什么是脑裂

      在高可用(HA)系统中,当联系两个节点的心跳线断裂的时候(两个节点失去联系),本来为一个整体、动作协同的HA系统,就分裂成两个独立的节点(两个独立的个体)。

      由于相互之间失去了联系,都以为对方出现了故障,两个节点上的HA软件就像“裂脑人”一样,“本能”的争抢共享资源,以及“应用服务”,就会引起问题:

      • 共享资源被瓜分,两边的“服务“都起不起来了

      • 两边服务都起来了,但是同时读取”共享存储“,导致数据损坏(常见的数据库轮询联机日志出错)。

        两个节点相互争抢共享资源,导致系统混乱,数据损坏。

        对应无状态服务的HA,没有脑裂不脑裂的问题,但是对于有状态服务的HA(如MySQL),必须严格现在脑裂。

    2. 脑裂出现的原因

      发生脑裂,一般有以下几种原因:

      • 高可用服务器节点之间心跳链路发生故障,导致无法正常通信。
      • 网卡以及相关驱动坏了,ip配置及冲突问题(网卡直连)。
      • 因心跳线间连接的设备故障(网卡及交换机)。
      • 因仲裁的机器出问题(采用仲裁的方案)。
      • 高可用服务器上开启了iptables防火墙阻挡了心跳消息传输。
      • 高可用服务器上心跳网卡地址信息配置不正确,导致发送心跳失败。
      • 其他服务配置不当导致,如心跳方式不同、心跳广插冲突、软件bug等。
    3. 脑裂预防方案

      • 添加冗余的心跳线(冗余通信方法)

        同时用两条心跳线路(心跳线也HA),这样一条心跳线坏了,另外一条还是好的,依然能够传递心跳消息,尽量减少”脑裂“产生的几率。

      • 仲裁机制

        当两个节点出现分歧时候,由第三方仲裁者决定听谁的。仲裁者,可以是一个锁服务,一个共享盘或者其他的什么东西。

      • Lease机制

      • 隔离(Fencing)机制

        • 共享Fencing:确保只有一个Master往共享存储中写数据。
        • 客户端Fencing:确保只有一个Master可以响应客户端请求。
        • Slave Fencing:确保只有一个Master可以向Slave下发命令
    编辑 (opens new window)
    #rpc#availability
    上次更新: 2023/09/19, 13:33:19
    分布式系统设计策略之心跳检测
    分布式系统设计策略之容错性

    ← 分布式系统设计策略之心跳检测 分布式系统设计策略之容错性→

    最近更新
    01
    Java_21
    09-22
    02
    Java_20
    09-22
    03
    macOS搭建openjdk8编译环境
    09-19
    更多文章>
    Theme by Vdoing | Copyright © 2011-2023 Terwer Green | MIT License | 粤ICP备2022020721号-1 | 百度统计
    • 跟随系统
    • 浅色模式
    • 深色模式
    • 阅读模式