高可用 架构

不要把鸡蛋都放在同一篮子里

标准：

1   正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务。

2   某个地方业务异常的时候，用户访问其他地方正常的业务系统，能够得到正确的业务服务。

 

与“活”对应的是字是“备”，备是备份，正常情况下对外是不提供服务的，如果需要提供服务，则需要大量的人工干预和操作，花费大量的时间才能让“备”变成“活”。

 

活能更好的进行容灾   保证更高的可用性   而备则需要更多的启动或者选举时间    如为核心链路，此段时间将会造成巨额损失。

 

实现高可用也会带来巨大的代价：

1 系统复杂度上升

2 成本上升

因此只有核心的业务才需要进行高可用改造。

 

按照地理位置距离划分，异地多活架构可分为 1 同城异区  2 跨城跨地  3 跨国异地

1 同城异区：

 

在同一城市距离较远的地方部署两个集群，共同提供读写服务，两集群间通过专线网络进行同步。

出现城市级别灾难时，无法满足高可用。

但在同一城市，能够在较短时间内完成数据同步，保证数据的一致性。但对于机房火灾，停电等能很好应对。

 

 

2 跨城异地：

业务部署在不同城市的多个机房，而且距离最好要远一些。  比如 北京与深圳

在距离上比较远，才能有效应对这类极端灾难事件。比如山洪 、地震等极端灾害

 

距离增加带来的最主要问题是两个机房的网络传输速度会降低

业务系统需要考虑部署在不同地点的两个机房，在数据短时间不一致的情况下，还能够正常提供业务。这就引入了一个看似矛盾的地方：数据不一致业务肯定不会正常，但跨城异地肯定会导致数据不一致。

 

尤其涉及到RMB 的业务  双写无法保证一致性，必然会带来问题。

 

支付宝等金融相关的系统，对余额这类数据，一般不会做跨城异地的多活架构，而只能采用同城异区这种架构。

 

对数据一致性要求不那么高，或者数据不怎么改变，或者即使数据丢失影响也不大的业务，跨城异地多活就能够派上用场了。例如，用户登录（数据不一致时用户重新登录即可）

 

3. 跨国异地