设计键值存储(第二部分)

原文:Design a Key-Value Store (Part II)

译者:飞龙

协议:CC BY-NC-SA 4.0

自豪地采用谷歌翻译

这是设计键值存储系列文章的第二篇文章。 如果你还没有阅读第一篇文章,请查看它。

在我们之前的文章中,我们主要关注的是键值存储的基本概念,特别是单机场景。 当涉及扩展问题时,我们需要通过一些规则将所有数据分配到多台机器,协调机可以将客户机引导到拥有所请求资源的机器。

设计分布式系统时需要考虑很多事情。 在将数据分到多台机器时,平衡流量很重要。 这就是最好确保键是随机分布的原因。

在这篇文章中,我们将继续讨论分布式键值存储系统。 我们将讨论系统可用性,一致性等主题。

系统可用性

要评估分布式系统,一个关键指标是系统可用性。例如,假设我们的一台计算机出于某种原因崩溃(可能是硬件问题或程序错误),这对我们的键值存储系统有什么影响?

显然,如果有人从这台机器请求资源,我们将无法返回正确的响应。建立业余项目时你可能不会考虑这个问题。但是,如果你使用大量服务器服务数百万用户,则会经常发生这种情况,你无法每次都手动重新启动服务器。这就是为什么可用性在当今每个分布式系统中都是必不可少的。那么你将如何解决这个问题呢?

当然你可以用测试用例编写更健壮的代码。但是,你的程序总会有错误。另外,硬件问题更难以保护。最常见的解决方案是冗余。通过建立带有重复资源的机器,我们可以显着减少系统停机时间。如果一台机器每个月有 10% 的几率崩溃,那么使用一台备份机器,我们将两台机器都停机的概率降低到 1%。

冗余 VS 分片

乍一看,冗余与分片非常相似。那么这两者有什么关系呢?在设计分布式键值存储时,如何在冗余和分片之间进行选择?

首先,我们需要清楚这两种技术的目的。分片基本上用来分割数据到多台机器,因为一台机器不能存储太多的数据。冗余是保护系统免于宕机的一种方式。考虑到这一点,如果一台机器不能存储所有的数据,冗余就没有用。

冗余

通过引入冗余,我们可以使系统更健壮。但是,一致性是个问题。比如存在机器 A1,我们有冗余 A2。你如何确保 A1 和 A2 具有相同的数据?例如,当插入一个新条目时,我们需要更新两台机器。但其中一个写入操作可能失败。所以随着时间的推移,A1 和 A2 可能会有很多不一致的数据,这是一个很大的问题。

这里有几个解决方案。第一种方法是将本地副本保存在协调机中。无论何时更新资源,协调机都会保留更新版本的副本。因此,如果更新失败,协调员可以重新进行操作。

另一种方法是提交日志。如果你一直在使用 Git,那么提交日志的概念对你来说应该是相当熟悉的。基本上,对于每个节点机器,它将保留每个操作的提交日志,就像所有更新的历史一样。所以当我们想要更新机器 A 中的条目时,它会首先将这个请求存储在提交日志中。然后一个单独的程序将按顺序处理所有提交日志(在队列中)。每当一个操作失败时,我们可以很容易地恢复,因为我们可以查找提交日志。

我想介绍的最后一种方法是解决读取中的冲突。假设当请求的资源位于 A1,A2 和 A3 时,协调机可以请求所有三台机器。如果数据不同,系统可以即时解决冲突。

值得一提的是,所有这些方法都不是互斥的。基于应用程序你肯定可以使用多个。

读取吞吐量

在这篇文章中,我还想简单地提一下读取吞吐量。 通常,键值存储系统应该能够支持大量的读请求。 那么你将使用什么方法来提高读取吞吐量?

为了提高读取吞吐量,常用的方法是总是利用内存。 如果数据存储在每个节点机器的磁盘中,我们可以将其中的一部分移动到内存中。更普遍的想法是使用缓存。 由于设计缓存系统的文章已经深入分析了这个话题,所以在这里我就不多说了。

总结

不要把这里的分析看作标准答案。 相反,这些常见的解决方案应该给你灵感,来帮助你想出不同的想法。

没有适用于每个系统的解决方案,你应该总是根据特定的情况调整你的方法。

results matching ""

    No results matching ""