如何深入浅出全面学习分布式系统？

目录

前言

1 、什么是分布式系统

2、 为什么分发系统&＃xff1f;

3、 缩放我们的数据库

二、分布式系统类别

1、 分布式数据存储

2、分布式计算

3、分布式文件系统

4、分布式消息

5、分布式应用

6、分布式分类帐

概要

前言

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

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

1 、什么是分布式系统

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

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

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

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

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

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

2、 为什么分发系统&＃xff1f;

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

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

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

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

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

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

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

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

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

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

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

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

3、 缩放我们的数据库

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

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

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

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

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

恭喜&＃xff0c;您现在可以执行3倍的读取查询&＃xff01;这不是很好吗&＃xff1f;

陷阱

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

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

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

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

继续扩展

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

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

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

让我们继续使用另一种称为的技术分片 &＃xff08;sharding&＃xff09;&＃xff08;也称为分区&＃xff09;。

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

对此的一种可能的方法是根据关于记录的某些信息来定义范围&＃xff08;例如&＃xff0c;具有名称AD的用户&＃xff09;。

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

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

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

陷阱

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

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

分散与分布&＃xff08;Decentralized vs Distributed&＃xff09;

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

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

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

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

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

二、分布式系统类别

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

1、 分布式数据存储

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

没有首先引入CAP定理&＃xff0c;我们就不能讨论分布式数据存储。

CAP定理

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

从3选择2&＃xff08;但不是一致性和可用性&＃xff09;

一些快速定义&＃xff1a;

• 一致性  - 您按顺序读取和写入的内容是预期的&＃xff08;请记住几个段落前的数据库复制陷阱&＃xff1f;&＃xff09;

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

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

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

我们做什么&＃xff1f;

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

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

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

这些系统提供BASE属性&＃xff08;与传统数据库的ACID相反&＃xff09;

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

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

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

这种可用的分布式数据库的例子 - Cassandra&＃xff0c;Riak&＃xff0c;Voldemort

当然&＃xff0c;还有其他更喜欢更强一致性的数据存储 --HBase&＃xff0c;Couchbase&＃xff0c;Redis&＃xff0c; Zookeeper

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

Cassandra

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

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

写样本

阅读时&＃xff0c;只能从这些节点读取。

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

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

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

共识

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

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

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

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

2、分布式计算

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

MapReduce

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

我们再来看一个例子&＃xff1a;

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

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

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

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

更好的技术

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

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

因此&＃xff0c;出现了解决这些问题的其他体系结构。即Lambda体系结构&＃xff08;混合批量处理和流处理&＃xff09;和Kappa体系结构&＃xff08;仅流处理&＃xff09;。这些领域的进步带来了新的工具 - Kafka Streams&＃xff0c; Apache Spark&＃xff0c;Apache Storm&＃xff0c;Apache Samza。

3、分布式文件系统

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

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

HDFS

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

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

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

IPFS

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

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

它仍然在经历重大的发展&＃xff08;写作时的v0.4&＃xff09;&＃xff0c;但已经看到有兴趣构建它的项目&＃xff08;FileCoin&＃xff09;。

4、分布式消息

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

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

一个示例网络

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

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

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

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

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

6、分布式分类帐

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

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

他们利用时间采购模式&＃xff0c;允许您在历史的任何时间重建账目状态。

Blockchain

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

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

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

简化区块链

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

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

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

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

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

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

比特币

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

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

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

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

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

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

复仇

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

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

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

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

分布式账本的进一步用法

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

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

分散式身份验证 - 将您的身份存储在区块链中&＃xff0c;使您能够在任何地方使用单点登录&＃xff08;SSO&＃xff09;。Sovrin&＃xff0c;思域

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

概要

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

• 分布式系统很复杂

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

• 他们很难与之合作

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

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

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

警告

让我给你留个别预告&＃xff1a;

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

这篇文章到这里就结束了

喜欢小编的分享可以点赞关注哦&＃xff0c;小编持续为你分享最新文章