从零开始设计键值数据库（KEY-VALUE STORE）

本文主要参考 System Design Interview: An Insider’s Guide（CHAPTER 6）

键值存储（key-value store），也被称为键值数据库（key-value database），是一个非关系型数据库。每一个独特的标识符都被存储为一个带有相关值的键。这种数据配对被称为 "键-值 "对。 在一个键值对中，键必须是唯一的，与键相关的值可以通过键来访问。键可以是纯文本或散列值。出于性能方面的考虑，短键的效果更好。键是什么样子的？这里有几个例子：

• Plain text key: “last_logged_in_at”

• Hashed key: 253DDEC4

键值对中的值可以是字符串、列表、对象等。在键值存储中，值通常被视为不透明的对象，如Amazon dynamo , Memcached , Redis , 等等。

下面是一个键值存储的数据片段：

你需要设计一个支持以下操作的键值存储。

• put(key, value) // insert “value” associated with “key”

• get(key) // get “value” associated with “key”

了解问题并确定设计范围

没有完美的设计。每种设计都会在读、写和内存使用的权衡方面达到特定的平衡。另一个必须做出的权衡是在一致性和可用性之间。我们希望设计了一个包括以下特点的键值存储：

• 一个键值对的大小很小：小于10KB。

• 有能力存储大数据。

• 高可用性。系统响应迅速，即使在故障期间也是如此。

• 高可扩展性。系统可以被扩展以支持大型数据集。

• 自动扩展。服务器的增加/删除应该是基于流量的自动。

• 可调整的一致性。

• 低延迟。

单服务器kv存储

开发一个部署在单个服务器中的键值存储很容易。一个直观的方法是将键值对存储在一个哈希表中，这样可以将所有东西都保存在内存中。尽管内存访问速度很快，但由于空间的限制，把所有东西都放在内存中可能是不可能的。有两种优化方法可以用来在单个服务器中容纳更多的数据：

• 数据压缩

• 只在内存中存储经常使用的数据，其余的存储在磁盘上

即使有这些优化，单个服务器也会很快达到其容量。需要一个分布式键值存储来支持海量数据。

分布式kv存储

分布式键值存储也被称为分布式哈希表，它将键值对分布在许多服务器上。在设计分布式系统时，理解CAP（Consistency一致性、Availability可用性、Partition Tolerance分区容忍度）理论很重要。

CAP 理论

CAP理论指出，一个分布式系统不可能同时提供这三种保证中的两种以上：一致性、可用性和分区容忍度。让我们建立几个定义。

一致性：一致性意味着所有客户在同一时间看到相同的数据，无论他们连接到哪个节点。

可用性：可用性意味着任何请求数据的客户端都能得到响应，即使有些节点发生了故障。

分区容忍度：分区表示两个节点之间的通信中断。 分区容忍度意味着尽管网络分区，系统仍能继续运行。

CAP理论指出，必须牺牲三个属性中的一个来支持三个属性中的两个，如图6-1所示。

现在，键值存储是根据它们支持的两个CAP特性来分类的。

CP（一致性和分区容忍）系统：CP键值存储支持一致性和分区容忍，同时牺牲了可用性。

AP（可用性和分区容忍度）系统：一个AP键值存储支持可用性和分区容忍度，同时牺牲了一致性。

CA（一致性和可用性）系统：CA键值存储支持一致性和可用性，同时牺牲了分区容忍度。由于网络故障是不可避免的，一个分布式系统必须容忍网络分区。因此，CA系统不能存在于现实世界的应用中。

你在上面读到的主要是定义部分。为了使它更容易理解，让我们看一下一些具体的例子。在分布式系统中，数据通常被多次复制。假设数据被复制在三个复制节点上，如图6-2所示，n1、n2和n3。

理想情况

在理想的世界里，网络分区永远不会发生。写入n1的数据会自动复制到n2和n3。这就实现了一致性和可用性。