在上文《异地多活架构梳理演变（九）异地双活》我们介绍了实施异地双活的部署方式来实现系统的高可用。但是这里其实有一个非常重大的问题，即：1、如果A用户在成都机房登录了。并且A用户也在北京机房登录了。 2、用户9点41分...

上文《异地多活架构梳理演变（八）两地三中心》我们介绍了两地三中心的部署实施方案保证系统的高可用。但是这种虽然同城发生故障的概率非常低，但是还是有发生故障的可能性，所以基于此，业界提出了异地双活的概念。整体异地双活的方...

上文《异地多活架构梳理演变（七）同城双活》我们介绍了同城双活的部署方式实现系统的高可用。但是这里其实还是会出现一种可能得情况，即：1、两个机房存在同一个城市。 2、如果整个城市发生灾害，例如地震，水灾等重大自然灾害的...

上文《异地多活架构梳理演变（六）同城灾备》我们实现了同城灾备。在同城灾备里面我们可以看到一个是主机房，另外一个是备用机房，当主机房出现任何问题的时候，通过dns来切割流量转移到备用机房，然后得以实现系统的高可用。但是...

上文《异地多活架构梳理演变（五）应用层的冗余》我们介绍了应用的冗余，可以看到在我们实现了两套部署，用冗余的方式来满足系统的高可用。但是对于企业来说，我们可能两套部署都是放在同一个机房的，并且有可能放在同一个机架上的。...

上文《异地多活架构梳理演变（四）主从副本的演进》我们解决了数据存储的高可用问题。但是对于我们的要求来说，既然是高可用，那么不仅仅是数据存储的高可用，还必须保证服务的高可用，对不对？所以我们在上文的基础上把单体系统架构...

上文《异地多活架构梳理演变（三）单体业务架构之手动备份》我们提到单体架构为了解决数据丢失的问题，我们采用定时备份的策略。但是又出现新的问题，就是中间一小部分的间隔数据也会存在丢失。所以整体的架构继续演进，逐渐演进到大...

上文《异地多活架构梳理演变（二）单体系统架构是什么样子的？》我们介绍了单体架构的致命缺点，就是当部署的服务器发生故障的时候，数据丢失了。所以随着业务的发展，为了解决这个问题，大家一般会采用的策略方案就是：定时备份数据...

上文《异地多活架构梳理演变（一）为什么要有异地多活架构》我们介绍了使用异地多活的架构主要是为了解决系统物理层面的高可用。从本文开始，我们逐渐的介绍下异地多活架构的具体演进。本文我们首先来介绍下单体架构，对于单体系统架...