【分布式】分布式架构

简介: 笔记

一、前言


  在大数据系统中,分布式系统已经成为一个无法避免的组件,如zookeeper已经成为了工业届的标准。所以对于大数据的研究,也必须要研究分布式系统的特点。


二、集中式系统


  由一台或多台计算机组成的中心节点,数据集中存储在这个中心节点中,并且整个系统的所有业务单元都集中部署在这个中心节点上,系统的所有功能均由其集中处理。其部署简单,不用考虑多个节点间的分布式协作问题。


三、分布式系统


  分布式系统是一个由硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。其拥有如下特点

 

 3.1 分布性

  分布式系统中的多台计算机都会在空间中随意分布,同时,机器的分布情况也会随时变动。

 

 3.2 对等性

  分布式系统中的计算机没有主/从之分,既没有控制整个系统的主机,也没有被控制的从机,组成分布式系统的所有计算机节点都是对等的,副本指的是分布式系统对数据和服务提供的一种冗余方式,为了对外提供高可用的服务,我们往往会对数据和服务进行副本处理。数据副本是指在不同的节点上持久化同一份数据,当某一个节点上存储的数据丢失时,可以从副本上读取到该数据,这是解决分布式系统数据丢失问题最为有效的手段。服务副本是只多个节点提供同样的服务,每个节点都有能力接受来自外部的请求并进行相应的处理。

  3.3 并发性


  同一分布式系统中的多个节点,可能会并发地操作一些共享资源,诸如数据库或分布式存储等,如何高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一。

  3.4 缺乏全局时钟

  

典型的分布式系统由一系列在空间上随意分布的多个进程组成,具有明显的分布性,这些进程之间通过交换消息来进行互相通信,因此,在分布式系统中,很难定义两个时间究竟谁先谁后,原因就是因为分布式系统缺乏一个全局的时钟序列控制。

  

3.5 故障总是会发生

  组成分布式系统的所有计算机,都有可能发生任何形式的故障,任何在设计阶段考虑到的异常情况,一定会在系统实际运行中发生。


四、分布式环境的问题


 

 4.1 通信异常

  从集中式到分布式,必然引入了网络因素,而由于网络本身的不可靠性,因此就引入了额外的问题。分布式系统各节点之间的网络通信能够正常进行,其延时也会远大于单机操作,在消息的收发过程中,消息丢失和消息延迟变得十分普遍。

 

 4.2 网络分区

  当网络发生异常情况时,导致分布式系统中部分节点之间的网络延时不断增大,最终导致组成分布式胸的所有节点中,只有部分节点之间能够正常通信,而另一些节点则不能,这种现象称之为网络分区,当网络分区出现时,分布式系统会出现局部小集群,在极端情况下,这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能,包括对数据的事务处理,这就对分布式一致性提出了非常大的挑战。

  

4.3 三态

  由于网络可能会出现各种各样的问题,因此分布式系统的每一次请求与响应,存在特有的三态概念:成功、失败、超时。当网络在异常情况下,可能会出现超时现象,通常由以下两种情况:1. 由于网络原因,该请求并没有被成功地发送到接收方,而是在发送过程就发生了消息丢失现象。2. 该请求成功的被接收方接受后,并进行了处理,但是在将响应反馈给发送方时,发生了消息丢失现象。

 

 4.4 节点故障

  节点故障是指组成分布式系统的服务器节点出现宕机或僵死现象,每个节点都有可能出现故障,并且煤炭都在发生。


