【Java高级工程师蜕变之路】062 分布式系统设计策略之高可用

高可用

高可用HA设计

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

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

1. 主备模式

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

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

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

   

2. 互备模式

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

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

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

   

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下发命令