计算高可用架构设计---摘要

《从0开始学架构》27-31的学习记录

一、概述

计算高可用：本质上是通过冗余来规避部分故障的风险。当部分硬件损坏时，还能继续提供计算服务。主要的设计复杂度体现在任务管理方面，即当任务在某台服务器上执行失败后，如何将任务重新分配到新的服务器进行执行。因此，关键是：

1、哪些服务器可以执行任务？要找到这个服务器。  2、任务如何重新执行？一种是不管已失败的，保证新的可以就行；一种是有任务分配器的。

常见的计算高可用架构有：主备、主从和集群。

主备一般是温备，而非冷备。主从和主备的区别是，从机也是一直在处理业务的，只是地位不同。这两个都是单台服务器冗余。

集群是多台，3台以上。有对称集群，和非对称集群两种模式。

对称集群中所有机器地位相同，通俗叫法是负载均衡集群；任务分配器要检测机器工作状态（一般是心跳模式），分配则简单的轮询或随机搞定。

非对称集群典型的有Master-Slave模式。Master出故障时，要先选举出新的Master。然后Master的任务转发给新机器。

二、异地多活架构

异地多活架构有同城异区、跨城异地、跨国异地。一般来说，同城异区采用高速网络连接，在架构上可以类比本地系统，主要是解决机房停电、机房火灾等事故，而非应对地震、大洪灾之类极端情况；跨国异地一般是处于业务考虑，不同地区用户提供服务，或者对只读类业务做多活，而不是真正意义上的异地多活。这样说来，真正复杂的是跨城异地。

跨城异地由于传输距离，肯定会导致数据不一致。因此，数据强一致性，实际上是无法做到跨城异地多活的。一般对数据强一致性要求没那么高的，跨城异地多活，可以较好应对极端情况。

三、异地多活设计技巧

1、保证核心业务的异地多活。  原则是：不可能、也没必要保证所有业务异地多活。 首先要识别核心业务，毕竟有的能赚钱；有的带来关注度（本质上也是钱）；有的业务出问题用户体验影响极大。

2、保证核心数据最终一致性。除了租用更大带宽外，技巧是：a）尽量减少数据同步，只同步核心业务相关的数据。b）保证核心数据最终一致性，而不是实时一致性。

3、采用多种手段同步数据。不要只限于数据库系统自带的同步方式。常用方式如：消息队列；二次读取（本地读取失败后，向异地读取。   应对场景：用户刚在A注册，然后就跑到B去访问。）；存储系统同步；回源读取（ 对数据量很大的，直接根据id判断，转到原来的服务器去获取。省掉二次读取先在本地取的步骤。）；重新生成数据。

4、只保证绝大部分用户的异地多活。注意，不只是所有业务的异地多活不保证，所有用户的也不保证。我觉得这个是符合CAP原理的，也符合28定律。为了那1%%，搞出个消耗90%资源的设计，划不来。

四、异地多活设计步骤

第一步，业务分级。  首先要确定核心业务（需要设计异地多活的业务）。一般标准：访问量大的；产品核心业务；带来大量收入的

第二步，数据分类。 识别出核心业务后，需要对核心业务相关的数据进一步分析，目的在于识别所有的数据及数据特征。数据特征分析维度有：数据量（总数据量和变动（增删改）数据量）；唯一性；实时性；可丢失性；可恢复性。

第三步，数据同步。根据数据特点设计不同的数据同步方案。按照方便性： 存储系统同步，消息队列同步，重复生成。

第四步，异常处理。出现问题时如何处理。常见处理措施有：多通道同步，同步和访问（二次读取，回源读取）结合，日志记录，用户补偿。