分布式理论总览
文章目录
一、集中式与分布式
1.1 集中式系统
由一台或多台主计算机组成中心节点,数据集中存储于这个中心节点中,并且整个系统的所有业务单元都集中部署在这个中心节点上,系统的所有功能均由其集中处理
1.2 分布式系统
分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。分布式系统的各个主机之间的通信和协调主要通过网络进行,所以分布式系统中的计算机在地域空间上几乎没有任何限制。分布式系统的特点有:
-
分布性
分布式系统中的多台计算机之间在空间位置上可以随意分布,同时,机器的分布情况也会随时变动
-
对等性
分布式系统中的计算机没有主/从之分,即没有控制整个系统的主机,也没有被控制的从机,组成分布式系统的所有计算机节点都是对等的
-
并发性
在一个计算机网络中,程序运行过程的并发性操作是非常常见的行为。例如同一个分布式系统中的多个节点,可能会并发地操作一些共享的资源
-
缺乏全局时钟
在分布式系统中,很难定义两个事件究竟谁先谁后,原因就是因为分布式系统缺乏一个全局的时钟序列控制
-
故障总会发生
分布式系统通过网络进行通信协调,因网络本身的不可靠性,导致分布式系统发生故障的情况不可避免
如图是一个分布式系统示例,其中系统 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