五、从ACID到CAP/BASE


 

 5.1 ACID

  事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行单元,狭义上的食物特指数据库事务。一方面,当多个应用程序并发访问数据库时,食物可以在这些应用程序之间提供一个隔离方法,以防止彼此的操作相互干扰,另一方面,食物为数据库操作序列提供了一个从失败中恢复到正常状态的方法,同时提供了数据库即使在宜昌状态下仍能保持数据一致性的方法。事务具有原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability),简称ACID。

  ① 原子性,指事务必须是一个原子的操作序列单元,事务中包含的各项操作在一次执行过程中,只允许出现以下两种状态之一,全部成功执行,全部不执行。任何一项操作失败都将导致整个事务失败,同时其他已经被执行的操作都将被撤销并回滚,只有所有操作全部成功,整个事务才算是成功完成。

  ② 一致性,指事务的执行不能破坏数据库数据的完整性和一致性,一个事务在执行之前和执行之后,数据库都必须处于一致性状态,即事务执行的结果必须是使数据库从一个一致性状态转变到另一个一致性状态,因此当数据库只包含成功事务提交的结果时,就能说数据库处于一致性状态,而如果数据库系统在运行过程中发生故障,有些事务尚未完成就被迫中断,这些未完成的事务对数据库所做的修改有一部分已写入物理数据库,这时数据库就处于一种不正确的状态,或者说是不一致的状态。

  ③ 隔离性,指在并发环境中,并发的事务是相互隔离的,一个事务的执行不能被其他事务干扰,即不同的事务并发操作相同的数据时,每个事务都有各自完整的数据空间,即一个事务内部的操作及使用的数据对其他并发事务是隔离的,并发执行的各个事务之间不能相互干扰。

  ④ 持久性,指一个事务一旦提交,他对数据库中对应数据的状态变更就应该是永久的,即一旦某个事务成功结束,那么它对数据库所做的更新就必须被永久的保存下来,即使发生系统崩溃或者宕机故障,只要数据库能够重新启动,那么一定能够将其恢复到事务成功结束时的状态。

 

 5.2 分布式事务

  分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上,通常一个分布式事务中会涉及对多个数据源或业务系统的操作。一个分布式事务可以看做是由多个分布式的操作序列组成,通常可以把这一系列分布式的操作序列称为子事务。由于在分布式事务中,各个子事务的执行是分布式的,因此要实现一种能够保证ACID特性的分布式事务处理系统就显得格外复杂。

 

 5.3 CAP

  CAP理论告诉我们,一个分布式系统不可能同时满足一致性、可用性、分区容错性这三个基本需求,最多只能同时满足其中的两个。

  ① 一致性,指数据在多个副本之间是否能够保持一致的特性,在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致状态。对于一个将数据副本分布在不同分布式节点上的系统来来说,如果对第一个结点的数据进行了更新操作并且成功后,却没有使得第二个节点上的数据得到相应的更新,于是在对第二个结点的数据进行读取操作时,获取的仍然是老数据(脏数据),这就是典型的分布式数据不一致的情况,在分布式系统中,如果能够做到针对一个数据项的更新操作执行成功后,所有的用户都可以读取到期最新的值,那么这样的系统就被认为具有强一致性。

  ② 可用性,指系统提供的服务必须一直处于可用的状态,对于用户的每一操作请求总是能够在有限的时间内返回结果。

  ③ 分区容错性,分布式系统在遇到任何网络分区故障时,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。

 

 5.4 BASE

  BASE是基本可用(Basically Available)、Soft state(弱状态)、Eventually consistent(最终一致性)三个短语的简写。

  ① 基本可用,指分布式系统在出现不可预知故障时,允许损失部分可用性,如响应时间上的损失或功能上的损失。

  ② 弱状态,也称为软状态,指允许系统中的二数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

  ③ 最终一致性,指系统中所有的数据副本,在经过一段时回见的同步后,最终能够达到一个一致的状态,因此最终一致性的本质是需要系统保证数据能够达到一致,而不需要实时保证系统数据的强一致性。


六、总结


  这篇博文主要介绍了分布式的一些相关知识,更详细的知识之后会给出。谢谢各位园友的观看~

目录
相关文章
|
5月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
2月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
2月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
292 1
|
6月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
348 61
|
7月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
2318 57
|
11月前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
734 8
|
7月前
|
消息中间件 缓存 算法
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
343 0
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
|
9月前
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
762 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
|
9月前
|
人工智能 运维 监控
领先AI企业经验谈:探究AI分布式推理网络架构实践
当前,AI行业正处于快速发展的关键时期。继DeepSeek大放异彩之后,又一款备受瞩目的AI智能体产品Manus横空出世。Manus具备独立思考、规划和执行复杂任务的能力,其多智能体架构能够自主调用工具。在GAIA基准测试中,Manus的性能超越了OpenAI同层次的大模型,展现出卓越的技术实力。
|
11月前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
1151 41

热门文章

最新文章