一、分布式
将不同的业务分部在不同的地方，就构成了一个分布式的系统，系统 A 是整个分布式系统的入口，用户访问量大的时候要么是速度巨慢，可能会引起单点失败。
二、集群（Cluster）
将三个服务器（系统 A）的系统就组成了一个集群。
三、负载均衡（Load Balancer）
负载均衡的工作独立出来，放到独立的服务器上（例如 nginx）：
负载均衡的服务器虽然工作内容简单，就是拿到请求，分发请求，但是 Nginx 还是有可能挂掉，单点失败还是会出现。
可以将负载均衡也组成一个集群，但是和系统 A 的集群有两点不同：
- 1、这个新的集群中虽然有两个机器，但是可以用某种办法，让这个机器对外只提供一个 IP 地址，也就是用户看到的好像只有一个机器。
- 2、同一时刻，只让一个负载均衡的机器工作，另外一个原地待命，如果工作的那个挂掉了，待命的那个就顶上去。
四、分布式架构
4.1.集中式系统
所谓的集中式系统就是指由一台或多台主计算机组成中心节点，数据集中存储于这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。
集中式系统的最大的特点就是部署结构非常简单。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署，很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。
4.2、分布式系统
分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。
各个主机之间通信和协调主要通过网络进行，所以分布式系统中的计算机在空间上几乎没有任何限制，这些计算机可能被放在不同的机柜上，也可能被部署在不同的机房中。但是，无论空间上如何分布，一个标准的分布式系统应该具有以下几个主要特征：
分布性
分布式系统中的多台计算机之间在空间位置上可以随意分布，同时，机器的分布情况也会随时变动。对等性
分布式系统中的计算机没有主／从之分，即没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的。副本（Replica）是分布式系统最常见的概念之一，指的是分布式系统对数据和服务提供的一种冗余方式。在常见的分布式系统中，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。数据副本是指在不同节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取该数据，这是解决分布式系统数据丢失问题最为有效的手段。另一类副本是服务副本，指多个节点提供同样的服务，每个节点都有能力接收来自外部的请求并进行相应的处理。并发性
在一个计算机网络中，程序运行过程的并发性操作是非常常见的行为。例如同一个分布式系统中的多个节点，可能会并发地操作一些共享的资源，如何准确并高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一。缺乏全局时钟
在分布式系统中，很难定义两个事件究竟谁先谁后，原因就是因为分布式系统缺乏一个全局的时钟序列控制。故障总是会发生
组成分布式系统的所有计算机，都有可能发生任何形式的故障。除非需求指标允许，在系统设计时不能放过任何异常情况。
五、分布式系统面临的问题
5.1、通信异常
分布式系统需要在各个节点之间进行网络通信，因此网络通信都会伴随着网络不可用的风险或是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外，即使分布式系统各节点之间的网络通信能够正常进行，其延时也会远大于单机操作，会影响消息的收发的过程，因此消息丢失和消息延迟变得非常普遍。
5.2、网络分区
当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够进行正常通信，而另一些节点则不能，这个现象为网络分区，就是俗称的 “脑裂”。当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式才能完成的功能，这就对分布式一致性提出类非常大的挑战。
5.3、三态
分布式系统的每一次请求与响应，存在特有的三态概念，即成功、失败与超时。当出现超时现象时，网络通信的发起方是无法确定当前请求是否被成功处理的。
5.4、节点故障
节点故障则是分布式环境下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或僵死现象。
六、分布式理论 (一) - CAP 定理
CAP 原则又称 CAP 定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能同时满足其中的 2 个。
6.1、初探分布式理论
6.1.1、CAP 原则简介
Consistency（一致性）指数据在多个副本之间能够保持一致的特性（严格的一致性）。Availability（可用性）指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应（不保证获取的数据为最新数据）。Partition tolerance（分区容错性）分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。
在分布式系统中，不同的节点分布在不同的子网络中，由于一些特殊的原因，这些子节点之间出现了网络不通的状态，但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域，这就是分区。
6.1.2、CAP 原则论证
如图所示，是我们证明 CAP 的基本场景，网络中有两个节点 N1 和 N2，可以简单的理解 N1 和 N2 分别是两台计算机，他们之间网络可以连通，N1 中有一个应用程序 A，和一个数据库 V，N2 也有一个应用程序 B 和一个数据库 V。现在，A 和 B 是分布式系统的两个部分，V 是分布式系统的数据存储的两个子数据库。
- 在满足一致性的时候，N1 和 N2 中的数据是一样的，V0=V0。
- 在满足可用性的时候，用户不管是请求 N1 或者 N2，都会得到立即响应。
- 在满足分区容错性的情况下，N1 和 N2 有任何一方宕机，或者网络不通的时候，都不会影响 N1 和 N2 彼此之间的正常运作。
如图所示，这是分布式系统正常运转的流程，用户向 N1 机器请求数据更新，程序 A 更新数据库 V0 为 V1。分布式系统将数据进行同步操作 M，将 V1 同步的 N2 中 V0，使得 N2 中的数据 V0 也更新为 V1，N2 中的数据再响应 N2 的请求。
根据 CAP 原则定义，系统的一致性、可用性和分区容错性细分如下：
- 一致性：N1 和 N2 的数据库 V 之间的数据是否完全一样。
- 可用性：N1 和 N2 的对外部的请求能否做出正常的响应。
- 分区容错性：N1 和 N2 之间的网络是否互通。
这是正常运作的场景，也是理想的场景。作为一个分布式系统，它和单机系统的最大区别，就在于网络。现在假设一种极端情况，N1 和 N2 之间的网络断开了，我们要支持这种网络异常。相当于要满足分区容错性，能不能同时满足一致性和可用性呢？还是说要对他们进行取舍？
假设在 N1 和 N2 之间网络断开的时候，有用户向 N1 发送数据更新请求，那 N1 中的数据 V0 将被更新为 V1。由于网络是断开的，所以分布式系统同步操作 M，所以 N2 中的数据依旧是 V0。这个时候，有用户向 N2 发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据 V1，怎么办呢？
这里有两种选择：
第一：牺牲数据一致性，保证可用性。响应旧的数据 V0 给用户。
第二：牺牲可用性，保证数据一致性。阻塞等待，直到网络连接恢复，数据更新操作 M 完成之后，再给用户响应最新的数据 V1。
这个过程，证明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。
6.1.3、CAP 原则权衡
通过 CAP 理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？
CA without P
如果不要求 P（不允许分区），则 C（强一致性）和 A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此 CA 的系统更多的是允许分区后各子系统依然保持 CA。CP without A
如果不要求 A（可用），相当于每个请求都需要在 Server 之间强一致，而 P（分区）会导致同步时间无限延长，如此 CP 也是可以保证的。很多传统的数据库分布式事务都属于这种模式。AP wihtout C
要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的 NoSQL 都属于此类。
6.2、小结
对于多数大型互联网应用的场景，主机众多、部署分散。而且现在的集群规模越来越大，所以节点故障、网络故障是常态。这种应用一般要保证服务可用性达到 N 个 9，即保证 P 和 A，只有舍弃 C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。
对于涉及到钱财这样不能有一丝让步的场景，C 必须保证。网络发生故障宁可停止服务，这是保证 CA，舍弃 P。还有一种是保证 CP，舍弃 A，例如网络故障时只读不写。
孰优孰劣，没有定论，只能根据场景定夺，适合的才是最好的。
七、分布式理论 (二) - BASE 理论
BASE 理论是由 eBay 架构师提出的。BASE 是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于 CAP 定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。
7.1、CAP 的 3 选 2 伪命题
实际上，不是为了 P（分区容错性），必须在 C（一致性）和 A（可用性）之间任选其一。分区的情况很少出现，CAP 在大多时间能够同时满足 C 和 A。
对于分区存在或者探知其影响的情况下，需要提供一种预备策略做出处理：
- 探知分区的发生；
- 进入显示的分区模式，限制某些操作；
- 启动恢复过程，恢复数据一致性，补偿分区发生期间的错误。
7.2、BASE 理论简介
BASE 理论是 Basically Available (基本可用)，Soft State（软状态）和 Eventually Consistent（最终一致性）三个短语的缩写。
其核心思想是：
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
7.3、BASE 理论的内容
7.3.1、基本可用
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
- 响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 2 秒作用返回结果。
- 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
7.3.2、软状态
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
7.3.3、最终一致性
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。
而在实际工程实践中，最终一致性分为 5 种：
因果一致性（Causal consistency）
因果一致性指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。读己之所写（Read your writes）
读己之所写指的是：节点 A 更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。会话一致性（Session consistency）
会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。单调读一致性（Monotonic read consistency）
单调读一致性指的是：如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。单调写一致性（Monotonic write consistency）
单调写一致性指的是：一个系统要能够保证来自同一个节点的写操作被顺序的执行。
在实际的实践中，这 5 种系统往往会结合使用，以构建一个具有最终一致性的分布式系统。
实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。
评论