应用场景异地多活的关键点在于异地、多活，其中异地就是指地理位置上不同的地方，多活就是指不同地理位置上的系统都能够提供业务服务。判断一个系统是否异地多活，需要满足以下二个条件： 正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的

44-架构重构内功心法第一式：有的放矢一般情况下，系统的架构是不断演化的，少部分架构演化可能需要推倒重来进行重定，但大部分的架构演化都是通过架构重构来实现的。相比全新的系统架构设计，架构重构要求更高： 业务已经上线，无法停下来 关联方众

前言计算高可用的主要目标是当部分硬件出现故障时，计算任务能够继续执行。其本质是通过冗余的方式来规避部分故障的风险，因此单台服务器是做不到这一点的，所以计算高可用的设计思想很简单：通过增加更多的服务器来达到计算高可用。 计算高可用的复杂度来源

数据集群主备、主从、主主架构本质上有一个隐藏的假设：即主机可以存储所有的数据，但是主机本身的存储和处理能力肯定是有限的。随着业务的发展，单独服务器肯定是不够存储和处理的，所以必须所用多台服务器来存储数据，这就是数据库集群。 集群就是多台机器

FMEA介绍FMEA(Failure mode and effects analysis,故障模式与影响分析)，又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析或故障模式与效应分析等。FMEA是一种在各行各业都有广泛使用的可

42-互联网架构模板：“用户层”和“业务层”技术用户层技术用户管理互联网业务的一个典型特征就是通过互联网将众多分散的用户连接起来，用户管理是必不可少的。 稍微大一点的互联网业务，肯定会涉及多个子系统，这些子系统不可能每个都管理这么庞大的用户

低成本简介通常情况下，我们会通过增加机器来实现高性能和高可用，而低成本是需要我们减少机器来达到低成本的要求。这与高性能和高可用产生了天然的矛盾。所以一般情况下，低成本是架构设计中的附加约束条件，而不是主要目标。比如说老板说这个项目最多只能提

CAP的关键细节 CAP关注的粒度是数据，而不是整个系统 CAP理论的定义和解释上，用的都是system、node这类的系统级概念，容易给我们造成误解，认为系统只能选择AP或者CP。但是在实际设计中，系统不可能只处理一种数据，有的数据需要

CAP理论CAP定理又称作布鲁尔定理，是分布式计算领域公认的一个定理。采用Robert Greiner第二版对CAP定理的定义为：在一个分布式系统(指互相连接并共享数据的节点的集合)中，当涉及读写操作时，只能保证一致性、可用性、分区容错性三

前言负载均衡算法分类 任务平均类：负载均衡系统将任务平均分配给服务器进行处理，这里的平均可以是绝对的平均，也可以是加权的平均。 负载均衡类：负载均衡系统根据服务器的负载进行分配，这里的负载是指系统当前的压力，可以用CPU负载衡量，也可以用

前言单服务器无论如何优化，都会达到一个性能瓶颈。如果单服务器无法达到我们的性能要求，那么就需要设计高性能服务器集群的方式来提升系统的整体性能。 高性能服务器集群的本质就是通过增加服务器来提升系统的整体计算能力。 高性能服务器集群的设计复杂度