分布式系统设计策略之高可用
高可用
高可用HA设计
高可用（Hign Availability）是系统架构中必须考虑的因素之一，指的是，经过设计来减少系统不能提供服务的时间。
系统高可用性的设计模式通常有三种：主备（master-slave）、互备（active-active）和集群（cluster）。
主备模式
主备模式是Active-Standby模式，当主机宕机时，备机接管主机的一切工作。
待主机回复正常之后，按照使用者的设定以自动（热备）或者手动（冷备）方式将服务器切换到主机上运行。
在数据库部分，习惯成为M-S模式。MS模式就是Master-Slave模式，这在数据库高可用方案中比较常用，例如MySQL、Redis等就是采用MS模式实现主从复制，保证包可用。
image-20220411195614832 互备模式
互备模式指的是两台主机同时运行各自的服务，且相互监测的情况。
在数据库高可用部分，常见的互备是MM模式。
MM模式是Multi-Master模式，指一个系统中存在多个master，每个master都有read-write的能力，会根据时间戳或者业务逻辑合并版本。
image-20220411202659518 集群模式
集群模式指的是多个节点运行，同时可以通过主控节点分担服务请求。
集群模式需要解决主控节点本身的高可用问题，一般采用主备模式。
高可用HA模式下的“脑裂问题”
什么是脑裂
在高可用（HA）系统中，当联系两个节点的心跳线断裂的时候（两个节点失去联系），本来为一个整体、动作协同的HA系统，就分裂成两个独立的节点（两个独立的个体）。
由于相互之间失去了联系，都以为对方出现了故障，两个节点上的HA软件就像“裂脑人”一样，“本能”的争抢共享资源，以及“应用服务”，就会引起问题：
共享资源被瓜分，两边的“服务“都起不起来了
两边服务都起来了，但是同时读取”共享存储“，导致数据损坏（常见的数据库轮询联机日志出错）。
两个节点相互争抢共享资源，导致系统混乱，数据损坏。
对应无状态服务的HA，没有脑裂不脑裂的问题，但是对于有状态服务的HA（如MySQL），必须严格现在脑裂。
脑裂出现的原因
发生脑裂，一般有以下几种原因：
- 高可用服务器节点之间心跳链路发生故障，导致无法正常通信。
- 网卡以及相关驱动坏了，ip配置及冲突问题（网卡直连）。
- 因心跳线间连接的设备故障（网卡及交换机）。
- 因仲裁的机器出问题（采用仲裁的方案）。
- 高可用服务器上开启了iptables防火墙阻挡了心跳消息传输。
- 高可用服务器上心跳网卡地址信息配置不正确，导致发送心跳失败。
- 其他服务配置不当导致，如心跳方式不同、心跳广插冲突、软件bug等。
脑裂预防方案
添加冗余的心跳线（冗余通信方法）
同时用两条心跳线路（心跳线也HA），这样一条心跳线坏了，另外一条还是好的，依然能够传递心跳消息，尽量减少”脑裂“产生的几率。
仲裁机制
当两个节点出现分歧时候，由第三方仲裁者决定听谁的。仲裁者，可以是一个锁服务，一个共享盘或者其他的什么东西。
Lease机制
隔离（Fencing）机制
- 共享Fencing：确保只有一个Master往共享存储中写数据。
- 客户端Fencing：确保只有一个Master可以响应客户端请求。
- Slave Fencing：确保只有一个Master可以向Slave下发命令