[分布式系统]全面介绍分布式系统
[声明：本篇文章翻译转载自Stanislav Kozlovski] ：A Thorough Introduction to Distributed Systems。
很感谢原作者这么通俗易懂介绍分布式系统。考虑在国内访问不到该作者的文章，以及自己学习的便利性，想在这里和大家分享一下 Stanislav Kozlovski 作者的文章。
什么是分布式系统？为什么这么复杂？
全文目录
介绍
分布式系统类别
一、介绍
随着世界不断增长的技术扩张，分布式系统变得越来越普遍。他们是计算机科学领域的一个庞大而复杂的领域。
本文旨在以基本方式向您介绍分布式系统，向您展示此类系统的不同类别，同时不深入细节。
1 、什么是分布式系统
最简单定义的分布式系统是一组计算机一起工作，以最终用户身份显示为一台计算机。
这些机器具有共享状态，并发操作并可独立故障，而不会影响整个系统的正常运行时间。
我建议我们通过分配系统的例子逐步完成工作，以便更好地理解这一切：
让我们来看一个数据库吧！传统的数据库存储在一台机器的文件系统上，无论何时你想要在其中读取/插入信息 - 直接与该机器通信。
为了分发这个数据库系统，我们需要让这个数据库同时在多台机器上运行。用户必须能够与他选择的任何一台机器通信，并且不应该能够告诉他他没有与一台机器通话 - 如果他将一条记录插入节点＃1，则节点＃3必须能够返回该记录。
可以被视为分布式的体系结构
2、 为什么分发系统？
系统总是按需分配。事情的真相是 - 管理分布式系统是一个复杂的主题，充满了陷阱和地雷。部署，维护和调试分布式系统令人头疼，为什么要去那里呢？
分布式系统使您能够做的是横向扩展。回到我们前面的单个数据库服务器的例子，处理更多流量的唯一方法是升级运行数据库的硬件。这称为垂直缩放。
尽管可以垂直缩放，但是在某个点之后，您会发现即使是最好的硬件也不足以提供足够的流量，更不用说主机不切实际了。
缩放横向意味着添加更多的计算机，而不是升级单个硬件。
水平缩放在一定的阈值之后变得更便宜
在一定的阈值之后，它比垂直缩放要便宜得多，但这不是偏好的主要情况。
垂直缩放只能将性能提升至最新的硬件功能。这些能力证明对于工作量适中到较大的技术公司是不够的。
关于水平缩放的最好的事情是，您无限制地扩展规模 - 只要性能下降，您只需添加另一台机器，最多可达到无限大。
轻松扩展并不是从分布式系统获得的唯一好处。容错和低延迟也同样重要。
容错 - 跨越两个数据中心的十台机器集群本质上比单台机器更容错。即使一个数据中心着火，您的应用程序仍然可以工作。
低延迟 - 网络数据包出行的时间受到光速的限制。例如，纽约到悉尼之间光纤电缆的请求往返时间（即来回）的最短时间为 160ms。分布式系统允许您在两个城市都拥有一个节点，从而使流量达到最接近它的节点。
但是，要使分布式系统正常工作，需要在这些机器上运行的软件专门设计用于同时在多台计算机上运行，并处理随之而来的问题。事实证明，这并非易事。
3、 缩放我们的数据库
想象一下，我们的Web应用程序非常受欢迎。想象一下，我们的数据库每秒处理的查询次数也开始增加两倍。您的应用程序会立即开始降低性能，这会被用户注意到。
让我们一起工作，并使我们的数据库规模满足我们的高要求。
在典型的Web应用程序中，您通常比插入新信息或修改旧信息更频繁地读取信息。
有一种方法可以提高读取性能，即通过所谓的主从复制策略。在这里，您创建了两个与主要服务器同步的新数据库服务器。问题是你只能从这些新的实例中读取。
无论何时插入或修改信息 - 您都可以与主数据库通信。反过来，它会异步地通知奴隶的变化，并将它们保存起来。
恭喜，您现在可以执行3倍的读取查询！这不是很好吗？
陷阱
疑难杂症！我们立即失去了关系数据库的ACID保证中的C，它代表一致性。
你看，现在有一种可能性，我们在数据库中插入一条新的记录，然后立即发出一个读取查询并获取任何东西，就好像它不存在一样！
将新的信息从主设备传播到从设备不会立即发生。实际上存在一个可以获取陈旧信息的时间窗口。如果情况并非如此，您的写入性能会受到影响，因为它必须同步等待数据传播。
分布式系统带来了一些折衷。如果你想充分扩展，这个特殊的问题是你必须忍受的。
继续扩展
使用从数据库方法，我们可以在一定程度上横向扩展读取流量。这很棒，但我们在写入流量方面遇到了一堵墙 - 它仍然在一台服务器上！
我们在这里没有太多选择。我们只需要将我们的写入流量分割为多个服务器，因为无法处理它。
一种方法是采用多主复制策略。在那里，而不是只能读取的从站，您有多个支持读取和写入的主节点。不幸的是，由于您现在有能力创建冲突（例如插入两个具有相同ID的记录），因此这会变得非常复杂。
让我们继续使用另一种称为分片 （sharding）的技术（也称为分区）。
通过分片，您可以将服务器分成多个较小的服务器，称为碎片。这些碎片都拥有不同的记录 - 您创建了哪种记录进入哪个碎片的规则。创建规则以使数据以统一的方式传播非常重要。
对此的一种可能的方法是根据关于记录的某些信息来定义范围（例如，具有名称AD的用户）。
应该非常仔细地选择这个分片键，因为基于任意列的负载并不总是相等的。（例如，更多人拥有以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年就证明，分布式数据存储不能同时具有一致性，可用性和分区容错性。
从3选择2（但不是一致性和可用性）
一些快速定义：
一致性 - 您按顺序读取和写入的内容是预期的（请记住几个段落前的数据库复制陷阱？）
可用性 - 整个系统不会死亡 - 每个非故障节点总是返回一个响应。
分区容忍 - 尽管存在网络分区，系统仍会继续运行并保持其一致性/可用性保证
实际上，对于任何分布式数据存储，分区容限必须是给定的。正如许多地方所提到的，其中的一篇文章，如果没有分区容差，就无法保证一致性和可用性。
想一想：如果你有两个节点接受信息并且他们的连接中断 - 它们将如何可用并同时为你提供一致性？他们无法知道其他节点正在做什么，因此可能变为脱机（不可用）或使用陈旧的信息（不一致）。
我们做什么？
最后，您可以选择是否希望系统在网络分区下保持强大的一致性或高可用性。
实践表明大多数应用程序更重视可用性。你不一定总是需要很强的一致性。即便如此，这种权衡并不一定是因为您需要100％的可用性保证，而是因为在必须同步机器以实现强大的一致性时，网络延迟可能成为一个问题。这些和更多因素使应用程序通常选择提供高可用性的解决方案。
这些数据库用最弱的一致性模型解决 - 最终的一致性 （强大vs最终一致性解释）。此模型保证，如果没有对给定项目进行新更新，则最终对该项目的所有访问都将返回最新的更新值。
这些系统提供BASE属性（与传统数据库的ACID相反）
乙 asically 甲 vailable -系统总是返回一个响应
小号经常状态-该系统可以随着时间的推移，即使是在没有输入的时间变化（由于最终一致性）
E公开的一致性 - 在没有输入的情况下，数据迟早会传播到每个节点 - 从而变得一致
这种可用的分布式数据库的例子 - Cassandra，Riak，Voldemort
当然，还有其他更喜欢更强一致性的数据存储 --HBase，Couchbase，Redis， Zookeeper
CAP理论值得自己撰写多篇文章 - 其中一些内容涉及如何根据客户端的行为以及其他如何正确理解它来调整系统的CAP属性。
Cassandra
如上所述，Cassandra是一个分布式的No-SQL数据库，它偏好CAP的属性，并最终保持一致性。我必须承认，这可能有点误导，因为Cassandra具有高度可配置性 - 您可以通过牺牲可用性来提供强大的一致性，但这不是它的常见用例。
Cassandra使用一致的哈希来确定哪个节点脱离了您的集群必须管理您传递的数据。您设置了一个复制因子，它基本上指出要复制数据的节点数。
写样本
阅读时，只能从这些节点读取。
Cassandra具有强大的可扩展性，可提供非常高的写入吞吐量。
可能有偏见的图，显示每秒写入基准。从这里采取。
尽管这张图可能有些偏颇，并且它看起来像将Cassandra与数据库集进行比较以提供强大的一致性（否则我无法明白为什么MongoDB在从4个节点升级到8个节点时性能会下降），但它仍应显示正确设置的内容up Cassandra集群是有能力的。
无论如何，在支持横向扩展和难以置信的高吞吐量的分布式系统平衡中，Cassandra不提供ACID数据库的一些基本特性 - 即事务处理。
共识
数据库事务在分布式系统中实现起来很棘手，因为它们要求每个节点都要采取正确的操作（中止或提交）。这被称为共识，这是分布式系统中的一个基本问题。
如果参与过程和网络完全可靠，那么达成“交易提交”问题所需的协议类型就很简单。但是，真正的系统会受到一些可能的故障的影响，如进程崩溃，网络分区以及丢失，失真或重复的消息。
这提出了一个问题 - 已证明不可能保证在不可靠网络上的有限时间框架内达成正确的共识。
但实际上，有些算法很快就会在不可靠的网络上达成共识。Cassandra实际上通过使用用于分布式共识的Paxos算法来提供轻量级事务。
2、分布式计算
分布式计算是近年来我们见到的大数据处理流入的关键。它是将一项庞大的任务（例如总计1000亿条记录）分割成许多较小的任务的技术，其中任何一台计算机都不能单独执行，而每个任务都可以装入一台商品机器中。您将您的庞大任务分解为许多较小的任务，让它们在多台机器上并行执行，合适地汇总数据，并解决了最初的问题。这种方法再次使您能够水平扩展 - 当您有更大的任务时，只需在计算中包含更多节点。
这个领域的早期创新者是谷歌，因为他们需要大量的数据必须为分布式计算创造一种新的范式 - MapReduce。他们在2004年发表了一篇论文，而开源社区后来又基于它创建了Apache Hadoop。
MapReduce
MapReduce可以简单地定义为两个步骤 - 映射数据并将其减少为有意义的数据。
我们再来看一个例子：
假设我们是中型企业，我们将庞大的信息存储在二级分布式数据库中用于仓储目的。我们希望获取表示2017年4月（一年前）每天发布的拍手次数的数据。
这个例子保持尽可能简短，清晰和简单，但想象我们正在处理大量数据（例如分析数十亿次拍子）。我们不会将所有这些信息都存储在一台机器上，我们也不会仅用一台机器来分析所有这些信息。我们也不会查询生产数据库，而是专门为低优先级脱机作业构建的一些“仓库”数据库。
每个Map作业都是一个单独的节点，它可以转换尽可能多的数据。每个作业都会遍历给定存储节点中的所有数据，并将其映射到日期和数字的简单元组。然后，三个中间步骤（没人谈论）完成 - Shuffle，Sort和Partition。他们基本上进一步安排数据并将其删除到适当的减少工作。在我们处理大数据时，我们将每个Reduce作业分隔开来，仅在单个日期上工作。
这是一个很好的范例，令人惊讶的是你可以用它做很多事情 - 例如，你可以链接多个MapReduce作业。
更好的技术
现在MapReduce有些遗留问题，并带来一些问题。因为它在批处理（作业）中起作用，所以如果您的工作失败，则会出现问题 - 您需要重新开始整个工作。2小时的工作失败可能会让你的整个数据处理流程变慢，而且你并不想这么做，特别是在高峰时段。
另一个问题是您等待直到您收到结果的时间。在实时分析系统中（所有这些系统都有大量数据，因此使用分布式计算），重要的是要让您的最新数据尽可能的新鲜，当然不是几个小时前。
因此，出现了解决这些问题的其他体系结构。即Lambda体系结构（混合批量处理和流处理）和Kappa体系结构（仅流处理）。这些领域的进步带来了新的工具 - Kafka Streams， Apache Spark，Apache Storm，Apache Samza。
3、分布式文件系统
分布式文件系统可以被认为是分布式数据存储。它们与概念一样 - 在一组机器中存储和访问大量数据，所有这些数据都显示为一个整体。他们通常与分布式计算并驾齐驱。
Wikipedia定义的区别在于分布式文件系统允许使用与本地文件相同的接口和语义来访问文件，而不是像Cassandra查询语言（CQL）那样的自定义API 。
HDFS
Hadoop分布式文件系统（HDFS）是通过Hadoop框架用于分布式计算的分布式文件系统。它被广泛采用，用于存储和复制大型文件（大小为GB或TB）跨多台机器。
其架构主要由NameNode和DataNode组成。NameNode负责保存关于集群的元数据，比如哪个节点包含哪些文件块。他们通过找出最佳存储和复制文件的位置，跟踪系统的健康状况，充当网络的协调员。DataNodes只是简单地存储文件并执行命令，如复制文件，写入新文件等等。
毫不奇怪，HDFS最适合用于计算，因为它为计算作业提供数据感知。所述作业然后在存储数据的节点上运行。这利用了数据局部性 - 优化了计算并减少了网络上的流量。
IPFS
星际文件系统（IPFS）是一个令人兴奋的新型分布式文件系统对等协议/网络。利用区块链技术，它拥有完全分散的架构，没有单一所有者或故障点。
IPFS提供了一个名为IPNS的命名系统（类似于DNS），可让用户轻松访问信息。它通过历史版本存储文件，类似于Git的做法。这允许访问文件的所有以前的状态。
它仍然在经历重大的发展（写作时的v0.4），但已经看到有兴趣构建它的项目（FileCoin）。
4、分布式消息
消息传递系统为整个系统内的消息/事件的存储和传播提供了一个中心位置。它们允许您将应用程序逻辑从直接与其他系统交谈中分离出来。
简而言之，消息传递平台的工作原理如下：
消息从应用程序广播，可能创建它（称为生产者），进入平台并被潜在的多个对其感兴趣的应用程序（称为消费者）读取。
如果您需要将某个事件保存到几个地方（例如创建用户到数据库，仓库，电子邮件发送服务以及您可以提供的任何其他服务），则消息传递平台是传播该消息的最简单方法。
消费者可以将信息从经纪人（拉模型）中提取出来，或让经纪人直接将信息推送给消费者（推送模式）。
有几个流行的顶级消息平台：
RabbitMQ - 消息代理，允许您通过路由规则和其他易于配置的设置对消息轨迹进行更细粒度的控制。可以称为智能代理，因为它有很多逻辑，并且密切关注通过它的消息。从CAP提供AP和CP的设置。使用推送模式通知消费者。
Kafka - 消息代理（以及所有平台），它有点低级，因为它不能跟踪哪些消息已被读取，并且不允许复杂的路由逻辑。这有助于它实现惊人的性能。在我看来，这是开源社区积极开发和Confluent团队支持的最大前景。卡夫卡可以说是顶尖科技公司使用最广泛的卡夫卡。我写了一篇全面的介绍，我详细介绍了它的所有优点。
Apache ActiveMQ - 最早的一批，从2004年开始。使用JMS API，这意味着它适用于Java EE应用程序。它被改写为ActiveMQ Artemis，与Kafka相媲美，表现出色。
Amazon SQS - 由AWS提供的消息服务。让您可以快速将其与现有应用程序集成，并且无需处理您自己的基础架构，这可能是一个巨大的好处，因为像Kafka这样的系统的安装非常棘手。亚马逊还提供两种类似的服务 - SNS和MQ，后者基本上是ActiveMQ，但由亚马逊管理。
5、分布式应用
如果您在连接到一个数据库的单个负载均衡器后面集合了5个Rails服务器，您能否称为分布式应用程序？从上面回想我的定义：
分布式系统是一组计算机一起工作，以便作为单台计算机显示给最终用户。这些机器具有共享状态，并发操作并可独立故障，而不会影响整个系统的正常运行时间。
如果您将数据库视为共享状态，那么您可以争辩说这可以归类为分布式系统 - 但是您错了，因为您错过了定义的“ 一起工作 ”部分。
只有节点彼此通信以协调其行为时才分配系统。
因此，类似于在对等网络上运行其后端代码的应用程序可以更好地分类为分布式应用程序。无论如何，这都是无用的分类，没有任何用处，但说明我们将事情分组在一起是多么的繁琐。
Erlang虚拟机
Erlang是一种功能强大的语言，对于并发性，分发和容错有很好的语义。Erlang虚拟机本身处理Erlang应用程序的分发。
其模型通过使许多独立的 轻量级进程都可以通过内置的消息传递系统与对方进行对话。这被称为Actor模型 ，Erlang OTP库可以被认为是一个分布式的actor框架（沿着JVM 的Akka线）。
该模型可以帮助它实现极佳的并发性 - 而这些进程遍布在运行系统的可用内核中。由于这与网络设置无法区分（除了丢弃消息的能力），Erlang的虚拟机可以连接到运行在同一个数据中心甚至另一个大陆的其他Erlang虚拟机。这群虚拟机运行一个应用程序，并通过接管来处理机器故障（另一个节点计划运行）。
事实上，该语言的分布式层被添加以提供容错。运行在单台机器上的软件始终有可能导致单台机器死机并使应用程序脱机。在许多节点上运行的软件允许更轻松地处理硬件故障，只要应用程序是根据这一点构建的。
BitTorrent
BitTorrent是通过种子在网络上传输大文件的使用最广泛的协议之一。主要想法是促进网络中不同对端之间的文件传输，而不必通过主服务器。
使用BitTorrent客户端，您可以连接到世界各地的多台计算机以下载文件。当你打开一个.torrent文件时，你连接到一个所谓的追踪器，这是一台充当协调器的机器。它有助于对等发现，向您显示网络中具有所需文件的节点。
一个示例网络
你有两种类型的用户的概念，一个是一个leecher和一个播种机。leecher是正在下载文件的用户，而播种员是上传所述文件的用户。
关于点对点网络的有趣之处在于，作为普通用户，您有能力加入并贡献于网络。
BitTorrent及其前身（Gnutella，Napster）允许您自愿托管文件并上传给需要它们的其他用户。BitTorrent之所以如此受欢迎的原因在于，它是第一个为激励网络提供激励的公司。在用户只能下载文件的情况下，Freeriding是以前文件共享协议的问题。
BitTorrent通过使播种机上传更多给那些提供最佳下载速率的人来解决一定程度的自由。它通过激励您在下载文件的同时上传。不幸的是，在你完成之后，没有什么能够让你在网络中保持活跃。这导致在网络中缺少具有完整文件的播种器，并且由于协议严重依赖于这些用户，像私人跟踪器这样的解决方案已经实现。私人追踪器要求您成为社区成员（通常只有邀请）才能参与分布式网络。
在该领域取得进展之后，发明了无追踪者的种子。这是对BitTorrent协议的升级，它不依赖集中跟踪器来收集元数据并找到对等点，而是使用新算法。其中一个例子是Kademlia（Mainline DHT），一个分布式哈希表（DHT），它允许您通过其他同行找到同行。实际上，每个用户都会执行跟踪器的职责。
6、分布式分类帐
分布式账本可以被认为是一个不可变的，仅追加数据库，它在分布式网络中的所有节点上进行复制，同步和共享。
已知规模 - 以太坊网络在2018年1月4日每天有130万宗高峰。
他们利用事件采购模式，允许您在历史的任何时间重建账目状态。
Blockchain
区块链是目前用于分布式分类账的基础技术，实际上标志着它们的开始。分布式空间的这一最新和最伟大的创新使得创建了第一个真正的分布式支付协议 - 比特币。
区块链是一个分布式分类帐，它载有网络中发生的所有交易的有序列表。事务分组并存储在块中。整个区块链本质上是一个块链接列表（因此名称）。所述块在创建时在计算上是昂贵的，并且通过密码学彼此紧密相关。
简单地说，每个块包含当前块的内容（以Merkle树的形式）加上前一个块的散列的特殊散列（以X的零数量开始）。这个散列需要大量的CPU能力才能生产出来，因为唯一的办法就是通过暴力破解。
简化区块链
矿工是试图计算散列（通过暴力）的节点。矿工们相互竞争，谁可以拿出一个随机的字符串（称为随机数），当与内容结合时产生前述的散列。一旦有人发现了正确的随机数 - 他将其广播到整个网络。所述字符串然后由每个节点自行验证并接受到它们的链中。
这转化为一个系统，修改区块链的代价非常昂贵，而且很容易验证它没有被篡改。
改变块的内容是昂贵的，因为这会产生不同的散列。请记住，每个后续块的散列都依赖于它。如果您要在上面的图片的第一个块中更改交易，您可以更改Merkle Root。这反过来会改变块的散列（很可能没有所需的前导零） - 这会改变块＃2的散列等等。这意味着你需要在刚刚修改的块之后为每个块强制一个新的随机数。
网络总是信任并复制最长的有效链。为了欺骗系统并最终产生更长的链，你需要所有节点使用的总CPU功率的50％以上。
区块链可以被认为是突发共识的分布式机制。没有明确达成共识 - 共识发生时没有选举或固定的时刻。相反，共识是数千个独立节点异步交互的紧急产物，所有节点都遵循协议规则。
这项前所未有的创新最近成为科技领域的热潮，人们预测它将标志着Web 3.0的诞生。这绝对是目前软件工程领域最激动人心的空间，充满了极具挑战性和有趣的问题，正在等待解决。
比特币
以前的分布式支付协议缺乏的是以分散的方式实时防止双重支出问题的方法。研究已经产生了有趣的命题[1]，但比特币是第一个实施具有明显优势的实用解决方案。
双重支出问题指出，一个演员（例如Bob）不能在两个地方花费他的单一资源。如果鲍勃有1美元，他就不应该把它交给爱丽丝和扎克 - 这只是一种资产，它不能被复制。事实证明，在分布式系统中真正实现这种保证是非常困难的。在区块链之前有一些有趣的缓解方法，但它们不能以实用的方式完全解决问题。
双倍支出可以通过比特币轻松解决，因为一次只能添加一个区块。在一个区块内双重支出是不可能的，因此，即使同时创建两个区块 - 只有一个区块会出现在最长的最长链上。
比特币依靠积累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
