分布式系统 订阅
分布式系统(distributed system)是建立在网络之上的软件系统。正是因为软件的特性,所以分布式系统具有高度的内聚性和透明性。因此,网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统),而不是硬件。 [1] 展开全文
分布式系统(distributed system)是建立在网络之上的软件系统。正是因为软件的特性,所以分布式系统具有高度的内聚性和透明性。因此,网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统),而不是硬件。 [1]
信息
类    型
软件系统
特    点
内聚性和透明性
中文名
分布式系统
外文名
distributed system
分布式系统简介
在一个分布式系统中,一组独立的计算机展现给用户的是一个统一的整体,就好像是一个系统似的。系统拥 有多种通用的物理和逻辑资源,可以动态的分配任务,分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常,对用户来说,分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件(middleware)负责实现这个模型。一个著名的分布式系统的例子是万维网(World Wide Web),在万维网中,所有的一切看起来就好像是一个文档(Web页面)一样。 [1]  在计算机网络中,这种统一性、模型以及其中的软件都不存在。用户看到的是实际的机器,计算机网络并没有使这些机器看起来是统一的。如果这些机器有不同的硬件或者不同的操作系统,那么,这些差异对于用户来说都是完全可见的。如果一个用户希望在一台远程机器上运行一个程序,那么,他必须登陆到远程机器上,然后在那台机器上运行该程序。 [1]  分布式系统和计算机网络系统的共同点是:多数分布式系统是建立在计算机网络之上的,所以分布式系统与计算机网络在物理结构上是基本相同的。 [1]  他们的区别在于:分布式操作系统的设计思想和网络操作系统是不同的,这决定了他们在结构、工作方式和功能上也不同。网络操作系统要求网络用户在使用网络资源时首先必须了解网络资源,网络用户必须知道网络中各个计算机的功能与配置、软件资源、网络文件结构等情况,在网络中如果用户要读一个共享文件时,用户必须知道这个文件放在哪一台计算机的哪一个目录下;分布式操作系统是以全局方式管理系统资源的,它可以为用户任意调度网络资源,并且调度过程是“透明”的。当用户提交一个作业时,分布式操作系统能够根据需要在系统中选择最合适的处理器,将用户的作业提交到该处理程序,在处理器完成作业后,将结果传给用户。在这个过程中,用户并不会意识到有多个处理器的存在,这个系统就像是一个处理器一样。 [1]  内聚性是指每一个数据库分布节点高度自治,有本地的数据库管理系统。透明性是指每一个数据库分布节点对用户的应用来说都是透明的,看不出是本地还是远程。在分布式数据库系统中,用户感觉不到数据是分布的,即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。 [1] 
收起全文
精华内容
参与话题
问答
  • 分布式系统

    2018-06-15 14:01:58
    分布式系统,要用到哪些技术正文 虽然本人目前正在学习分布式这一块 ,主要包括CAP理论、分布式存储与分布式事务,但对于分布式系统,并没有一个跟清晰的概念。分布式系统涉及到很多的技术、理论与协议,很多人也说...

    分布式系统,要用到哪些技术

    正文

      虽然本人目前正在学习分布式这一块 ,主要包括CAP理论分布式存储分布式事务,但对于分布式系统,并没有一个跟清晰的概念。分布式系统涉及到很多的技术、理论与协议,很多人也说,分布式系统是“入门容易,深入难”,我之前的学习也只算是管中窥豹,只见得其中一斑。因此,一致希望能对分布式系统有一个更全面的认识,至少能够把分布式系统中的各个技术、理论串起来,了解他们在分布式系统分别解决什么问题,有哪些优秀的实现。

    什么是分布式系统

    分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器,处理更多的数据

      首先需要明确的是,只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候,且硬件的提升(加内存、加磁盘、使用更好的CPU)高昂到得不偿失的时候,应用程序也不能进一步优化的时候,我们才需要考虑分布式系统。因为,分布式系统要解决的问题本身就是和单机系统一样的,而由于分布式系统多节点、通过网络通信的拓扑结构,会引入很多单机系统没有的问题,为了解决这些问题又会引入更多的机制、协议,带来更多的问题。。。

      在很多文章中,主要讲分布式系统分为分布式计算(computation)与分布式存储(storage)。计算与存储是相辅相成的,计算需要数据,要么来自实时数据(流数据),要么来自存储的数据;而计算的结果也是需要存储的。在操作系统中,对计算与存储有非常详尽的讨论,分布式系统只不过将这些理论推广到多个节点罢了。

      那么分布式系统怎么将任务分发到这些计算机节点呢,很简单的思想,分而治之,即分片(partition)。对于计算,那么就是对计算任务进行切换,每个节点算一些,最终汇总就行了,这就是MapReduce的思想;对于存储,更好理解一下,每个节点存一部分数据就行了。当数据规模变大的时候,Partition是唯一的选择,同时也会带来一些好处:

      (1)提升性能和并发,操作被分发到不同的分片,相互独立

      (2)提升系统的可用性,即使部分分片不能用,其他分片不会受到影响

      理想的情况下,有分片就行了,但事实的情况却不大理想。原因在于,分布式系统中有大量的节点,且通过网络通信。单个节点的故障(进程crash、断电、磁盘损坏)是个小概率事件,但整个系统的故障率会随节点的增加而指数级增加,网络通信也可能出现断网、高延迟的情况。在这种一定会出现的“异常”情况下,分布式系统还是需要继续稳定的对外提供服务,即需要较强的容错性。最简单的办法,就是冗余或者复制集(Replication),即多个节点负责同一个任务,最为常见的就是分布式存储中,多个节点复杂存储同一份数据,以此增强可用性与可靠性。同时,Replication也会带来性能的提升,比如数据的locality可以减少用户的等待时间。

    分布式系统的优点

      分布式系统需要大量机器协作,面临诸多的挑战:

      第一,异构的机器与网络:

        分布式系统中的机器,配置不一样,其上运行的服务也可能由不同的语言、架构实现,因此处理能力也不一样;节点间通过网络连接,而不同网络运营商提供的网络的带宽、延时、丢包率又不一样。怎么保证大家齐头并进,共同完成目标,这四个不小的挑战。

      第二,普遍的节点故障:

        虽然单个节点的故障概率较低,但节点数目达到一定规模,出故障的概率就变高了。分布式系统需要保证故障发生的时候,系统仍然是可用的,这就需要监控节点的状态,在节点故障的情况下将该节点负责的计算、存储任务转移到其他节点

      第三,不可靠的网络:

        节点间通过网络通信,而网络是不可靠的。可能的网络问题包括:网络分割、延时、丢包、乱序。

        相比单机过程调用,网络通信最让人头疼的是超时:节点A向节点B发出请求,在约定的时间内没有收到节点B的响应,那么B是否处理了请求,这个是不确定的,这个不确定会带来诸多问题,最简单的,是否要重试请求,节点B会不会多次处理同一个请求。

      总而言之,分布式的挑战来自不确定性,不确定计算机什么时候crash、断电,不确定磁盘什么时候损坏,不确定每次网络通信要延迟多久,也不确定通信对端是否处理了发送的消息。而分布式的规模放大了这个不确定性,不确定性是令人讨厌的,所以有诸多的分布式理论、协议来保证在这种不确定性的情况下,系统还能继续正常工作。

    分布式系统的特征与衡量标准

    透明性:使用分布式系统的用户并不关心系统是怎么实现的,也不关心读到的数据来自哪个节点,对用户而言,分布式系统的最高境界是用户根本感知不到这是一个分布式系统。

    可扩展性:分布式系统的根本目标就是为了处理单个计算机无法处理的任务,当任务增加的时候,分布式系统的处理能力需要随之增加。简单来说,要比较方便的通过增加机器来应对数据量的增长,同时,当任务规模缩减的时候,可以撤掉一些多余的机器,达到动态伸缩的效果

      可用性与可靠性:一般来说,分布式系统是需要长时间甚至7*24小时提供服务的。可用性是指系统在各种情况对外提供服务的能力,简单来说,可以通过不可用时间与正常服务时间的必知来衡量;而可靠性而是指计算结果正确、存储的数据不丢失。

      高性能:不管是单机还是分布式系统,大家都非常关注性能。不同的系统对性能的衡量指标是不同的,最常见的:高并发,单位时间内处理的任务越多越好;低延迟:每个任务的平均时间越少越好。这个其实跟操作系统CPU的调度策略很像

      一致性:分布式系统为了提高可用性可靠性,一般会引入冗余(复制集)。那么如何保证这些节点上的状态一致,这就是分布式系统不得不面对的一致性问题。一致性有很多等级,一致性越强,对用户越友好,但会制约系统的可用性;一致性等级越低,用户就需要兼容数据不一致的情况,但系统的可用性、并发性很高很多。

    用一个请求串起来

      用户使用Web、APP、SDK,通过HTTP、TCP连接到系统。在分布式系统中,为了高并发、高可用,一般都是多个节点提供相同的服务。那么,第一个问题就是具体选择哪个节点来提供服务,这个就是负载均衡(load balance)。负载均衡的思想很简单,但使用非常广泛,在分布式系统、大型网站的方方面面都有使用,或者说,只要涉及到多个节点提供同质的服务,就需要负载均衡。

      通过负载均衡找到一个节点,接下来就是真正处理用户的请求,请求有可能简单,也有可能很复杂。简单的请求,比如读取数据,那么很可能是有缓存的,即分布式缓存,如果缓存没有命中,那么需要去数据库拉取数据。对于复杂的请求,可能会调用到系统中其他的服务。

      承上,假设服务A需要调用服务B的服务,首先两个节点需要通信,网络通信都是建立在TCP/IP协议的基础上,但是,每个应用都手写socket是一件冗杂、低效的事情,因此需要应用层的封装,因此有了HTTP、FTP等各种应用层协议。当系统愈加复杂,提供大量的http接口也是一件困难的事情。因此,有了更进一步的抽象,那就是RPC(remote produce call),是的远程调用就跟本地过程调用一样方便,屏蔽了网络通信等诸多细节,增加新的接口也更加方便。

      一个请求可能包含诸多操作,即在服务A上做一些操作,然后在服务B上做另一些操作。比如简化版的网络购物,在订单服务上发货,在账户服务上扣款。这两个操作需要保证原子性,要么都成功,要么都不操作。这就涉及到分布式事务的问题,分布式事务是从应用层面保证一致性:某种守恒关系。

      上面说道一个请求包含多个操作,其实就是涉及到多个服务,分布式系统中有大量的服务,每个服务又是多个节点组成。那么一个服务怎么找到另一个服务(的某个节点呢)?通信是需要地址的,怎么获取这个地址,最简单的办法就是配置文件写死,或者写入到数据库,但这些方法在节点数据巨大、节点动态增删的时候都不大方便,这个时候就需要服务注册与发现:提供服务的节点向一个协调中心注册自己的地址,使用服务的节点去协调中心拉取地址。

      从上可以看见,协调中心提供了中心化的服务:以一组节点提供类似单点的服务,使用非常广泛,比如命令服务、分布式锁。协调中心最出名的就是chubby,zookeeper。

      回到用户请求这个点,请求操作会产生一些数据、日志,通常为信息,其他一些系统可能会对这些消息感兴趣,比如个性化推荐、监控等,这里就抽象出了两个概念,消息的生产者与消费者。那么生产者怎么讲消息发送给消费者呢,RPC并不是一个很好的选择,因为RPC肯定得指定消息发给谁,但实际的情况是生产者并不清楚、也不关心谁会消费这个消息,这个时候消息队列就出马了。简单来说,生产者只用往消息队列里面发就行了,队列会将消息按主题(topic)分发给关注这个主题的消费者。消息队列起到了异步处理、应用解耦的作用。

      上面提到,用户操作会产生一些数据,这些数据忠实记录了用户的操作习惯、喜好,是各行各业最宝贵的财富。比如各种推荐、广告投放、自动识别。这就催生了分布式计算平台,比如Hadoop,Storm等,用来处理这些海量的数据。

      最后,用户的操作完成之后,用户的数据需要持久化,但数据量很大,大到按个节点无法存储,那么这个时候就需要分布式存储:将数据进行划分放在不同的节点上,同时,为了防止数据的丢失,每一份数据会保存多分。传统的关系型数据库是单点存储,为了在应用层透明的情况下分库分表,会引用额外的代理层。而对于NoSql,一般天然支持分布式。

    一个简化的架构图

      下面用一个不大精确的架构图,尽量还原分布式系统的组成部分(不过只能体现出技术,不好体现出理论)

      

     

    概念与实现

      那么对于上面的各种技术与理论,业界有哪些实现呢,下面进行简单罗列。

      当然,下面的这些实现,小部分我用过,知其所以然;大部分听说过,知其然;还有一部分之前闻所未闻,分类也不一定正确,只是从其他文章抄过来的。罗列在这里,以便日后或深或浅的学习。

     

    • 负载均衡:

        Nginx:高性能、高并发的web服务器;功能包括负载均衡、反向代理、静态内容缓存、访问控制;工作在应用层

        LVS: Linux virtual server,基于集群技术和Linux操作系统实现一个高性能、高可用的服务器;工作在网络层

    • webserver:

        Java:Tomcat,Apache,Jboss

        Python:gunicorn、uwsgi、twisted、webpy、tornado

    • service:  

        SOA、微服务、spring boot,django

    • 容器:

        docker,kubernetes

    • cache:

        memcache、redis等

    • 协调中心:

        zookeeper、etcd等

        zookeeper使用了Paxos协议Paxos是强一致性,高可用的去中心化分布式。zookeeper的使用场景非常广泛,之后细讲。

    • rpc框架:

        grpc、dubbo、brpc

        dubbo是阿里开源的Java语言开发的高性能RPC框架,在阿里系的诸多架构中,都使用了dubbo + spring boot

    • 消息队列:

        kafka、rabbitMQ、rocketMQ、QSP

        消息队列的应用场景:异步处理、应用解耦、流量削锋和消息通讯

    • 实时数据平台:

        storm、akka

    • 离线数据平台:

        hadoop、spark

        PS: apark、akka、kafka都是scala语言写的,看到这个语言还是很牛逼的

    • dbproxy:

        cobar也是阿里开源的,在阿里系中使用也非常广泛,是关系型数据库的sharding + replica 代理

    • db:

        mysql、oracle、MongoDB、HBase

    • 搜索:

        elasticsearch、solr

    • 日志:

        rsyslog、elk、flume







      

    展开全文
  • [分布式系统]全面介绍分布式系统

    千次阅读 2019-08-23 09:25:23
    [分布式系统]全面介绍分布式系统 [声明:本篇文章翻译转载自Stanislav Kozlovski] :A Thorough Introduction to Distributed Systems。 很感谢原作者这么通俗易懂介绍分布式系统。考虑在国内访问不到该作者的...

    [分布式系统]全面介绍分布式系统

    [声明:本篇文章翻译转载自Stanislav Kozlovski] :A Thorough Introduction to Distributed Systems。

    很感谢原作者这么通俗易懂介绍分布式系统。考虑在国内访问不到该作者的文章,以及自己学习的便利性,想在这里和大家分享一下 Stanislav Kozlovski 作者的文章。

    什么是分布式系统?为什么这么复杂?

    全文目录

    介绍

    1. 什么是分布式系统?
    1. 为什么分发系统?
    1. 数据库缩放示例

    分布式系统类别

    1. 分布式数据存储
    1. 分布式计算
    1. 分布式文件系统
    1. 分布式消息
    1. 分布式应用
    1. 分布式分类帐

    一、介绍

    随着世界不断增长的技术扩张,分布式系统变得越来越普遍。他们是计算机科学领域的一个庞大而复杂的领域。

    本文旨在以基本方式向您介绍分布式系统,向您展示此类系统的不同类别,同时不深入细节。

    1 、什么是分布式系统

    最简单定义的分布式系统是一组计算机一起工作,以最终用户身份显示为一台计算机。

    这些机器具有共享状态,并发操作并可独立故障,而不会影响整个系统的正常运行时间。

    我建议我们通过分配系统的例子逐步完成工作,以便更好地理解这一切:

    传统的堆栈.png

    让我们来看一个数据库吧!传统的数据库存储在一台机器的文件系统上,无论何时你想要在其中读取/插入信息 - 直接与该机器通信。

     

     

    为了分发这个数据库系统,我们需要让这个数据库同时在多台机器上运行。用户必须能够与他选择的任何一台机器通信,并且不应该能够告诉他他没有与一台机器通话 - 如果他将一条记录插入节点#1,则节点#3必须能够返回该记录。

    可以被视为分布式的体系结构.png

    可以被视为分布式的体系结构

    2、 为什么分发系统?

    系统总是按需分配。事情的真相是 - 管理分布式系统是一个复杂的主题,充满了陷阱和地雷。部署,维护和调试分布式系统令人头疼,为什么要去那里呢?

    分布式系统使您能够做的是横向扩展。回到我们前面的单个数据库服务器的例子,处理更多流量的唯一方法是升级运行数据库的硬件。这称为垂直缩放

    尽管可以垂直缩放,但是在某个点之后,您会发现即使是最好的硬件也不足以提供足够的流量,更不用说主机不切实际了。

    缩放横向意味着添加更多的计算机,而不是升级单个硬件。

    水平缩放在一定的阈值之后变得更便宜.png

    水平缩放在一定的阈值之后变得更便宜

    在一定的阈值之后,它比垂直缩放要便宜得多,但这不是偏好的主要情况。

    垂直缩放只能将性能提升至最新的硬件功能。这些能力证明对于工作量适中到较大的技术公司是不够的。

    关于水平缩放的最好的事情是,您无限制地扩展规模 - 只要性能下降,您只需添加另一台机器,最多可达到无限大。

    轻松扩展并不是从分布式系统获得的唯一好处。容错低延迟也同样重要。

    容错  - 跨越两个数据中心的十台机器集群本质上比单台机器更容错。即使一个数据中心着火,您的应用程序仍然可以工作。

    低延迟 - 网络数据包出行的时间受到光速的限制。例如,纽约到悉尼之间光纤电缆的请求往返时间(即来回)的最短时间为 160ms。分布式系统允许您在两个城市都拥有一个节点,从而使流量达到最接近它的节点。

    但是,要使分布式系统正常工作,需要在这些机器上运行的软件专门设计用于同时在多台计算机上运行,并处理随之而来的问题。事实证明,这并非易事。

    3、 缩放我们的数据库

    想象一下,我们的Web应用程序非常受欢迎。想象一下,我们的数据库每秒处理的查询次数也开始增加两倍。您的应用程序会立即开始降低性能,这会被用户注意到。

    让我们一起工作,并使我们的数据库规模满足我们的高要求。

    在典型的Web应用程序中,您通常比插入新信息或修改旧信息更频繁地读取信息。

    主从复制.png

    有一种方法可以提高读取性能,即通过所谓的主从复制策略。在这里,您创建了两个与主要服务器同步的新数据库服务器。问题是你只能从这些新的实例中读取

    无论何时插入或修改信息 - 您都可以与主数据库通信。反过来,它会异步地通知奴隶的变化,并将它们保存起来。

    恭喜,您现在可以执行3倍的读取查询!这不是很好吗?

    陷阱

    疑难杂症!我们立即失去了关系数据库的ACID保证中的C,它代表一致性。

    你看,现在有一种可能性,我们在数据库中插入一条新的记录,然后立即发出一个读取查询并获取任何东西,就好像它不存在一样!

    将新的信息从主设备传播到从设备不会立即发生。实际上存在一个可以获取陈旧信息的时间窗口。如果情况并非如此,您的写入性能会受到影响,因为它必须同步等待数据传播。

    分布式系统带来了一些折衷。如果你想充分扩展,这个特殊的问题是你必须忍受的。

    继续扩展

    使用从数据库方法,我们可以在一定程度上横向扩展读取流量。这很棒,但我们在写入流量方面遇到了一堵墙 - 它仍然在一台服务器上!

    我们在这里没有太多选择。我们只需要将我们的写入流量分割为多个服务器,因为无法处理它。

    一种方法是采用多主复制策略。在那里,而不是只能读取的从站,您有多个支持读取和写入的主节点。不幸的是,由于您现在有能力创建冲突(例如插入两个具有相同ID的记录),因此这会变得非常复杂。

    让我们继续使用另一种称为分片sharding)的技术(也称为分区)。

    通过分片,您可以将服务器分成多个较小的服务器,称为碎片。这些碎片都拥有不同的记录 - 您创建了哪种记录进入哪个碎片的规则。创建规则以使数据以统一的方式传播非常重要。

    对此的一种可能的方法是根据关于记录的某些信息来定义范围(例如,具有名称AD的用户)。

    继续扩展.png

    应该非常仔细地选择这个分片键,因为基于任意列的负载并不总是相等的。(例如,更多人拥有以C开头而非Z开头的名字)。一个接收更多请求的碎片被称为热点,必须避免。一旦分裂,重新分片的数据变得非常昂贵并且可能导致显着的停机时间,就像FourSquare臭名昭着的11小时停机一样

    为了保持我们的例子简单,假设我们的客户端(Rails应用程序)知道每个记录使用哪个数据库。值得注意的是,有许多分片策略,这是一个简单的例子来说明这个概念。

    我们现在赢得了很多 - 我们可以将写入流量增加N倍,其中N是碎片的数量。这实际上给我们几乎没有限制 - 想象我们可以通过这种分区获得多么细微的粒度。

    陷阱

    软件工程中的一切或多或少都是一种折衷,这也不例外。Sharding不是简单的壮举,而是最好避免直到真正需要

    现在我们通过分区键之外的键进行查询的效率非常低(他们需要遍历所有的分片)。SQL 查询更加糟糕,而且复杂的查询实际上无法使用。 JOIN

    分散与分布(Decentralized vs Distributed)

    为防止翻译偏差:将这段文字粘贴过来
    Decentralized vs Distributed
    Before we go any further I’d like to make a distinction between the two terms.
    Even though the words sound similar and can be concluded to mean the same logically, their difference makes a significant technological and political impact.
    Decentralized is still distributed in the technical sense, but the whole decentralized systems is not owned by one actor. No one company can own a decentralized system, otherwise it wouldn’t be decentralized anymore.
    This means that most systems we will go over today can be thought of as distributed centralized systems — and that is what they’re made to be.
    If you think about it — it is harder to create a decentralized system because then you need to handle the case where some of the participants are malicious. This is not the case with normal distributed systems, as you know you own all the nodes.
    Note: This definition has been debated a lot and can be confused with others (peer-to-peer, federated). In early literature, it’s been defined differently as well. Regardless, what I gave you as a definition is what I feel is the most widely used now that blockchain and cryptocurrencies popularized the term.
    在我们进一步讨论之前,我想区分这两个术语。

    尽管这些词听起来很相似,可以得出结论意味着它们在逻辑上相同,但它们的差异会产生重大的技术和政治影响。

    在技术层面上,分散型仍然是分布式的,但是整个分散式系统并不属于一个行动者。没有一个公司可以拥有分散的系统,否则它不会再分散。

    这意味着我们今天将要发布的大多数系统都可以被看作是分布式集中式系统 - 这就是他们所做的。

    如果你仔细想一想 - 创建一个分散系统就比较困难,因为那时你需要处理一些参与者是恶意的情况。正常分布式系统并非如此,因为您知道您拥有所有节点。

    注意:这个定义已经有很多争论,并且可能会与其他人(对等,联合)混淆。在早期的文献中,它的定义也不尽相同。无论如何,我给你的定义是我认为现在区块链和加密货币推广这个术语的最广泛使用。


    二、分布式系统类别

    我们现在要通过几个分布式系统类别并列出他们最大的公众已知的生产用途。请记住,大部分显示的数字都过时了,而且在阅读本文时可能显着更大。

    1、 分布式数据存储

    分布式数据存储被广泛使用并被公认为分布式数据库。大多数分布式数据库都是NoSQL非关系数据库,仅限于键值语义。它们以一致性或可用性为代价提供令人难以置信的性能和可扩展性。

    已知的规模 -  早在2015年,苹果就已知使用75,000个Apache Cassandra节点存储超过10PB的数据

    没有首先引入CAP定理,我们就不能讨论分布式数据存储

    CAP定理

    CAP定理早在2002年就证明,分布式数据存储不能同时具有一致性,可用性和分区容错性。

    CAP定理1.png

    从3选择2(但不是一致性和可用性)

    一些快速定义:

    • 一致性  - 您按顺序读取和写入的内容是预期的(请记住几个段落前的数据库复制陷阱?)

    • 可用性 - 整个系统不会死亡 - 每个非故障节点总是返回一个响应。

    • 分区容忍 - 尽管存在网络分区,系统仍会继续运行并保持其一致性/可用性保证

    实际上,对于任何分布式数据存储,分区容限必须是给定的。正如许多地方所提到的,其中的一篇文章,如果没有分区容差,就无法保证一致性和可用性。

    想一想:如果你有两个节点接受信息并且他们的连接中断 - 它们将如何可用并同时为你提供一致性?他们无法知道其他节点正在做什么,因此可能变为脱机(不可用)或使用陈旧的信息(不一致)

    CAP定理2.png

    我们做什么?

    最后,您可以选择是否希望系统在网络分区下保持强大的一致性或高可用性。

    实践表明大多数应用程序更重视可用性。你不一定总是需要很强的一致性。即便如此,这种权衡并不一定是因为您需要100%的可用性保证,而是因为在必须同步机器以实现强大的一致性时,网络延迟可能成为一个问题。这些和更多因素使应用程序通常选择提供高可用性的解决方案。

    这些数据库用最弱的一致性模型解决 - 最终的一致性 (强大vs最终一致性解释)。此模型保证,如果没有对给定项目进行新更新,则最终对该项目的所有访问都将返回最新的更新值。

    这些系统提供BASE属性(与传统数据库的ACID相反)

    • asically vailable -系统总是返回一个响应

    • 小号经常状态-该系统可以随着时间的推移,即使是在没有输入的时间变化(由于最终一致性)

    • E公开的一致性 - 在没有输入的情况下,数据迟早会传播到每个节点 - 从而变得一致

    这种可用的分布式数据库的例子 - CassandraRiakVoldemort

    当然,还有其他更喜欢更强一致性的数据存储 --HBaseCouchbaseRedis, Zookeeper

    CAP理论值得自己撰写多篇文章 - 其中一些内容涉及如何根据客户端的行为以及其他如何正确理解它调整系统的CAP属性

    Cassandra

    如上所述,Cassandra是一个分布式的No-SQL数据库,它偏好CAP的属性,并最终保持一致性。我必须承认,这可能有点误导,因为Cassandra具有高度可配置性 - 您可以通过牺牲可用性来提供强大的一致性,但这不是它的常见用例。

    Cassandra使用一致的哈希来确定哪个节点脱离了您的集群必须管理您传递的数据。您设置了一个复制因子,它基本上指出要复制数据的节点数。

    Cassandra1.png

    写样本

    阅读时,只能从这些节点读取。

    Cassandra具有强大的可扩展性,可提供非常高的写入吞吐量。

    Cassandra2.png

    可能有偏见的图,显示每秒写入基准。从这里采取。

    尽管这张图可能有些偏颇,并且它看起来像将Cassandra与数据库集进行比较以提供强大的一致性(否则我无法明白为什么MongoDB在从4个节点升级到8个节点时性能会下降),但它仍应显示正确设置的内容up Cassandra集群是有能力的。

    无论如何,在支持横向扩展和难以置信的高吞吐量的分布式系统平衡中,Cassandra不提供ACID数据库的一些基本特性 - 即事务处理。

    共识

    数据库事务在分布式系统中实现起来很棘手,因为它们要求每个节点都要采取正确的操作(中止或提交)。这被称为共识,这是分布式系统中的一个基本问题。

    如果参与过程和网络完全可靠,那么达成“交易提交”问题所需的协议类型就很简单。但是,真正的系统会受到一些可能的故障的影响,如进程崩溃,网络分区以及丢失,失真或重复的消息。

    这提出了一个问题 - 已证明不可能保证在不可靠网络上的有限时间框架内达成正确的共识。

    但实际上,有些算法很快就会在不可靠的网络上达成共识。Cassandra实际上通过使用用于分布式共识的Paxos算法来提供轻量级事务


    2、分布式计算

    分布式计算是近年来我们见到的大数据处理流入的关键。它是将一项庞大的任务(例如总计1000亿条记录)分割成许多较小的任务的技术,其中任何一台计算机都不能单独执行,而每个任务都可以装入一台商品机器中。您将您的庞大任务分解为许多较小的任务,让它们在多台机器上并行执行,合适地汇总数据,并解决了最初的问题。这种方法再次使您能够水平扩展 - 当您有更大的任务时,只需在计算中包含更多节点。

    已知的规模 - 折叠@家庭在2012年160K活动机器

    这个领域的早期创新者是谷歌,因为他们需要大量的数据必须为分布式计算创造一种新的范式 - MapReduce。他们在2004年发表了一篇论文,而开源社区后来又基于它创建了Apache Hadoop

    MapReduce

    MapReduce可以简单地定义为两个步骤 - 映射数据并将其减少为有意义的数据。

    我们再来看一个例子:

    假设我们是中型企业,我们将庞大的信息存储在二级分布式数据库中用于仓储目的。我们希望获取表示2017年4月(一年前)每天发布的拍手次数的数据。

    这个例子保持尽可能简短,清晰和简单,但想象我们正在处理大量数据(例如分析数十亿次拍子)。我们不会将所有这些信息都存储在一台机器上,我们也不会仅用一台机器来分析所有这些信息。我们也不会查询生产数据库,而是专门为低优先级脱机作业构建的一些“仓库”数据库。

    MapReduce.png

    每个Map作业都是一个单独的节点,它可以转换尽可能多的数据。每个作业都会遍历给定存储节点中的所有数据,并将其映射到日期和数字的简单元组。然后,三个中间步骤(没人谈论)完成 - Shuffle,Sort和Partition。他们基本上进一步安排数据并将其删除到适当的减少工作。在我们处理大数据时,我们将每个Reduce作业分隔开来,仅在单个日期上工作。

    这是一个很好的范例,令人惊讶的是你可以用它做很多事情 - 例如,你可以链接多个MapReduce作业。

    更好的技术

    现在MapReduce有些遗留问题,并带来一些问题。因为它在批处理(作业)中起作用,所以如果您的工作失败,则会出现问题 - 您需要重新开始整个工作。2小时的工作失败可能会让你的整个数据处理流程变慢,而且你并不想这么做,特别是在高峰时段。

    另一个问题是您等待直到您收到结果的时间。在实时分析系统中(所有这些系统都有大量数据,因此使用分布式计算),重要的是要让您的最新数据尽可能的新鲜,当然不是几个小时前。

    因此,出现了解决这些问题的其他体系结构。即Lambda体系结构(混合批量处理和流处理)和Kappa体系结构(仅流处理)。这些领域的进步带来了新的工具 - Kafka Streams, Apache SparkApache StormApache Samza


    3、分布式文件系统

    分布式文件系统可以被认为是分布式数据存储。它们与概念一样 - 在一组机器中存储和访问大量数据,所有这些数据都显示为一个整体。他们通常与分布式计算并驾齐驱。

    已知规模 - 雅虎因在超过42,000个节点上运行HDFS而存储600 PB数据而闻名,早在2011年

    Wikipedia定义的区别在于分布式文件系统允许使用与本地文件相同的接口和语义来访问文件,而不是像Cassandra查询语言(CQL)那样的自定义API 。

    HDFS

    Hadoop分布式文件系统(HDFS)是通过Hadoop框架用于分布式计算的分布式文件系统。它被广泛采用,用于存储和复制大型文件(大小为GB或TB)跨多台机器。

    其架构主要由NameNodeDataNode组成。NameNode负责保存关于集群的元数据,比如哪个节点包含哪些文件块。他们通过找出最佳存储和复制文件的位置,跟踪系统的健康状况,充当网络的协调员。DataNodes只是简单地存储文件并执行命令,如复制文件,写入新文件等等。

    HDFS.png

    毫不奇怪,HDFS最适合用于计算,因为它为计算作业提供数据感知。所述作业然后在存储数据的节点上运行。这利用了数据局部性 - 优化了计算并减少了网络上的流量。

    IPFS

    星际文件系统(IPFS)是一个令人兴奋的新型分布式文件系统对等协议/网络。利用区块链技术,它拥有完全分散的架构,没有单一所有者或故障点。

    IPFS提供了一个名为IPNS的命名系统(类似于DNS),可让用户轻松访问信息。它通过历史版本存储文件,类似于Git的做法。这允许访问文件的所有以前的状态。

    它仍然在经历重大的发展(写作时的v0.4),但已经看到有兴趣构建它的项目(FileCoin)。


    4、分布式消息

    消息传递系统为整个系统内的消息/事件的存储和传播提供了一个中心位置。它们允许您将应用程序逻辑从直接与其他系统交谈中分离出来。

    已知规模 - LinkedIn的Kafka集群每天处理1万亿条消息,每秒处理450万条消息。

    分布式消息.png

    简而言之,消息传递平台的工作原理如下:

    消息从应用程序广播,可能创建它(称为生产者),进入平台并被潜在的多个对其感兴趣的应用程序(称为消费者)读取。

    如果您需要将某个事件保存到几个地方(例如创建用户到数据库,仓库,电子邮件发送服务以及您可以提供的任何其他服务),则消息传递平台是传播该消息的最简单方法。

    消费者可以将信息从经纪人(拉模型)中提取出来,或让经纪人直接将信息推送给消费者(推送模式)。

    有几个流行的顶级消息平台:

    RabbitMQ - 消息代理,允许您通过路由规则和其他易于配置的设置对消息轨迹进行更细粒度的控制。可以称为智能代理,因为它有很多逻辑,并且密切关注通过它的消息。从CAP提供APCP的设置。使用推送模式通知消费者。

    Kafka  - 消息代理(以及所有平台),它有点低级,因为它不能跟踪哪些消息已被读取,并且不允许复杂的路由逻辑。这有助于它实现惊人的性能。在我看来,这是开源社区积极开发和Confluent团队支持的最大前景。卡夫卡可以说是顶尖科技公司使用最广泛的卡夫卡。我写了一篇全面的介绍,我详细介绍了它的所有优点。

    Apache ActiveMQ - 最早的一批,从2004年开始。使用JMS API,这意味着它适用于Java EE应用程序。它被改写为ActiveMQ Artemis,与Kafka相媲美,表现出色。

    Amazon SQS  - 由AWS提供的消息服务。让您可以快速将其与现有应用程序集成,并且无需处理您自己的基础架构,这可能是一个巨大的好处,因为像Kafka这样的系统的安装非常棘手。亚马逊还提供两种类似的服务 - SNSMQ,后者基本上是ActiveMQ,但由亚马逊管理。

    5、分布式应用

    如果您在连接到一个数据库的单个负载均衡器后面集合了5个Rails服务器,您能否称为分布式应用程序?从上面回想我的定义:

    分布式系统是一组计算机一起工作,以便作为单台计算机显示给最终用户。这些机器具有共享状态,并发操作并可独立故障,而不会影响整个系统的正常运行时间。

    如果您将数据库视为共享状态,那么您可以争辩说这可以归类为分布式系统 - 但是您错了,因为您错过了定义的“ 一起工作 ”部分。

    只有节点彼此通信以协调其行为时才分配系统。

    因此,类似于在对等网络上运行其后端代码的应用程序可以更好地分类为分布式应用程序。无论如何,这都是无用的分类,没有任何用处,但说明我们将事情分组在一起是多么的繁琐。

    已知的规模 - 2014年4月的权力游戏集中的193,000个节点的BitTorrent群

    Erlang虚拟机

    Erlang是一种功能强大的语言,对于并发性,分发和容错有很好的语义。Erlang虚拟机本身处理Erlang应用程序的分发。

    其模型通过使许多独立的 轻量级进程都可以通过内置的消息传递系统与对方进行对话。这被称为Actor模型 ,Erlang OTP库可以被认为是一个分布式的actor框架(沿着JVM 的Akka线)。

    该模型可以帮助它实现极佳的并发性 - 而这些进程遍布在运行系统的可用内核中。由于这与网络设置无法区分(除了丢弃消息的能力),Erlang的虚拟机可以连接到运行在同一个数据中心甚至另一个大陆的其他Erlang虚拟机。这群虚拟机运行一个应用程序,并通过接管来处理机器故障(另一个节点计划运行)。

    事实上,该语言的分布式层被添加以提供容错。运行在单台机器上的软件始终有可能导致单台机器死机并使应用程序脱机。在许多节点上运行的软件允许更轻松地处理硬件故障,只要应用程序是根据这一点构建的。

    BitTorrent

    BitTorrent是通过种子在网络上传输大文件的使用最广泛的协议之一。主要想法是促进网络中不同对端之间的文件传输,而不必通过主服务器。

    使用BitTorrent客户端,您可以连接到世界各地的多台计算机以下载文件。当你打开一个.torrent文件时,你连接到一个所谓的追踪器,这是一台充当协调的机器。它有助于对等发现,向您显示网络中具有所需文件的节点。

    一个示例网络.png

    一个示例网络

    你有两种类型的用户的概念,一个是一个leecher和一个播种机。leecher是正在下载文件的用户,而播种员是上传所述文件的用户。

    关于点对点网络的有趣之处在于,作为普通用户,您有能力加入并贡献于网络。

    BitTorrent及其前身(GnutellaNapster)允许您自愿托管文件并上传给需要它们的其他用户。BitTorrent之所以如此受欢迎的原因在于,它是第一个为激励网络提供激励的公司。在用户只能下载文件的情况下,Freeriding是以前文件共享协议的问题。

    BitTorrent通过使播种机上传更多给那些提供最佳下载速率的人来解决一定程度的自由。它通过激励您在下载文件的同时上传。不幸的是,在你完成之后,没有什么能够让你在网络中保持活跃。这导致在网络中缺少具有完整文件的播种器,并且由于协议严重依赖于这些用户,像私人跟踪器这样的解决方案已经实现。私人追踪器要求您成为社区成员(通常只有邀请)才能参与分布式网络。

    在该领域取得进展之后,发明了无追踪者的种子。这是对BitTorrent协议的升级,它不依赖集中跟踪器来收集元数据并找到对等点,而是使用新算法。其中一个例子是KademliaMainline DHT),一个分布式哈希表(DHT),它允许您通过其他同行找到同行。实际上,每个用户都会执行跟踪器的职责。


    6、分布式分类帐

    分布式账本可以被认为是一个不可变的,仅追加数据库,它在分布式网络中的所有节点上进行复制,同步和共享。

    已知规模 - 以太坊网络在2018年1月4日每天有130万宗高峰

    他们利用事件采购模式,允许您在历史的任何时间重建账目状态。

    Blockchain

    区块链是目前用于分布式分类账的基础技术,实际上标志着它们的开始。分布式空间的这一最新和最伟大的创新使得创建了第一个真正的分布式支付协议 - 比特币。

    区块链是一个分布式分类帐,它载有网络中发生的所有交易的有序列表。事务分组并存储在块中。整个区块链本质上是一个块链接列表(因此名称)。所述块在创建时在计算上是昂贵的,并且通过密码学彼此紧密相关。

    简单地说,每个块包含当前块的内容(以Merkle树的形式)加上前一个块的散列的特殊散列(以X的零数量开始)。这个散列需要大量的CPU能力才能生产出来,因为唯一的办法就是通过暴力破解。

    简化区块链.png

    简化区块链

    矿工是试图计算散列(通过暴力)的节点。矿工们相互竞争,谁可以拿出一个随机的字符串(称为随机数),当与内容结合时产生前述的散列。一旦有人发现了正确的随机数 - 他将其广播到整个网络。所述字符串然后由每个节点自行验证并接受到它们的链中。

    这转化为一个系统,修改区块链的代价非常昂贵,而且很容易验证它没有被篡改。

    改变块的内容是昂贵的,因为这会产生不同的散列。请记住,每个后续块的散列都依赖于它。如果您要在上面的图片的第一个块中更改交易,您可以更改Merkle Root。这反过来会改变块的散列(很可能没有所需的前导零) - 这会改变块#2的散列等等。这意味着你需要在刚刚修改的块之后为每个块强制一个新的随机数。

    网络总是信任并复制最长的有效链。为了欺骗系统并最终产生更长的链,你需要所有节点使用的总CPU功率的50%以上。

    区块链可以被认为是突发共识的分布式机制。没有明确达成共识 - 共识发生时没有选举或固定的时刻。相反,共识是数千个独立节点异步交互的紧急产物,所有节点都遵循协议规则。

    这项前所未有的创新最近成为科技领域的热潮,人们预测它将标志着Web 3.0的诞生。这绝对是目前软件工程领域最激动人心的空间,充满了极具挑战性和有趣的问题,正在等待解决。

    比特币

    以前的分布式支付协议缺乏的是以分散的方式实时防止双重支出问题的方法。研究已经产生了有趣的命题[1],但比特币是第一个实施具有明显优势的实用解决方案。

    双重支出问题指出,一个演员(例如Bob)不能在两个地方花费他的单一资源。如果鲍勃有1美元,他就不应该把它交给爱丽丝和扎克 - 这只是一种资产,它不能被复制。事实证明,在分布式系统中真正实现这种保证是非常困难的。在区块链之前有一些有趣的缓解方法,但它们不能以实用的方式完全解决问题。

    双倍支出可以通过比特币轻松解决,因为一次只能添加一个区块。在一个区块内双重支出是不可能的,因此,即使同时创建两个区块 - 只有一个区块会出现在最长的最长链上。

     

    btc.png

    比特币依靠积累CPU能力的困难。

    在投票系统中,攻击者只需要向网络添加节点(这很容易,因为免费访问网络是设计目标),但在基于CPU电源的方案中,攻击者面临物理限制:越来越多地访问强大的硬件。

    这也是恶意节点组需要控制超过50%的网络计算能力才能实际进行任何成功攻击的原因。少于这一点,网络的其他部分将更快地创建更长的区块链。

    复仇

    以太坊可以被认为是一个基于可编程区块链的软件平台。它拥有自己的加密货币(Ether),加速了区块链上智能合约的部署。

    智能合约是在以太坊区块链中作为单个交易存储的一段代码。要运行代码,您所要做的就是以智能合约作为目标进行交易。这反过来又使矿工节点执行代码以及它发生的任何变化。代码在以太坊虚拟机内执行。

    密实度,复仇的本地编程语言,是什么用来编写智能合同。它是一种图灵完整的编程语言,直接与以太坊区块链接口,允许您查询状态,如余额或其他智能合约结果。为了防止无限循环,运行代码需要一定数量的以太网。

    由于区块链可以解释为一系列状态变化,所以很多分布式应用程序(DApps)都是在以太坊和类似平台的基础上构建的。

    分布式账本的进一步用法

    存在证明 - 匿名服务并安全地存储在某个时间点某个数字文件存在的证据。用于确保文档完整性,所有权和时间戳。

    分散的自治组织(DAO) - 使用区块链作为就组织改进主张达成共识的手段的组织。例子是Dash的治理系统即SmartCash项目

    分散式身份验证 - 将您的身份存储在区块链中,使您能够任何地方使用单点登录(SSO)。Sovrin思域

    还有很多,还有更多。分布式账本技术确实打开了无限的可能性。有些人很可能是在我们说话时被发明的!


    概要

    在本文短小的篇幅中,我们管理着定义什么是分布式系统,为什么要使用它,并稍微检查每个类别。一些重要的事情要记住的是:

    • 分布式系统很复杂

    • 他们是根据规模和价格的必然选择

    • 他们很难与之合作

    • CAP定理 - 一致性/可用性权衡

    • 他们有6个类别 - 数据存储,计算,文件系统,邮件系统,分类帐,应用程序

    坦率地说,我们几乎没有触及分布式系统的表面。我没有改变彻底解决,并解释类似的核心问题达成共识复制策略事件顺序和时间宽容失败广播在网络上的消息他人

    警告

    让我给你留个别预告:

    您必须尽可能远离分布式系统。如果您可以通过以不同方式解决问题或其他开箱即用的解决方案来避免此问题,那么他们自己承担的复杂开销并不值得。


    [1]打击使用合作P2P系统的双重支出,2007年6月25 - 27日 - 一个提议的解决方案,其中每个“硬币”可以过期并被分配一个证人(验证者)。

    Bitgold,2005年12月 - 对与比特币非常相似的协议的高级概述。据说这是比特币的先驱。

    更多分布式系统阅读:

    设计数据密集型应用程序,Martin Kleppmann - 一本超越分布式系统和其他内容的伟大书籍。

    云计算专业化,伊利诺伊大学Coursera - 一系列课程(6)遍历分布式系统概念,应用

    Jepsen - 博客解释了许多分布式技术(ElasticSearch,Redis,MongoDB等)


    感谢您花时间阅读这篇长(约5600字)的文章!

    如果您有任何可能发现这些信息或认为它为您提供了有价值的信息,请确保为其提供尽可能多的您认为值得的拍子,并考虑与可以使用这一精彩研究领域介绍的朋友分享。

    〜Stanislav Kozlovski



    作者:瑾兰
    链接:https://www.jianshu.com/p/bc764647169c

    展开全文
  • 现在的架构很多,各种各样的...那什么是分布式系统分布式系统是支持分布式处理的软件系统,是由通信网络互联的多处理机体系结构上执行任务的系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文...

    现在的架构很多,各种各样的,如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等,还有和这些架构相关的管理型的技术方法,如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等等,还有很多。

    那什么是分布式系统?分布式系统是支持分布式处理的软件系统,是由通信网络互联的多处理机体系结构上执行任务的系统。包括分布式操作系统、分布式程序设计语言及其编译系统、分布式文件系统分布式数据库系统等,当然这些也是分布式的关键技术。

    使用分布式系统主要有:

    1.增大系统容量。我们的业务量越来越大,而要能应对越来越大的业务量,一台机器的性能已经无法满足了,我们需要多台机器才能应对大规模的应用场景。所以,我们需要垂直或是水平拆分业务系统,让其变成一个分布式的架构。

    2.加强系统可用。我们的业务越来越关键,需要提高整个系统架构的可用性,这就意味着架构中不能存在单点故障。这样,整个系统不会因为一台机器出故障而导致整体不可用。所以,需要通过分布式架构来冗余系统以消除单点故障,从而提高系统的可用性。

    3.因为模块化,所以系统模块重用度更高

    4.因为软件服务模块被拆分,开发和发布速度可以并行而变得更快

    5.系统扩展性更高

    6.团队协作流程也会得到改善

    分布式系统的类型有三种:

    1.分布式处理,但只有一个总数据库,没有局部数据库

    2.分层式处理,每一层都有自己的数据库

    3.充分分散的分布式网络,没有中央控制部分,各节点之间的联系方式又可以有多种,如松散的联接,紧密的联接,动态的联接,广播通知式的联接等

    然后来对比一下单体应用和分布式架构的优缺点:

    1.从上面的表格可以看到,分布式系统虽然有一些优势,但也存在一些问题

    2.架构设计变得复杂(尤其是其中的分布式事务)

    3.部署单个服务会比较快,但是如果一次部署需要多个服务,部署会变得复杂

    4.系统的吞吐量会变大,但是响应时间会变长

    5.运维复杂度会因为服务变多而变得很复杂

    6.架构复杂导致学习曲线变大

    7.测试和查错的复杂度增大

    8.技术可以很多样,这会带来维护和运维的复杂度

    9.管理分布式系统中的服务和调度变得困难和复杂


    所以总结一下,分布式系统架构的难点在于系统设计,以及管理和运维。所以分布式系统架构在解决了一些问题的同时,也增加了其他的问题,这就需要不断的再用各种各样的技术跟手段去解决这些新增的问题。后续会跟上分布式系统架构的搭建以及使用。

    Hadoop伪分布式集群搭建使用

    Hadoop HA 高可用关键搭建


    展开全文
  • 目录 什么是分布式系统 分布式系统挑战分布式系统特性与衡量标准 组件、理论、协议 用一个请求串起来一个简化的架构图概念与实现正文 虽然本人在前面也写过好几篇分布式系统相关的文章,主要包括CAP理论、分布式...
    展开全文
  • 分布式系统概念

    万次阅读 多人点赞 2018-11-15 16:25:36
    分布式系统 分布式系统的由来: 国内来讲,移动互联网的爆发伴随着分布式系统的突现,移动互联网最大的特点是2(to)c的o2o产品越来越多,这跟传统2B的系统最大区别就是用户量的不同,2C系统的用户量远远要高于2b...
  • 分布式系统与分布式锁简析

    万次阅读 2019-04-19 09:44:09
    分布式系统涉及到很多的技术、理论与协议,很多人也说,分布式系统是“入门容易,深入难”,有一些人简历上写着熟悉分布式系统,但是其实只能算是管中窥豹,只见得其中一斑。 回到顶部 那么究竟什么是分布式系统...
  • 分布式系统的接口幂等性设计

    万次阅读 2020-08-16 02:26:47
    分布式系统的接口幂等性设计 在微服务架构下,我们在完成一个订单流程时经常遇到下面的场景: 一个订单创建接口,第一次调用超时了,然后调用方重试了一次 在订单创建时,我们需要去扣减库存,这时接口发生了...
  • 分布式系统(一)分布式系统介绍

    千次阅读 2016-06-23 21:27:41
    本文简单介绍什么是分布式系统,我们为什么需要分布式系统分布式系统应该关注的特性有哪些,谷歌文件系统( GFS)的一些简单介绍系列文章的内容整理自清华大学分布式课程主页,课程网站...目录 什么是分布式系统 ...
  •   现在的架构很多,如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等,还有和这些架构相关的管理型的技术方法,如 DevOps、应用监控、自动化...分布式系统是支持分布式处理的软...
  • 分布式系统是什么?2. 分布式系统的优缺点2.1 优点2.2 缺点 1. 分布式系统是什么? 分布式系统(distributed system)由多台计算机和通信的软件组件通过计算机网络连接(本地网络或广域网)组成。 分布式系统是...
  • 分布式系统接口如何保证幂等性

    万次阅读 2020-08-15 18:32:14
    分布式系统接口如何保证幂等性 接口幂等性 为了防止上述情况的发生,我们需要提供一个防护措施,对于同一笔支付信息如果我其中某一次处理成功了,我虽然又接收到了消息,但是这时我不处理了,即保证接口的 幂等性。 ...
  • 什么是分布式系统

    千次阅读 多人点赞 2020-06-09 17:05:21
    本篇属于《分布式系统学习》系列 教材:《分布式系统:概念与设计》 新手上路,按我的一贯作风,第一遍基本是总结书上的东西,对于小白来说,看书还不如看我的读书笔记。所以本系列适用于跟我一样的小白。 CSDN搜...
  • 分布式系统复习

    千次阅读 2019-12-28 16:29:41
    1 分布式系统模型 1.1 什么是分布式系统分布式系统的目标 定义: 分布式系统是若干独立计算机的集合,这些计算机对于用户来说就像是单个相关系统。 目标: 使资源可访问 透明性 开放性 可扩展性 1.2 为什么要...
  • 分布式系统概述

    2018-06-17 19:08:00
    分布式系统概述 总结自:A Thorough Introduction to Distributed Systems 分布式系统概述 概述 什么是分布式系统 为什么需要分布式系统? 扩展数据库 继续扩展 陷阱 去中心化与分布式 分布式系统类型 分布式...
  • 如何认识分布式系统

    万次阅读 2020-03-04 11:21:27
    首先,我想写的不是介绍任何一个商用或开源的分布式系统,这种文章网上太多的教程了,而且质量很高,我觉得我无法写出更好的,也没有这个必要。如果起名叫分布式系统概述之类,感觉题目就太大了,我现在还没有这样的...
  • 分布式系统浅谈

    千次阅读 2020-06-08 14:17:48
    分布式系统基础知识 一个tomcat打天下的时代,不能说完全淘汰了,在一个管理系统,小型项目中还经常使用,这并不过分,出于成本的考虑,这反而值得提倡。但如果要延伸到高并发场景下就必然要了解分布式系统: ...
  • 【分布式】分布式系统概述

    千次阅读 2018-07-03 23:01:05
    关键词:分布式系统、TCP/IP、NIO模型 一、基本概念 分布式系统:多个节点(一般来说一个节点即一台计算机),且节点间互相连通(网络&消息传递) -> 在这些连通的节点上部署了组件并且组件之间的操作互相...

空空如也

1 2 3 4 5 ... 20
收藏数 169,215
精华内容 67,686
关键字:

分布式系统