【问题标题】:How do I calculate how long eventual consistency takes to become consistent?我如何计算最终一致性需要多长时间才能变得一致?
【发布时间】:2013-03-11 11:58:54
【问题描述】:

我开始研究 nosql 和面向文档的数据库来存储我们将在我们的网站上提供的 HTML5 应用程序的资产。这旨在替代仅在文件系统上存储文件。它们将是小型的 Web 优化文件,包括 html、js、css 和 xml 等文本文件,以及图像、声音和字体等二进制文件。

由于我对容错感兴趣,我正在研究的解决方案(riak,Cassandra)使用最终一致性。虽然我在抽象层面上理解了这个概念,但当我与经理和决策者交谈时,我无法用实际术语解释多长时间最终一致性需要变得一致。毫秒?秒?分钟?由于我在这个领域没有任何经验,所以我正在寻找现实世界的经验,这意味着什么。

我知道不同的变量将确切地决定任何配置需要多长时间,但我需要能够开始了解我们需要构建哪些类型的基础架构来支持我们的需求。所以我正在寻找的是我们是否需要优化网络延迟、节点数量等来支持我们的特定需求。

我们希望达到选择要测试的平台的程度,并且在我们将时间投入任何特定解决方案之前,我们希望能够说“不,这对我们不起作用。”

我们现在拥有使用严格一致性的系统(例如我们的网络服务器和我们的 mysql 数据库上的文件系统),因此我们的管理习惯于加载和超时等概念,以及“关闭”的事情。但我无法与他们沟通“是的,数据现在不可用,但它没有关闭;它将最终可用”。他们想知道“嗯,‘最终’有多长”?

我如何判断最终一致的系统是否会在我们的网站上实际运行?

【问题讨论】:

    标签: nosql eventual-consistency


    【解决方案1】:

    由于我对 Riak 的熟悉程度远胜于 Cassandra,因此我将只讨论最终一致性如何应用于 Riak。

    在正常运行期间,Riak 支持tuneable consistency,它允许您根据应用程序要求定制一致性行为。然而,默认设置非常合理,适用于大多数情况,因为它们需要大部分 replicas 来响应读取或写入,然后才能被视为成功。

    虽然所有副本可能并非在每个时间点都处于完全相同的状态,但这些一致性设置将确保您阅读所写的内容。传统上通过称为read-repair 的过程在读取时更正不一致,但如果启用主动反熵(Riak 1.3 版中的新功能),也可以定期更正。

    Eventual consistency 主要是在各种故障情况下考虑。如果例如一个节点与集群的其余部分分离,它将(使用默认设置)继续能够接受写入和读取,它将根据它所拥有的数据/副本尽其所能提供服务。由于在此期间它无法与集群的其余部分通信,因此可能会出现不一致。但是,一旦集群恢复到正常运行状态,这些问题就会得到解决。这需要多长时间取决于许多外部因素,范围可能从临时网络故障的几分之一秒到需要人工干预来纠正问题的几分钟或几小时不等。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2015-06-05
      • 2022-01-12
      • 1970-01-01
      • 2017-05-23
      • 1970-01-01
      • 2016-03-18
      • 2021-11-05
      相关资源
      最近更新 更多