Amazon Dynamo阅读笔记(二)

2.背景
Amazon电子商务平台由数以千计的服务器组成, 每个服务公开接口,通过网络访问。
这些服务中有一些是无状态的;有一些是有状态的,比如存储服务。
传统的存储系统,将数据状态存在关系型数据库中(RDBMS)。
对于通用的状态存储模式,关系型数据库方案不够理想:
(1)大多数服务只需要主键查询,不需要复杂的查询和管理功能;
(2)关系型数据库硬件成本、运维成本高;
(3)效率低下;
(4)备份、复制(replication)技术有限;
(5)一致性保证以牺牲可用性为代价;
Amazon使用Dynamo,一个高度可用的数据存储方案解决这一系列的问题。

2.1系统假设
查询模型如下:
(1)数据项的读写通过主键唯一标识;
(2)状态存储为二进制对象(存储层不关心存取内容);
(3)没有横跨多个数据项的操作,即无需关系(relational schema);
(4)数据存储为小数据对象,小于1MB;

关于ACID特性(原子性、一致性、隔离性、持久性)的支持:
(1)数据库对ACID的特性的支持建立在低可用性上,Dynamo不全部支持;
(2)Dynamo不支持数据隔离性(Isolation),只允许单一主键更新;
(3)支持弱一致性,即最终一致性;

效率保证:
(1)系统运行在廉价PC级硬件设施上;
(2)时延要求高;
(3)吞吐量要求高;

其他假设:
(1)系统只被Amazon内部使用,无安全机制,包括身份验证、权限控制等都没有。

2.2服务级协议SLA(Service Level Agreements)
为了保证在限定的时间内交付(deliver)功能,平台内任何依赖都有严格的超时要求。
客户端和服务器采用SLA,客户对API的时延有预期要求,举例:每秒500个请求,99.9%的响应时间需要再300ms以内。

2.3设计考虑
商业系统中,数据复制(Data replication)一般使用同步副本协调技术,以提供强一致性的数据访问接口。
为了达到这一水平,这些算法往往牺牲可数据可用性。

对于故障为常态的系统,可以使用乐观复制技术来提高系统的可用性,它能在后台复制与传递副本。
这种方法的挑战在于,有可能导致数据不一致,需要一个检测冲突与解决冲突的方法。
这里又带来两个问题:
(1)什么时候检测冲突;
(2)谁来解决冲突;

Dynamo被设计成最终一致性(eventually consistent)的数据存储,即所有更新操作,最终将到达所有副本。
Dynamo的设计目标之一是“永远可写”(always writable),对于用户来说,拒绝用户的更新操作是一个糟糕的体验。
即使服务器或者网络故障,购物车服务仍然支持客户向他们的购物车中添加和删除商品。
这个目标迫使我们将检测与解决冲突的工作交给“读”,以确保“写”永远不被拒绝。

而冲突的解决方,则可以交给上层应用程序。如果放在存储层解决冲突,它的选择是相当有限的,它只能使用一些简单的策略,
例如“最后一次写成功”(last write wins)。两一方面,客户上层应用程序,知道数据是如何使用的,知道数据的对与错,
能力理解冲突数据的语义,可以选择合适的方法“合并”冲突版本,以返回一个统一的购物车。

其他重要设计原则:
(1)增量扩展性:Dynamo能一次水平扩展一台存储主机(后称为“节点”),而对系统只产生很小的影响;
(2)对称性:Dynamo的每个节点对等,职责相同,没有任何区别;对称性将简化系统的配置与维护;
(3)去中心化:即对称性的延伸,没有任何集中控制技术,避免系统逻辑单点;
(4)异质性:能够运行在异质的基础设施上,例如我们能一次升级一台主机;

评论关闭。