一、集中式与分布式

1.1 集中式系统

由一台或多台主计算机组成中心节点，数据集中存储于这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理

1.2 分布式系统

分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。分布式系统的各个主机之间的通信和协调主要通过网络进行，所以分布式系统中的计算机在地域空间上几乎没有任何限制。分布式系统的特点有：

1. 分布性

   分布式系统中的多台计算机之间在空间位置上可以随意分布，同时，机器的分布情况也会随时变动

2. 对等性

   分布式系统中的计算机没有主／从之分，即没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的

3. 并发性

   在一个计算机网络中，程序运行过程的并发性操作是非常常见的行为。例如同一个分布式系统中的多个节点，可能会并发地操作一些共享的资源

4. 缺乏全局时钟

   在分布式系统中，很难定义两个事件究竟谁先谁后，原因就是因为分布式系统缺乏一个全局的时钟序列控制

5. 故障总会发生

   分布式系统通过网络进行通信协调，因网络本身的不可靠性，导致分布式系统发生故障的情况不可避免

如图是一个分布式系统示例，其中系统 A、系统 B 和系统 C 组成分布式系统，为了避免单点故障，系统 A 部署为集群模式，中间用 Nginx 做负载均衡。同理，为了避免 Nginx 单点故障，部署 Nginx 集群，并利用 keepalived 设置虚拟 IP 对外暴露

二 分布式理论

2.1 CAP 理论

2.1.1 CAP 简介

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能同时满足其中的2个

选项	描述
Consistency	指数据在多个副本之间能够保持一致的特性（严格的一致性）
Availability	指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应（不保证获取的数据为最新数据）
Partition tolerance	分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障

什么是分区？

在分布式系统中，不同的节点分布在不同的子网络中，由于一些特殊的原因，这些子节点之间出现了网络不通的状态，但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域，这就是分区

2.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 节点请求数据更新，N1 节点的数据库状态由 V0 变为 V1。分布式系统将数据进行同步操作 Modify，使得 N2节点的数据库状态也更新为 V1，此时 N2 再响应请求时，返回的是最新的数据状态 V1 的数据

此时根据 CAP 原则，系统正常运转时的 CAP 状态为

• 一致性：节点 N1 和 N2 的数据库状态 V1 = V1
• 可用性：节点 N1 和 N2 均可对外部请求进行正常响应
• 分区容错性：节点 N1 和 节点 N2 的网络互通

上述情景是理想状况下的分布式系统运转，在实际情况中，由于网络的不稳定性，节点 N1 和 N2 间的网络可能不通，假设我们允许这种情况的发生，即满足 P 条件，那么在这个时候，分布式系统对 CA 是如何取舍的呢？

这里有两种选择：

• 满足 AP：牺牲数据一致性，保证可用性。节点 N2 将旧数据库状态 V0 的数据响应给用户
• 满足 CP：牺牲可用性，保证数据一致性。路由到节点 N2 的请求阻塞等待，直到网络连接恢复，数据更新操作 modify 完成之后，再给用户响应最新的数据库状态为 V1 的数据

这个过程，证明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个

2.2 BASE 理论

BASE 理论是 Basically Available（基本可用），Soft State（软状态） 和 Eventually Consistent（最终一致性）三个短语的缩写，其核心思想是既然无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）

2.2.1 Basically Available

假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：

• 响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 2 秒左右返回结果
• 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2.2.2 Soft State

相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时

2.2.3 Eventually Consistent

上面说软状态，不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本的数据一致，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素

三、分布式常见问题

• 分布式事务
• 分布式锁
• 分布式 session
• 分布式 ID
• 负载均衡
• 分布式缓存

参考文章

https://blog.csdn.net/a724888/category_9276097.html