高可用架构

CAP理论

一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）

FMEA方法

FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等

分析方法

• 给出初始的架构设计图。
• 假设架构中某个部件发生故障。

• 分析此故障对系统功能造成的影响。
• 根据分析结果，判断架构是否需要进行优化。

1. 功能点
2. 故障模式--故障点和故障形式

1. 故障影响
2. 严重程度

1. 故障原因
2. 故障概率

1. 风险程度
2. 已有措施

1. 规避措施
2. 解决措施

1. 后续规划

高可用存储架构

双机架构

主备复制

主备复制是最常见也是最简单的一种存储高可用方案，几乎所有的存储系统都提供了主备复制的功能，例如 MySQL、Redis、MongoDB 等。

主从复制

主机负责读写操作，从机只负责读操作，不负责写操作。

主主复制

主主复制指的是两台机器都是主机，互相将数据复制给对方，客户端可以任意挑选其中一台机器进行读写操作。

集群

数据集中集群

1 主多备、1 主多从

问题

主机如何将数据复制给备机；备机检测主机状态；主机故障后，决定新的主机（zab算法）

数据分散集群

数据分散集群指多个服务器组成一个集群，每台服务器都会负责存储一部分数据；同时，为了提升硬件利用率，每台服务器又会备份一部分数据。

问题

均衡性、容错性、可伸缩性

数据集中集群架构中，客户端只能将数据写到主机；数据分散集群架构中，客户端可以向任意服务器中读写数据。

一般来说，数据集中集群适合数据量不大，集群机器数量不多的场景。例如，ZooKeeper 集群，一般推荐 5 台机器左右，数据量是单台服务器就能够支撑；而数据分散集群，由于其良好的可伸缩性，适合业务数据量巨大、集群机器数量庞大的业务场景。例如，Hadoop 集群、HBase 集群，大规模的集群可以达到上百台甚至上千台服务器。

数据分区

考虑的问题：数据量、分区规则（位置，异地多活）、复制规则

复制规则

集中式、互备式、独立式

高可用架构

主备

主从

集群

对称集群

非对称集群

业务高可用的保障：异地多活

备份系统平常没有流量，如果直接上线可能触发平常测试不到的故障。
再实时的系统也会有数据延时，如果涉及到金融这种系统，仍然是不敢直接切换的。
系统运行过程中会有很多中间数据，缓存数据等。系统不经过预热直接把流量倒过来，大流量会直接把系统拖垮

三种不同类型的异地多活架构

同城异区

关键在于搭建高速网络将两个机房连接起来，达到近似一个本地机房的效果。架构设计上可以将两个机房当作本地机房来设计，无须额外考虑。

跨域异地

关键在于数据不一致的情况下，业务不受影响或者影响很小，这从逻辑的角度上来说其实是矛盾的，架构设计的主要目的就是为了解决这个矛盾。

跨国异地

主要是面向不同地区用户提供业务，或者提供只读业务，对架构设计要求不高。

技巧

保证核心业务的异地多活

分析核心业务，用户关注的业务。

保证核心数据最终一致性

• 尽量减少异地多活机房的距离问题，搭建告诉网络。
• 尽量减少数据同步问题，只同步核心业务相关的数据。

• 保证最终一致性，不保证实时一致性。

采取多种手段同步数据

避免只使用存储系统的同步功能，可以将多种手段配合存储系统的同步来使用，甚至可以不采用存储系统的同步方案，改用自己的同步方案。

只保证绝大部分用户的异地多活

四个步骤

业务分级

访问量大的业务

核心业务

产生大量收入的业务

数据分类

数据量

唯一性

实时性

可丢失性

可恢复性

数据同步

存储系统同步

消息队列同步

重复生成

异常处理

问题发生时，避免少量数据异常导致整体业务不可用。

问题恢复后，将异常的数据进行修正。

对用户进行安抚，弥补用户损失。

接口级故障解决

优先保证核心业务和优先保证绝大部分用户

降级

熔断

限流

排队