分布式系统的十二个目标

来源:互联网 发布:c 串口通信编程 编辑:程序博客网 时间:2024/04/19 11:21

分布式系统的十二个目标作为分布式系统的基础,虽然这些目标并不是在所有情形下都是关联在一起的,对于我们认识和学习分布式系统有着不可或缺的作用,下面我们介绍一下分布式系统的十二个目标。

    1. 本地自治

    一个分布式系统中的场地应该是自治的。本地自治是指在一个给定场地上的所有操作由这个场地自己控制,场地X上的成功操作不应该依赖于某个其他的场地Y(相反的情况是场地Y停机了也许意味着场地X也不能运转了,即使场地X自己没有任何问题—这显然是一种不希望发生的情况)。本地自治还意味着本地数据是由本地拥有和管理的,并具有本地的可计算性:所有的数据都是“真正”属于某个本地数据库的,即使它们可以被其他的、远程的场地访问。本地数据的安全性、完整性和存储形式之类的问题也是在本地场地的控制和管辖之下的。
    实际上,本地自治的目标是无法完全达到的—在不少情况下,一个给定的场地X必须交出一定程度的控制权给某个场地Y。因此自治目标也许应该这样表述更为:场地应该在尽可能大的程度上是自治的。

    2. 不依赖于中心场地

    本地自治意味着所有的场地都必须得到同等的对待。因此,尤其是不应该为了某些集中服务—比如,集中查询处理、集中事务管理或者是集中命名服务—而依赖于一个中心“主”场地,以至于整个系统会依赖于一个中心场地。这样第二个目标其实是个目标的一个推论(如果个满足了,第二个毫无疑问会得到满足)。但是“不依赖于中心场地”本身是非常重要的,即使是完全的本地自治无法达到。因此,把它做为一个单独的目标提出来是很有必要的。
    而之所以不接受对中心场地的依赖至少是基于以下两个原因:首先,中心场地可能会成为一个瓶颈;其次,也是更重要的,系统将会是脆弱的—如果中心场地停止运转了,整个系统也将停止下来(即单点故障( single point of failure))。

    3. 可连续操作性
    通常分布式系统的一个好处是它们可以提供更大的可靠性和更高的可用性:
    • 可靠性(即系统可以在任何时刻启动并运行的可能性)是得到证明了的,因为分布式系统不是一个要么做要么不做的系统—在某些单独的部分,比如说单独的场地,出现故障的时候,它们仍然可以连续地进行操作(当然是在一个被降低的水平上)。
    • 可用性(即系统在某个特定的时期内能够启动并始终运行的可能性)也是得到证明了的,一方面是由于上面的理由,另一方面是由于分布式系统具有数据复制的可能性。
    上述讨论适用于在系统某处发生了意外停机(即出现了某种故障)的情况。意外停机显然是令人讨厌的,但却是难以阻止的。相应地, 计划停机应该是永远不需要的,也是说,应该永远也没有必要停止系统的运行来执行某个任务,比如说是类似增加一个新的场地、或是在一个现存的场地上把D B M S升级到新版本之类的任务。

    4. 位置独立性

    位置独立性(也叫做位置透明性)的基本概念是很简单的:用户不需要知道数据在物理上存储在哪里,但是应该仍然可以进行操作—至少是从逻辑的角度看—好像数据是存储在用户自己本地的场地上一样。之所以要达到位置独立性是由于它简化了用户程序和终端操作。尤其是它允许数据在场地之间迁移,而不会造成程序和操作的失效。需要这种可迁移性是为了使数据可以在网络上移动以适应改变性能的要求。
    注意:你无疑会意识到这一点,即位置独立性只是通常的(物理上的)数据独立性概念在分布情况下的扩展。实际上—稍微提前说一下—我们将看到,每个列出的目标,只要其中含有“独立性”的字眼,都可以看作是数据独立性的一种扩展。

    5. 分片独立性
    如果为了物理存储的需要,可以把给定的关系分割成小块和片断,则说这个系统是支持数据分片的。使用分片是出于性能上的考虑:数据可以在最经常被用到的地方存储,这样大部分的操作会是本地的,而网络开销也会降低。

    6. 复制独立性
    一个系统是支持数据复制的,如果一个存储的关系—或更一般地,一个存储关系的某个分片—可以由存储在许多不同场地上的不同的副本/拷贝或复本( r e p l i c a)来表示。

    7. 分布式查询处理
    在这个标题下有两个要点。
    • 首先,来看看查询“给出供应红色零件的伦敦供应商”。假设用户是在纽约的场地而数据是在伦敦的场地,再假设满足请求的供应商有n个。如果系统是关系的,则查询将主要涉及两条消息—一条是将查询请求从纽约发往伦敦,另一条是将n个元组的结果集合从伦敦发回到纽约。另一方面,如果系统不是关系的,而是一次一纪录的系统,则查询将涉及2n条消息—n条从纽约到伦敦要求“下一个”供应商, n条从伦敦到纽约返回“下一个”供应商。这个例子说明,一个关系系统的性能可能比一个非关系系统要高出若干个数量级。
    • 其次, 优化在一个分布式系统中比在一个集中式系统中更重要。基本的观点是,在一个像上面一样涉及多个场地的查询中,会有很多种在系统中移动数据的方法可以满足查询请求,而找到一个高效的策略是至关重要的。

    8. 分布式事务管理
    事务管理有两个主要的方面,恢复控制和并发控制。两者在分布式环境中都需要扩展处理方式。为了解释扩展处理方式,我们需要引入一个新的术语—代理。在一个分布式系统中,一个单独的事务可以涉及多个场地上的代码执行,尤其是它可以对多个场地进行修改。因此每个事务都可以看作是由许多代理组成,这里代理是指在一个场地上代一个事务执行的进程。而系统需要知道哪两个代理是属于同一个事务的—比如,很显然两个属于同一个事务的代理之间不能发生死锁。

    9. 硬件独立性
    对于这个问题确实没有什么太多好说的—标题已经说明了一切。现实世界中安装地的计算机包括了种类繁多的机型—I B M的机器、I C L的机器、H P的机器以及各种各样的P C和工作站,等等—从而确实需要能够把所有这些系统中的数据集成起来,并给用户提供一个“单一系统映像”。因此非常需要能够在不同的硬件平台上运行同样的D B M S,进一步地讲,要能够让这些不同的机器做为对等的合作者参与到分布式系统中来。

    10. 操作系统独立性

    这个目标可以部分地看作是上一个目标的推论,它同样也确实没有过多讨论的必要。很显然,同样的D B M S应该不仅仅能够运行在不同的硬件平台上,而且也同样可以运行在不同的操作系统平台上—包括在同样硬件平台上的不同操作系统—从而这些(比如说) M V S版本的、U N I X版本的、N T版本的操作系统可以参与到同一个分布式系统中。

    11. 网络独立性
    这个目标也没有什么好说的。如果系统能够支持许多完全不同的场地,这些场地是基于完全不同的硬件、运行完全不同的操作系统的,这显然需要系统也能够支持各种完全不同的通信网络。

    12. DBMS独立性
    对于这个目标,我们需要考虑放松对同构假设的限制会有什么样的结果。可以证明这个假设有一些过强了:实际上只要在不同场地上的D B M S实体都支持相同的界面足够了—它们并不需要是同一个D B M S软件的拷贝。比如,如果I n g r e s和O r a c l e都支持官方的S Q L标准,则让一个I n g r e s场地和一个O r a c l e场地在一个分布式系统的环境中交互是很可能的。换句话说,分布式系统可以是异构的,至少在某种程度上是这样的。

    支持异构性无疑是非常必要的。事实上,现实世界中的绝大部分计算机设备不仅仅是运行着许多不同的机器和许多不同的操作系统,也同样经常运行着不同的D B M S:而如果这些不同的D B M S都能够在某种程度上参与到同一个分布式系统中,这将是一件非常好的事情。换句话说,理想的分布式系统应该提供D B M S独立性。


转载地址:点击打开链接

原创粉丝点击