透明度：单一系统的错觉（第二部分）

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

分布式系统之所以让人觉得难以驾驭，原因之一（也是众多原因之一）在于它们通常需要同时处理多项任务。分布式系统旨在为最终用户带来无缝体验；然而，为了实现这一目标，我们往往需要考虑诸多因素。

在本系列的第一部分中，我们开始深入探讨分布式系统会给用户带来哪些错觉。简单回顾一下，分布式 透明性使得由多个自给自足、自治节点组成的分布式系统能够伪装成一个单一的镜像系统。分布式系统可以通过多种方式实现透明性，我们已经探讨了其中的三种（即访问透明性、位置透明性和重定位透明性）。

让我们继续调查透明度的各种形式，看看我们还能发现什么！

（更多）透明形式

移民透明度

我们已经了解了一种称为“重定位透明性”的透明性形式，它允许分布式系统将某些资源从节点 A 移动到节点 B，即使某个用户可能正在访问该资源。但是，资源也可能被某个用户访问，然后移动到新的节点，之后该用户再次访问该资源。迁移透明性允许在系统内移动资源，而资源的消费者（用户）却毫不知情。

我们可以将迁移透明度视为迁移透明度的“不太严格”版本；之所以说它“不太严格”，是因为我们假设系统不会在用户使用资源时移动资源，而迁移透明度则不会。

就迁移透明性而言，资源从位置 A 迁移到位置 B 的方式可能意味着多种不同的事情。资源在系统中的物理地址可能会发生变化，所有指向该资源或引用该资源的内容都必须根据其新位置进行相应更改。迁移透明性确保资源在系统内移动到不同位置后，用户仍然可以以相同的方式访问它；这也意味着资源在迁移位置时无需更改其名称。

复制透明度

我们可以想象，访问、迁移和重新定位资源可能会变得相当棘手。如果我们只有一个资源，而且系统的所有用户都可以访问，那么情况就尤其复杂了！

但复制透明性正能帮我们解决这个问题。复制透明性允许资源的多个实例同时存在。有了这种透明性，用户或程序就可以访问资源，而无需知道他们正在操作的是资源的哪个实例，更不用说资源存在多个副本这一事实了！

在设计一个复制透明的分布式系统时，我们通常需要考虑三件事：创建、维护和访问复制的资源。

考虑资源的复制方式（以及后续的访问和使用方式）至关重要。这是因为任何形式的透明度都只是一种假象。

制作资源的多个副本需要一定的思考和谨慎。

例如，创建和访问复制资源。为了掩盖资源存在多个副本的事实，复制透明性必须确保资源的所有副本都具有相同的名称，并且可以通过相同的方式访问。要创建资源的副本，我们需要考虑如何命名和访问该副本。可以想象，如果同一资源的两个副本名称不同，或者它们的检索方式不同，那么最终用户显然会意识到他们正在尝试检索的资源存在多个副本！因此，任何形式的复制透明性都必须确保最终用户始终认为他们正在与一个资源交互。

复制透明性尤其引人注目，因为它能带来许多隐藏的好处。拥有多个资源实例可以提高系统的可靠性。如果我们处理的资源是某种数据（例如文件），那么复制透明性可以确保，即使第一个文件出现问题，我们也能从另一个副本读取同一文件。

同样，如果资源是一个进程，那么这种透明性将使得另一个相同的（复制的）进程可以进入与第一个（不可用的）进程相同的状态，并继续执行它正在执行的任何操作。事实上，复制进程就是一个很好的例子，说明了维护同一资源的不同副本的状态是多么重要！

除了提高可靠性之外，复制透明性还为我们带来了提升性能的额外好处。在同一台服务器上拥有多个数据副本意味着，所有通过同一服务器访问同一资源的用户都能快速访问到可靠的数据，尤其因为他们并非都在尝试访问同一个共享资源。复制真是太棒了！

并发透明性

资源共享显然是分布式系统正常运行的重要组成部分。我们现在知道，复制透明性允许用户通过创建和维护资源的多个版本，在不知不觉中“共享”对资源的访问权限。但是，如果资源正在被用户修改或“写入”（而不仅仅是被用户访问或“读取”），会发生什么情况？或者，如果资源的某些属性发生变化，而两个用户同时共享对该资源的访问权限，又会发生什么情况？

