cassandra - 如何在 Cassandra 中快速增加计数器而不会过时

Question

我有一个 Cassandra 问题。您知道 Cassandra 如何更新/增加计数器吗？

我想使用一个可以写入 cassandra 的 Storm bolt (来自 Storm-contrib repo on github 的 CassandraCounterBatchingBolt)。但是，我不确定 incrementCounterColumn() 方法的某些实现是如何工作的......而且还有 cassandra 计数器的限制(来自:http://wiki.apache.org/cassandra/Counters)这使得它们对我的场景没用恕我直言:

如果写入意外失败(超时或与协调器节点的连接丢失)，客户端将不知道操作是否已执行。重试可能会导致 CASSANDRA-2495 计数过多。

计数器移除本质上是有限的。例如，如果您非常快速地发出序列“增量，删除，增量”，则删除可能会丢失

无论如何，这是我的场景:
我更新同一个计数器的速度比更新传播到其他 Cassandra 节点的速度要快。

Example:
Say I have 3 cassandra nodes. The counters on each of these nodes are 0.
Node1:0, node2:0, node3:0

An increment comes: 5 -> Node1:0, node2:0, node3:0

Increment starts at node 2 – still needs to propagate to node1 and node3
Node1:0, node2:5, node3:0

In the meantime, another increment arrives before previous increment
is propagated: 3 -> Node1:0, node2:5, node3:0

Assuming 3 starts at a different node than where 5 started we have:
Node1:3, node2:5, node3:0

现在，如果 3 作为增量而不是作为新值传播到其他节点
(和 5 相同)然后最终节点都等于 8，这就是我想要的。

如果 3 覆盖 5(因为它有一个较晚的时间戳)这是有问题的——不是我想要的。

您知道 Cassandra 是如何处理这些更新/增量的吗？

请注意，写入之前的读取仍然容易受到相同的问题的影响，具体取决于读取执行的副本节点(如果传播不远，仲裁仍然可能失败)

我也在想，也许在我的 Storm bolt 和 Cassandra 中放置一个缓存可能会解决这个问题，但这是另一个故事。

Answer 1

C* 中的计数器具有复杂的内部表示，可以避免在无领导分布式系统中计算事物的大多数(但不是全部)问题。我喜欢将它们视为分片计数器。一个计数器由许多由主机 ID 和版本号标识的子计数器组成。接收到计数器操作的主机只会增加自己的子计数器，也会增加版本。然后它将其整个计数器状态复制到其他副本，这些副本将其与其状态合并。当计数器被读取时，处理读取操作的节点通过总结来自每个主机的计数的总和来确定计数器值。

在每个节点上，计数器增量就像 Cassandra 中的其他所有内容一样，只是一次写入。增量写入到内存表中，本地值在读取时通过合并内存表和所有 SSTable 中的所有增量来确定。

当我说您不必担心计数器的递增速度超过 Cassandra 的处理速度时，我希望这个解释能帮助您相信我。由于每个节点都保留自己的计数器，并且从不复制增量操作，因此不可能像读取-修改-写入场景那样引入竞争条件导致计数丢失。如果 Cassandra 接受写入，您几乎可以保证它会计数。

但是，您不能保证的是，除非计数始终显示正确。如果将增量写入一个节点，但随后从另一个节点读取计数器值，则不能保证增量已被复制，您还必须考虑在网络分区期间会发生什么。这或多或少与 Cassandra 中的任何写入相同，它具有最终一致性的性质，并且取决于您用于操作的一致性级别。

还存在丢失确认的可能性。如果您在获得响应之前执行增量并断开与 Cassandra 的连接，您将无法知道您的写入是否得到了响应。当您恢复连接时，您也无法判断，因为在增加之前您不知道计数是多少。这是选择可用性而不是一致性的系统的一个固有问题，并且您为许多其他好处付出了代价。

最后，快速删除、增量、删除的问题是真实存在的，您应该避免。问题是增量操作本质上会重新激活列，如果这些操作彼此足够接近，它们可能会获得相同的时间戳。 Cassandra 严格执行最后写入，并根据操作的时间戳确定最后一个。如果两个操作具有相同的时间戳，则“较大”的一个获胜，这意味着按照严格的字节顺序排序的那个。这是真实的，但我不会太担心，除非您对相同的值进行非常快速的写入和删除(这可能是您的数据模型中的错误)。

这是 Cassandra 计数器内部结构的很好指南:http://www.datastax.com/wp-content/uploads/2011/07/cassandra_sf_counters.pdf