什么是分布式系统?
定义
分布式系统是若干独立计算机的集合,这些计算机对于用户来说就像是单个相关系统。
这句话是对分布式系统的一个简洁定义,强调了两个要点:
-
独立计算机的集合:分布式系统由多个独立的计算机组成,这些计算机可以是服务器、客户端、移动设备等。它们通过网络连接在一起,形成一个整体。
-
对用户来说像是单个相关系统:尽管分布式系统由多个独立的计算机组成,但对于用户来说,它应该表现为一个单一的、统一的系统。用户能够与分布式系统进行交互,但用户无需了解系统内部的复杂性或各个计算机之间的关系。
设想有一个在线购物平台,它需要处理大量的用户请求、管理商品信息和处理订单。在传统的集中式系统中,所有的业务逻辑和数据都在一个中心服务器上处理。然而,随着业务规模的扩大,单台服务器可能无法满足性能需求,并且存在单点故障的风险。
相比之下,分布式系统将购物平台拆分成多个子系统,例如用户服务、商品服务和订单服务,每个子系统可以部署在不同的服务器上,通过网络进行通信和协作。各个子系统还可以根据实际需求进行水平扩展,通过增加服务器节点来提升系统的处理能力。同时,分布式系统还可以通过冗余部署来实现高可用性,当某个服务器节点出现故障时,其他节点可以接管其工作,确保系统的连续运行。这种分布式的设计可以更好地应对大规模业务和高并发请求,提高系统的性能、可靠性和可扩展性。
主要特征
无论空间上如何分布,一个标准的分布式系统应该具有以下几个主要特征
-
分布性:分布式系统中的组件或节点可以分布在不同的地理位置或网络环境中,通过网络进行通信和协作。这种分布性使得系统能够更好地利用资源、提高可靠性和可伸缩性。比如,可以按照用户分布的地区选择在该地区的数据中心部署应用程序,以提供更好的性能和用户体验。
-
对等性:在分布式系统中,每个节点都具有相同的地位和能力,没有中心节点或主从关系。每个节点可以自主地执行任务和处理数据,而不依赖于其他节点。这种对等性有助于可以提高系统的可靠性、可扩展性和容错性。由于没有中心化的单点故障,系统可以更好地应对节点故障或网络分区等问题。举个简单的例子,P2P(对等网络)是一种分布式网络架构,其中每个节点既是客户端又是服务器。节点之间可以直接相互通信和共享资源,而不需要中心化的服务器。在 P2P 网络中,每个节点具有相同的地位和能力,没有主从之分。
-
自治性:分布式系统中的每个节点都具有一定的自治性和独立性,可以自主地管理自身的状态和行为。节点可以根据自身的情况做出决策,并与其他节点进行协调和协作。这种自治性使得系统更加灵活和可靠。比如分布式数据库,数据被分布存储在多个节点上。每个节点可以自主地管理自己存储的数据,并根据本地的策略和需求进行数据的读取、写入和维护,而不需要将数据传输至中心节点。
-
并发性:分布式系统中的多个节点可以同时执行任务和处理数据,从而实现并发处理。这种并发性可以提高系统的效率和性能,但也带来了一致性、锁管理和并发控制等方面的挑战。
设计目标
衡量分布式系统的指标有哪些?
-
可伸缩性:能够轻松地扩展系统规模,以应对不断增长的业务需求。像云计算平台(如 Amazon AWS、Microsoft Azure)就是典型的分布式系统,它们可以通过添加更多的服务器来扩展计算资源,以应对用户需求的增长。为了实现可伸缩性,分布式系统通常采用水平扩展的方式,即通过增加更多的节点来分担负载。这种方式可以避免单个节点成为性能瓶颈,并且可以提高系统的容错性。此外,分布式系统还需要考虑数据的分区和复制,以确保数据可以均匀地分布在各个节点上,并在节点故障时能够快速恢复。
-
高可用:高可用性是指分布式系统能够在部分节点或网络故障的情况下,仍然保持可用并提供服务。高可用性是分布式系统的关键设计目标之一,因为系统的故障可能会导致业务的中断和数据的丢失。为了实现高可用性,分布式系统通常采用冗余的方式,即在系统中部署多个备份节点或数据副本。当主节点或数据副本发生故障时,备份节点可以快速接管并继续提供服务。此外,分布式系统还需要考虑容错机制,以确保系统在出现故障时能够快速恢复。
-
低延迟:低延迟是指分布式系统能够快速地响应和处理用户请求,以提供实时的服务。低延迟是分布式系统的重要设计目标之一,尤其是对于那些需要实时响应的应用程序,如在线游戏、金融交易等。为了实现低延迟,分布式系统需要优化网络通信、数据存储和计算资源的分配。例如,采用高速网络、数据缓存和并行计算等技术可以提高系统的响应速度。此外,分布式系统还需要考虑数据的局部性,即尽可能地将数据存储在离用户最近的节点上,以减少数据传输的延迟。
-
数据一致性:确保数据在多个节点上的一致性和完整性。例如,在分布式存储系统中,多个节点需要保证数据的一致性。
面临的挑战
分布式系统面临哪些挑战?
-
故障与部分失效:故障和部分失效是指系统中的某个节点或组件无法正常工作或无法完全满足其预期功能的情况。故障和部分失效是不可避免的,因为系统中的各个节点和组件可能会受到各种因素的影响,如硬件故障、网络故障、软件错误乃至人为导致的错误等。
-
网络异常:在分布式系统中,网络是各个节点之间进行通信和数据传输的基础。然而,由于网络本身的特性,网络问题可能会导致分布式系统出现不可靠的情况,比如网络延迟、网络拥塞、网络分区甚至网络中断。
-
不可靠的时钟:在分布式系统中,各个节点的时钟可能不同步,这被称为不可靠的时钟。由于各个节点的时钟可能会受到各种因素的影响,如时钟漂移、网络延迟等,因此节点之间的时间可能会出现差异。这种时间差异可能会导致分布式系统中的一些操作出现问题,例如:
-
事务排序问题:如果各个节点的时钟不同步,那么分布式系统中的事务可能会按照不同的顺序执行,从而导致数据不一致。
-
超时问题:在分布式系统中,通常会使用超时机制来确保某个操作能够在一定时间内完成。如果各个节点的时钟不同步,那么超时时间可能会不同,从而导致操作无法正常完成。
-
集中式系统、分布式系统和分布式单体系统
集中式系统
集中式系统是指将所有的计算和数据存储都集中在一个中心节点或服务器上进行处理的系统。在集中式系统中,客户端通过网络与中心节点进行通信和数据交换。
集中式系统的优点包括:
-
易于管理和维护:因为所有的计算和数据都在一个地方进行处理,所以管理和维护相对简单。
-
性能较好:由于数据和计算都在同一个地方进行,避免了分布式系统中数据传输和协调的开销,因此性能可能较好。
-
数据一致性容易保证:在集中式系统中,数据通常只存在一个副本,因此更容易保证数据的一致性。
然而,集中式系统也存在一些缺点,例如:
-
可伸缩性较差:集中式系统的处理能力和存储容量受到中心节点的限制,难以通过添加更多节点来扩展系统规模。
-
单点故障风险:如果中心节点出现故障,整个系统可能会瘫痪,导致服务中断。
-
网络依赖性:集中式系统对网络的依赖性较高,如果网络出现问题,可能会影响整个系统的运行。
分布式单体应用
分布式单体应用(Distributed Monolithic Application)是一种将单体应用(Monolithic Application)部署在分布式环境中的架构模式。
在传统的单体应用中,所有的业务逻辑、数据存储和用户界面都被打包在一个单一的应用程序中。而在分布式单体应用中,虽然应用程序仍然作为一个整体进行开发和部署,但它被分布在多个服务器或计算节点上,以实现更高的可伸缩性、容错性和性能。
-
将单体应用程序部署在多个节点上,以提高系统的性能、可靠性和可伸缩性。
-
各个模块或服务之间通过网络进行通信和协作,以实现整个系统的功能。
-
通常使用容器技术(如 Docker)进行部署,以确保每个模块或服务在不同的环境中能够正常运行。
总的来说,分布式单体应用是一种介于传统单体应用和分布式系统之间的架构模式,它结合了两者的一些优点,但也仍然存在一些挑战和问题。在选择系统架构时,需要根据具体的业务需求和技术要求进行权衡和选择。
三者之间的区别
| 分布式系统 | 集中式系统 | 分布式单体应用 | |
|---|---|---|---|
| 体系结构 | 由多个独立的服务组成,每个服务可以单独部署、扩展和更新,通过轻量级的通信机制(如 HTTP、RPC 或消息队列)进行交互。 | 通常由单个中心节点处理所有任务。 | 将单体应用程序部署在多个节点上,各模块之间的协调和通信通常较为简单。 |
| 可伸缩性 | 高,可以通过添加更多节点来轻松扩展系统规模。 | 差,受到中心节点的能力限制。 | 较好,但也受到单个应用程序的限制。 |
| 容错性 | 高,分布式系统通常具有更好的容错能力,因为即使某个节点出现故障,其他节点仍然可以继续工作。 | 差,中心节点故障,整个系统可能会瘫痪。 | 取决于应用程序本身的设计和实现。 |
| 性能 | 可以通过并行处理来提高系统性能,但在数据传输和协调方面可能会有一些开销。 | 在处理大量数据时性能较好。 | 取决于应用程序的设计和实现,以及硬件资源的配置。 |
| 数据一致性 | 由于数据分布在多个节点上,实现数据一致性可能更具挑战性 | 更容易保证数据的一致性。 | 分布式单体应用的数据一致性问题通常较为简单,但也需要考虑数据的分布式存储和处理。 |
| 灵活性 | 分布式系统通常更灵活,因为可以根据需求动态调整节点的角色和功能。 | 较差 | 较好,可以根据需要进行模块的拆分和组合。 |
| 复杂度 | 相对复杂,需要考虑网络延迟、节点故障、数据一致性等问题。 | 相对简单,更容易理解和维护。 | 介于两者之间,但也需要考虑分布式环境下的一些特殊问题。 |
分布式系统和集群
从进程角度看,如果两个程序分别运行在两台主机的进程上,它们相互协作最终完成同一个服务(或者功能),那么理论上这两个程序所组成的系统,也可以称作是“分布式系统”。
当然,这两个程序可以是不同的程序,也可以是相同的程序。如果是相同的程序,我们又可以称之为“集群”。
集群是一种特殊的分布式系统,它由多个相同的计算机组成,这些计算机协同工作以提供更高的性能和可靠性。在集群中,所有的计算机都运行相同的操作系统和应用程序,并且它们之间通过网络进行通信和协调。集群的目标是通过增加计算机的数量来提高系统的性能和可靠性,同时保持系统的单一性和一致性。
分布式系统与微服务
分布式系统和微服务都是用于构建大规模、高可用和可伸缩的应用程序的架构模式,但它们的侧重点和实现方式略有不同。
分布式系统:
-
是指将应用程序的各个组件分布在多个节点上,通过网络进行通信和协作,以实现系统的功能。
-
强调系统的整体性能、可靠性和可伸缩性,通常采用分布式数据库、分布式缓存、分布式文件系统等技术来实现数据的共享和一致性。
-
可以更好地支持高并发、大数据量的处理,适用于构建大型的企业级应用程序。
微服务:
-
是一种基于分布式系统的架构模式,它将应用程序拆分为多个独立的服务,每个服务都可以独立开发、部署和运维。
-
强调服务的自治性和独立性,每个服务都有自己的数据库、缓存、文件系统等资源,并且可以通过轻量级的通信机制(如 HTTP、RPC 等)与其他服务进行交互。
-
可以更好地支持敏捷开发和持续交付,因为每个服务都可以独立开发、测试和部署,而不会影响其他服务。
总的来说,分布式系统和微服务都是为了构建高可用、可伸缩的应用程序而设计的,但分布式系统更注重系统的整体性能和可靠性,而微服务更注重服务的自治性和独立性。在实际应用中,两者可以结合使用,以构建更加灵活、高效的应用程序。
什么是CAP定理?它对分布式系统的设计有什么影响?
一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。
C:数据一致性
数据一致性指的是在分布式系统中,所有节点上的数据在任何时刻都是一致的。也就是说,无论从哪个节点读取数据,都能得到相同的结果。
任何一个读取返回新值后,所有后续读取(在相同或其他客户端上)也必须返回新值。
在线性一致性模型下,如果 Alice 和 Bob 在同一时间刷新并获得了两个不同的查询结果,这可能是因为系统中存在多个数据副本,并且这些副本之间的数据同步存在延迟。在这种情况下,Bob 的请求路由到了一个落后的数据库副本,导致他获取到了陈旧的数据。这表明系统的数据一致性存在问题,没有满足线性一致性的要求。
A:可用性
可用性指的是系统在任何时刻都能提供服务并响应请求。即使某些节点出现故障或网络分区,系统仍然能够正常工作并提供服务。
-
如果部分节点宕机了或者系统崩溃了,而其他节点依然能正常接收请求,那么,我们说系统依然是可用的,也就是说,部分宕机没事儿,不影响可用性指标。
-
如果节点能正常接收请求,但是发现节点内部数据有问题,那么也必须返回结果,哪怕返回的结果是有问题的。比如,系统有两个节点,其中有一个节点数据是三天前的,另一个节点是两分钟前的,如果,一个读请求跑到了包含了三天前数据的那个节点上,抱歉,这个节点不能拒绝,必须返回这个三天前的数据,即使它可能不太合理。
P:分区容忍性
分布式的存储系统会有很多的节点,这些节点都是通过网络进行通信。而网络是不可靠的,当节点和节点之间的通信出现了问题,此时,就称当前的分布式存储系统出现了分区。但是,值得一提的是,分区并不一定是由网络故障引起的,也可能是因为机器故障。
综上,我们可以知道,只要在分布式系统中,节点通信出现了问题,那么就出现了分区。
CAP怎么选择?
在分布式系统内,P 是必然的发生的,不选 P,一旦发生分区错误,整个分布式系统就完全无法使用了,这是不符合实际需要的。所以,对于分布式系统,我们只能考虑当发生分区错误时,如何选择一致性和可用性。
而根据一致性和可用性的选择不同,开源的分布式系统往往又被分为 CP 系统和 AP 系统。
CP系统:当一套系统在发生分区故障后,客户端的任何请求都被卡死或者超时,但是,系统的每个节点总是会返回一致的数据,则这套系统就是 CP 系统,Zookeeper 是一个典型的 CP 系统,它在面对分区故障时会牺牲可用性来保证一致性。如果发生分区故障,Zookeeper 可能会返回错误或超时,但它确保了每个节点返回的数据是一致的。
AP系统:如果一套系统发生分区故障后,客户端依然可以访问系统,但是获取的数据有的是新的数据,有的还是老数据,那么这套系统就是 AP 系统。典型的 AP 系统比如Eureka ,它在面对分区故障时会牺牲一致性来保证可用性。即使发生分区故障,Eureka 仍然可以提供服务,但可能返回不一致的数据。
引申出来的 BASE理论
BASE 理论是对 CAP 理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。
BASE 理论是实践工程的理论,它弥补了CAP 理论过于抽象的问题,也同时解决了 AP 系统的总体工程实践思想,是分布式系统的核心理论之一。
BASE理论强调了基本可用(Basically Available)、软状态(Soft State)和最终一致性(Eventually Consistent)。
-
基本可用:意味着系统在面对部分故障或网络分区时仍然能够提供基本的功能和服务。例如,在一个电子商务网站中,如果某些服务器或网络出现故障,基本可用意味着用户仍然可以浏览产品目录、查看购物车和进行付款等基本操作,但可能会暂时无法查看产品详细信息或查看订单状态。
-
软状态:软状态表示系统可以允许数据存在一定的不一致性,但会通过一些机制来修复和同步数据,以达到最终一致性。例如,在一个分布式数据库中,当某个节点的数据发生更改时,系统可能不会立即将更改同步到其他节点。而是会在后续的某个时间点进行数据同步,以保证最终一致性。
-
最终一致性:最终一致性意味着虽然在某些时刻数据可能不一致,但系统会保证在一定时间后数据会达到一致的状态。
总结
分布式系统具有可伸缩性好、可靠性高、安全性好、网络延迟低等优点,但也存在复杂性高、性能可能较差、管理和维护困难等缺点。在设计分布式系统时,需要根据具体的业务需求和场景,权衡数据一致性、可用性和分区容错性之间的关系,选择适当的方案。
参考文章
《数据密集型应用系统设计》