并发透明性（有时也称为事务透明性）允许分布式系统的多个用户竞争对资源的访问，并同时对资源执行操作，而其他用户对此一无所知。

在分布式系统中处理并发操作比在单个非分布式中央系统中处理并发操作要棘手得多。

在一个真正的单一系统中，只有一个资源存在于一个位置，竞态条件（例如两个用户试图修改同一个资源）很可能遵循先到先得的原则（或者在本例中是先“修改”）。真正的并发并不存在。

然而，在分布式系统中，资源可能存在多个副本，不同的终端用户可能同时访问这些共享资源。例如，假设两个用户同时访问同一个共享文件；如果在访问过程中文件内容发生更改，会发生什么情况？再比如，考虑一下ATM网络或电商平台；分布式系统至少需要考虑数据状态的不断变化。更常见的情况是，它需要在写入数据库时​​优雅地锁定数据库，并且能够处理同一共享进程同时发生的两个修改操作。

管理多个用户共享资源的状态，以及在用户访问该资源时处理其变更，绝非易事。事实上，在分布式系统领域，并发控制算法本身就是一个庞大的研究课题！

失败透明度

考虑到分布式系统必须对用户隐藏诸多信息，有一个方面有时是任何人都无法控制的：系统部件故障。即使在单一系统中，故障也只是一种可能性；而在分布式系统中——由于其组件众多且协同工作——故障则是一种必然。

故障透明性使得分布式系统的最终用户能够在不察觉系统某部分发生故障的情况下继续使用系统并访问任何资源。分布式系统中的故障也称为系统缺陷。

系统故障是不可避免的，因此，作为分布式系统的设计者，我们有责任考虑系统可能出现的故障类型，以及我们计划如何从故障中恢复。有时，识别系统的所有故障并非易事，尤其因为故障通常不仅包括软件故障，还包括硬件故障！

通常情况下，确保故障透明性可能意味着在系统确定故障的具体原因并按照程序员的预期进行处理之前，需要向用户提供延迟响应。然而，对最终用户的延迟响应可能会造成困惑；例如，如果服务器发生故障，而用户并不知道系统存在故障，他们可能会误以为整个流程都失败了，而不是意识到流程只是延迟了。在某些情况下，复制透明性可以发挥作用，因为拥有资源的多个副本意味着，如果某个副本最终成为故障根源，我们可以利用另一个副本。

故障透明性比我们想象的更为普遍，我们日常使用的许多分布式系统都考虑到了系统中某些（潜在的）故障。例如，数据库管理系统就采用了某种方法来确保故障透明性。处理故障透明性是分布式系统设计和维护中最困难的方面之一。

我们究竟能做到多透明？

既然我们已经讨论了主要的透明形式，我们就可以开始发现，有些透明形式似乎比其他形式更容易实现。根据系统的大小和规模，甚至可能根本无法实现真正​​的故障透明或真正的并发透明！所有这些我们需要对最终用户“隐藏”的东西，可能会让人感到有些不知所措；在设计分布式系统时，我们究竟该如何应对所有这些“假象”呢？！

实际上，在单个分布式系统中实现完全的分布式透明性并成功确保访问、位置、迁移、复制、并发和故障透明性是不可能的。

的确，作为分布式系统的设计者，我们能做的和能真正考虑到的方面都存在局限性！有时，维持系统的透明假象甚至并非对我们（或用户）最有利。透明度是一个难题，如果我们无法做到完全透明，也不必为此自责（因为实际上，我们根本做不到这一点）。然而，了解如何思考如何以不同的方式向用户展现透明度，以及如何让他们对系统中一些深层、复杂且棘手的部分保持沉默，仍然是有益的。

资源

分布式透明性是分布式系统领域的一个深奥话题，本文仅作了浅尝辄止的探讨。如果您想了解更多更复杂的透明性相关内容，请查看以下资源！

1. 透明胶片，乔恩·克罗克罗夫特教授
2. 分布式系统中的透明性，苏迪尔·曼特纳教授
3. 分布式系统原理，沃尔夫冈·埃默里希教授
4. 分布式系统的目标，卢阮教授
5. 分布透明度, Juhani Toivonen 教授
6. 分布式系统简述，作者：Maarten van Steen 和 Andrew S. Tanenbaum