亚马逊dynamo高可用性关键字仓库

2.3 设计思路

    数据复制算法在传统商业系统中是做同步协同复制，来提供良好的一致性数据接口。为了实现这个等级的一致性，这些算法必须权衡数据在一些出错情况下的可用性。比方说，与其处理正确性不确定的数据，不如在肯定其正确性之前让它不可用。从早期的复制数据库工作中，我们知道当网络可能出现错误的情况下，良好的一致性和高度数据可用性不能同时达到。所以，系统和应用应该知道在具体情况下，什么属性是能别实现的。

    对于服务和网络易于出错的系统，可以是用乐观的复制技术来实现可用性，在后台复制品允许更改，并发和不连接任务是可以容忍的。这个方法的问题是，这样会导致有冲突的改变，这些改变必须要检查出来并处理掉。冲突处理过程引入两个问题：什么时候解决、谁来解决。dynamo是一个完全一致的数据仓库，所有的更新最终会到达所有的复制品。

    一个设计需要考虑到问题是决定什么时候来完成解决更新冲突的过程，在读和写的过程中冲突要不要解决。许多传统的数据仓库在写操作的时候解决冲突，保持读操作简单化。在某些系统中，如果数据仓库不能联系所有的复制品，写操作是别拒绝的。换句话说，dynamo想要设计一个永远可写的数据仓库。对于很多亚马逊的服务，拒绝消费者的更新操作会造成不好的用户体验。比如，购物车必须允许用户增加和删除其中的条目，即使在网络和服务出错的情况下。这个需求迫使我们把冲突解决过程放到读操作中，来保证写操作不被拒绝。

    下个问题是选择谁来处理冲突。这可以被数据仓库或者应用。如果冲突被数据仓库解决，他的选择会很局限。这个情况下，数据仓库只能用一些简单的方法，比如“最后的写操作胜利”，来解决更新的冲突。另一方面，因为应用知道数据模型，他的解决方法更适合他的用户体验。比如，维护购物车的应用可以合并冲突的版本，返回一个统一的购物车。尽管这是灵活的，一些开发者会不愿意写自己的冲突解决机制，让冲突到数据仓库，最后使用像“最后写胜利”的简单策略。

    其它关键原则：

    增加的可扩展性：dynamo应该能够一次扩展一个存储节点，最小程度的影响系统的操作员和系统本身。

    匀称：dynamo中的每一个节点应该和他的peers有相同的责任；没有特别的节点或者扮演特殊角色的节点或拥有更多的责任。经验证实，匀称性简化了系统的运营过程。

    分散化：匀称性的扩展，设计应该赞成节点间的分散化，反对集中控制。在过去集中控制造成了很多负载，我们的目标是尽可能的阻止它。这使系统具有更好的可用性和可扩展性。

    异构：系统需要能够在基础设施上异构地开发。服务器上的工作必需和它的能力成比例。这是很重要的，给系统添加更高容量的新节点时不用更新所有的节点。

3.相关工作

3.1点对点系统

    一些p2p系统已经看到数据存储和分布的问题。第一代的P2P系统Freenet和Gnutella被作为文件共享系统主导使用。有一些非结构化的P2P网络，节点之间的过载连接被草率建立。在这些网络中，一个搜索语句通常在整个网络上寻找尽量多的拥有该数据的节点。P2P改革进入下一代，被叫做结构化P2P网络。这些网络使用一个全局一致性协议来确保任何节点都能够有效的查找到拥有期望数据的节点。Pastry 和Chord使用路由机制来保证查询能在一定跳数之内得到答案。为了减少多跳路由造成的延迟，一些P2P系统使用O（1）路由，每个节点位置足够多的路由信息在本地，这样可以在一定跳数之内找到适当的节点。

    有一些存储系统，比如Oceanstore和PAST，都是建立在这些路由负载之上的，Oceanstore提供一种全局的、相互作用的、连续的存储服务，支持多复制品数据的连续更新。在避免广域锁带来的问题的同时允许并发更新，它使用一种基于冲突解决方案的更新模型。冲突解决方案用来减少事物中断。Oceanstore通过处理一系列的更新操作来解决冲突，给他们做一个排序，再根据排序原子地实施他们。这个方法用在数据被复制在一个不可信的设施上的情况下。相比而下，PAST在Pastry之上提出来一个抽象层，用来保存固定和不可变的对象。它假设应用能够在它上面构建存储语义。

3.2分布式文件系统和数据库

    分布式数据的性能、可用性和持久性已经在文件系统和数据库系统社区被广泛研究。P2P存储系统知识提供单调的命名空间，和它相比，分布式文件系统通常支持层次结构的命名空间。像Ficus和Coda系统，复制文件为了高可用性损害了一致性。更新冲突通常用单独的冲突解决程序来管理。Farsite系统是一个分布式文件系统，它不使用集中化的服务。Farsite使用复制来达到高的可用性和可扩展性。Google文件系统是另一个分布式文件系统，它用来维持Google的网络应用状态。GFS使用一个单独的master服务器来保存所有的元数据还有这些数据在那里分割，存储在那个chunkserver上。Bayou是一个分布式文件系统，允许不连接操作，提供完全的数据一致性。

    这些系统中，Bayou，coda和Ficus允许无连接操作，在网络分区和负载方面适应性强。这些系统的冲突解决方案不同，比如，Code和Ficus是系统级冲突解决方案，Bayou是应用级的解决方案。但是，他们都坚持最终的一致性。和这些系统类似，Dynamo即使在网络断开和解决冲突的过程中也允许读写操作。像FAB的分布式块存储系统能够将大块分割成小块，用高可用的方式存储这些数据块。和这些系统相比，Key-value存储更合适是因为：a.它用来存储相对小的对象（小于1M）b.key-value基于每个应用更容易配置。Antiquity是一个用来处理多服务器错误的分布式存储系统。它使用一个安全日志来保持数据完整，在多节点复制每个日志来保证持久性，并且使用Byzantine容错协议来保证数据一致性。和Antiquity不同，Dynamo不关注数据完整和安全问题，它用在一个可信的环境下。Bigtable是一个管理结构化数据的分布式存储系统，它维持一个稀松的多维分类的映射，允许应用使用多属性访问数据。和Bigtable相比，Dynamo的目的是，应用只需要key/value访问，更新操作不会被拒绝，即使在网络中断或服务器出错。

    传统的复制关系数据库系统关注如何保证数据副本的一致性，尽管良好的数据一致性使应用开发者便于编程，但是这些系统在扩展性和可用性上有局限性。这些系统不能处理网络断开问题，因为他们通常提供强的一致性保证。

