「分布式架构」“一切都是分布式”说最终一致性


「分布式架构」“一切都是分布式”说最终一致性

文章插图
 
大约一年前 , 我在一致性模型上写了这篇文章的第一个版本 , 但我从来没有对它感到满意 , 因为它写得很匆忙 , 而且这个主题足够重要 , 需要得到更彻底的处理 。ACM Queue要求我修改它以便在他们的杂志中使用 , 我利用这个机会改进了这篇文章 。这是那个新版本 。
最终的一致性——在全球范围内构建可靠的分布式系统需要在一致性和可用性之间进行权衡 。
亚马逊云计算的基础是基础设施服务 , 如Amazon的S3(简单存储服务)、SimpleDB和EC2(弹性计算云) , 它们为构建互联网规模的计算平台和各种应用程序提供了资源 。对这些基础设施服务的要求非常严格;他们需要在安全性、可伸缩性、可用性、性能和成本效益方面取得高分 , 并且他们需要在满足这些需求的同时 , 持续地为全球各地的数百万客户服务 。
在这些服务的背后是在全球范围内运行的大规模分布式系统 。这种规模带来了额外的挑战 , 因为当系统处理数万亿、数万亿的请求时 , 通常发生概率很低的事件现在保证会发生 , 需要在系统的设计和体系结构中预先考虑 。考虑到这些系统的全球范围 , 我们广泛地使用复制技术来保证一致的性能和高可用性 。尽管复制使我们更接近我们的目标 , 但它不能以完全透明的方式实现它们;在许多情况下 , 这些服务的客户将面临在服务内部使用复制技术的后果 。
其表现方式之一是所提供的数据一致性类型 , 特别是当底层分布式系统为数据复制提供最终一致性模型时 。在Amazon设计这些大规模系统时 , 我们使用一组与大规模数据复制相关的指导原则和抽象 , 并关注高可用性和数据一致性之间的权衡 。在本文中 , 我将介绍一些相关的背景知识 , 这些背景知识为我们提供了交付需要在全球范围内运行的可靠分布式系统的方法 。这篇文章的早期版本出现在2007年12月的All Things Distributed weblog上 , 并在读者的帮助下得到了极大的改进 。
历史的角度在理想的世界中 , 只有一个一致性模型:当进行更新时 , 所有观察者都将看到该更新 。第一次出现这种难以实现的情况是在70年代末的数据库系统中 。关于这个主题最好的“时期文章”是Bruce Lindsay等人写的“分布式数据库的注释”5 。它列出了数据库复制的基本原则 , 并讨论了实现一致性的许多技术 。这些技术中的许多都试图实现分布透明性—也就是说 , 对于系统的用户来说 , 看起来好像只有一个系统 , 而不是有许多协作系统 。这一时期的许多系统采取的方法是 , 与其破坏这种透明度 , 不如让整个系统失灵
在90年代中期 , 随着大型互联网系统的兴起 , 这些做法被重新审视 。那时 , 人们开始考虑可用性可能是这些系统最重要的属性 , 但他们也在为它应该与什么进行交换而挣扎 。系统教授Eric Brewer的加州大学伯克利分校,当时Inktomi,带来了不同的交换在主题演讲PODC 2000.1(分布式计算的原则)会议上他提出上限定理,即三个属性的数据共享系统数据一致性、系统可用性和公差网络partition-only两个可以实现在任何给定的时间 。Seth Gilbert和Nancy lynch在2002年的一篇论文中给出了更正式的确认
不能容忍网络分区的系统可以实现数据一致性和可用性 , 通常是通过使用事务协议实现的 。要做到这一点 , 客户端和存储系统必须是同一个环境的一部分;在某些场景下 , 它们作为一个整体失败 , 因此 , 客户端无法观察分区 。一个重要的观察结果是 , 在较大的分布式系统中 , 网络分区是给定的;因此 , 一致性和可用性不能同时实现 。这意味着对于放弃什么有两种选择:放松一致性将允许系统在可分区条件下保持高可用性 , 而将一致性作为优先级意味着在某些条件下系统将不可用 。
这两个选项都要求客户端开发人员知道系统提供了什么 。如果系统强调一致性 , 开发人员就必须处理这样一个事实 , 即系统可能无法进行写入操作 。如果由于系统不可用而导致写入失败 , 那么开发人员将不得不处理如何处理要写入的数据 。如果系统强调可用性 , 它可能总是接受写操作 , 但在某些条件下 , 读操作不会反映最近完成的写操作的结果 。然后开发人员必须决定客户端是否一直需要访问绝对最新的更新 。有一系列应用程序可以处理稍微陈旧的数据 , 它们在此模型下得到了很好的服务 。


推荐阅读