最终一致的分布式数据库与幂等增加运算符？答案

【问题标题】：Eventualy consistent distributed database with idempotent increase operator?最终一致的分布式数据库与幂等增加运算符？
【发布时间】：2013-01-03 02:17:29
【问题描述】：

是否存在支持对标量值进行幂等操作的分布式高可用性、最终一致的数据库？

如果我们使用正常更新，那么我们有可能在不同的节点上有 2 个不同的值，并且没有一个值是正确的，因为我们需要增加两个交易值的金额。

是否有一个分布式数据库，我可以在其中发送命令 increase(key, attribute[column], diff) 以便当我收到响应时，我可以确定无论当前值如何，该操作都会在其他副本上执行的帐户？这样，即使 2 个不同的节点增加了不同的值，我也将获得最终一致性的增加操作，因为这种增加会传播到其他副本。

我不是在谈论条件更新，因为它不适用于像 cassandra 这样的高可用性数据库（这就是他们没有该功能的原因），我对原子增加操作感兴趣。

谢谢。

附：在幂等增加的情况下，我将有一个命令增加（key，attribute，diff，lock_key），这样如果 db 已经收到具有相同 lock_key 的相同命令，则它不会增加

tl;博士：

有没有办法在分布式 AP 类数据库中进行精确计数器？ 2个问题： 1）如果我发送操作以增加计数器但我没有得到响应，我会再次发送该请求但不想增加计数器两次。 2）如果该计数器在另一个副本上同时更新，我想最终结合这个增加，而不是覆盖这些值。那么是否有像 increase("John's balance", +5.67, "sdfsdfas") 这样的命令，其中 sdfsdfas 是一个用于丢弃重复更新的字符串。有没有复制这种命令的数据库？

【问题讨论】：

我不确定我是否理解这将是有用的场景。如果所有副本必须始终保持相同的值至关重要，那么它们必须保持同步。 “幂等更新”对此有何帮助？
如何只使用任何带有复制的数据库，然后等效地使用insert into increase_operations (target_id, increase_amount, operation_id)，然后使用 sum() 来获得胜利？ operation_id 是您识别重复操作的方式。它肯定最终是一致的。

标签： database nosql cassandra high-availability eventual-consistency

【解决方案1】：

在我看来，您在谈论两件不同的事情。幂等性意味着您可以多次发送increase 指令，但计数器只会增加一次。原子性对单个操作没有意义（它对多个操作有意义，例如，原子地增加计数器和增加的日期；要么都被修改，要么都不修改）。

MongoDB 支持“文档”级别的原子操作（我不确定您是否需要），但显然增量运算符不是幂等的（根据定义！否则您将如何增加计数器？）。

你能澄清你的问题吗？

此外，您不能拥有一个“最终一致”的数据库，其中所有节点每次都具有相同的给定键值。这就是它“最终一致”的原因，因为它不能保证它们“现在”是相同的。

至于答案，如果您想使用 MongoDB 来维护增量运算符，请使用以下模式（来自他们的网站，[$inc operator][1] 的示例）：

db.collection.update( { age: 20 }, { $inc: { age: 1 } } );
db.collection.update( { name: "John" }, { $inc: { age: 1 } } );

在你的情况下，应该是db.collection.update({$inc:{mycounter:1}});

【讨论】：

是的，我想要类似 update({ name: "John" }, { $inc: { balance: 58.4 } } );我是否在 MongoDB 中得到确认，这样我就不会两次运行相同的查询？这是一种方式。完成同样事情的另一种方法是使用一种幂等增加，这样相同的操作就不会运行两次。例如，如果命令需要提供某种 lock_key 以便它知道我是否已经尝试更新。我想在 AP 数据库中看到这样的功能（MongoDB 是 CP，对吗？）
在我的问题中添加了 tl;dr。

【解决方案2】：

好的，我看到问题 2 已经在 cassandra https://issues.apache.org/jira/browse/CASSANDRA-1072 中解决了分布式计数器将结合增加操作，因此最后一切都将保持一致。

问题 1（幂等性）是一个未解决的问题：https://issues.apache.org/jira/browse/CASSANDRA-4775

至少我知道人们会考虑这一点，这对我的场景非常重要，所以我会尽力帮助解决这个问题。

我希望这有助于澄清我的问题。

【讨论】：