3.3讨论

    Dynamo就目标需求而言和上面的分布式存储系统不同，首先，Dynamo针对那些需要“永远可写”的数据仓库应用，不会因为出错或者并发写操作而拒绝更新操作。第二，前面说过，Dynamo用在一个单独管理领域，所有的节点都是可信的。第三，使用Dynamo的应用不需要支持层次命名空间，或者复杂的关系模型。第四，Dynamo针对那些延迟敏感性应用，这些应用需要至少99.9%的读写操作在几百毫秒的时间内完成。为了满足这个严厉的延迟需求，我们需要阻止多节点间的路由请求。这是应为多跳路由会增加响应时间，从而增加延迟。Dynamo具有0跳动态哈希表的特点，每一个节点保持足够的路由信息在本地来直接请求特定节点。

4.系统架构

  存储系统架构需要管理的东西是很复杂的。除了数据保存构建，还要有扩展、负载均衡的鲁棒解决方法、从属关系、错误探测、状态转移、并发和作业调度、请求整理、请求路由、系统监控和警告还有配置管理。描述每一个解决方案是不现实的，这篇文章关注Dynamo中的关键分布式系统技术：分割、复制、版本、从属关系、错误处理和扩展。

4.1系统接口

    Dynamo通过一个简单接口把存储的对象和Key相关联；它使用两个操作：get（）和put（）。get（key）操作指出和key关联的Object副本在存储系统中的位置，返回一个单独的object或者是存在冲突的一系列objects和context。put（key，context，object）操作根据关联的key决定object的副本放在哪里，将副本写到磁盘。context是对对象系统元数据的编码，对调用者是不透明的，包括对象的版本信息。context和对象存在一起，系统可以据此证实put请求中object的有效性。

    Dynamo对待调用者提供的key和object时使用一个不透明的字节数组，对key使用MD5哈希算法产生一个128位的识别符，用来决定服务key的存储节点。

4.2分割算法

    Dynamo的一个重要的设计需求是它必须规模可增加。这需要一个在节点集合上分割数据的机制。Dynamo的分割方案依赖于一致性哈希把负载分配到多个节点。在一致性哈希中，哈希函数的输出空间被看作一个圆环，系统中的每个节点分配空间中的一个随机值来代表它在圆环中的位置。每个数据项的身份识别符key通过哈希运算分配到圆环上的一个节点位置，然后顺时针走过圆环，找到的第一个节点位置。

    这样，每个节点负责圆环上它和它的前任节点之间的区域。一致性哈希的好处是减少或增加一个节点只影响它的当前临界点，其它节点不受影响。

    基本的一致性哈希算法带来了一些问题。首先，每个节点随机分配位置引起不均匀数据和负载分布。第二，基础算法忽视了各节点性能的不同。为了解决这些问题，Dynamo使用了一个变异的一致性hash算法：更改每个几点在圆环上映射一个点，每个节点在圆环上赋予多个点。为此，Dynamo使用了虚拟节点的概念。一个虚拟节点可以看成是系统中的一个节点，但是每个节点可以负责多个虚拟节点。当一个新节点加入系统，圆环上分配给多个位置。Dynamo分割方案的微调过程在第六部分讨论。

    使用虚拟节点有以下好处：

    如果一个节点失效，这个节点的负载会均匀分散到可用节点上。

    节点再次可用或者增加一个新节点，新的可用节点从可用节点上接收大概等量的负载。

    一个节点负责的虚拟节点数量可以根据他的容量决定，计量物理设施的差异。

4.3复制

    为了达到高可用性和持久性，dynamo把他的数据复制到多个节点上，每个数据项被复制到N个节点，N是个配置参数“per-instance”。每个key，k，被分配到一个协同节点。协同者负责落到它的范围内的数据项副本。除了在他的范围内存储每个key，协同者还复制这些key在N-1个顺时针后续节点上。这可以使系统每一个节点负责它和它的第N个前任节点。在图2中，B节点除了把k存储在本地，还复制到C和D上。D节点存储落在区间（A，B],(B,C],(C,D].

    

    

    负责存储一个特定key的节点列表被称作优先列表。在4.8中会解释系统设计使得每个系统节点能够决定对于key哪些节点应该在优先列表中。为了解释节点错误，优先列表包含多余N个节点。注意，使用虚拟节点可能造成一个key的N个后续位置属于少于N个物理节点。为此，key的优先列表通过跳过圆环中的虚拟节点来确保列表包含的都是不同 的物理节点。