如何在Cassandra中快速增加计数器（不含过时）

我有一个卡桑德拉问题。你知道卡桑德拉是如何更新/增加计数器的吗

我想使用一个写入cassandra的storm bolt（github上storm contrib repo的CassandraCounterBatchingBolt）。但是，我不确定incrementCounterColumn（）方法的某些实现是如何工作的。。cassandra计数器（来自：）也有一些限制，这使得它们在我的场景IMHO中毫无用处：

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

• 计数器的拆卸本质上是有限的。例如，如果您很快发出“增量、移除、增量”序列，则移除可能会丢失

无论如何，我的情况是：
我更新同一计数器的速度比更新传播到其他Cassandra节点的速度快

示例：
假设我有3个cassandra节点。每个节点上的计数器均为0。
节点1:0，节点2:0，节点3:0

一个增量出现：5->Node1:0，node2:0，node3:0

增量从节点2开始–仍然需要传播到节点1和节点3
节点1:0，节点2:5，节点3:0

同时，另一个增量在上一个增量之前到达
正在传播：3->Node1:0、node2:5、node3:0

假设3开始于不同的节点，而不是5开始于不同的节点：
节点1:3，节点2:5，节点3:0

现在，如果3作为增量而不是新值传播到其他节点 （和5一样）最后节点都等于8，这就是我想要的

如果3覆盖了5（因为它有一个更晚的时间戳），这是有问题的-不是我想要的

您知道卡桑德拉是如何处理这些更新/增量的吗？

请注意，写入之前的读取仍然容易出现相同的问题，这取决于读取从哪个副本节点执行（如果传播距离不远，仲裁仍然可能失败）

---

我也在想，也许在我的暴风雪和卡桑德拉之间放置一个缓存可以解决这个问题，但这是另一个时代的故事。

为了理解更新/增量，即写操作，我建议你通过流言，卡桑德拉用于通信的协议。在八卦中，每个参与者（节点）使用元组

σ（K）=（V*N）

来维护其状态，其中

σ（K）

是

K

键的状态，其中

V

值和

N

作为版本号

为了维护数据包的单一真相版本，流言维护了一种协调机制，即

Precise

和

Scuttlebutt

（当前）。根据

Scuttlebutt对账

，在更新任何元组之前，它们相互通信，以检查谁持有密钥的最高版本（最新值）。持有最高版本的人负责写操作

---

欲了解更多信息，请阅读此

C*中的计数器具有复杂的内部表示，可以避免无领导分布式系统中的大多数（但不是全部）计数问题。我喜欢把它们想象成碎片计数器。计数器由主机ID和版本号标识的多个子计数器组成。接收计数器操作的主机仅增加其自己的子计数器，还增加版本。然后，它将其整个计数器状态复制到其他副本，这些副本将其与其状态合并。读取计数器时，处理读取操作的节点通过对每个主机的计数总数求和来确定计数器值

在每个节点上，一个计数器增量就像Cassandra中的其他任何东西一样，只是一个写入。增量写入memtable，本地值在读取时通过合并memtable和所有SSTable中的所有增量来确定

我希望这个解释能帮助你相信我说的，你不必担心计数器的递增速度超过卡桑德拉的处理速度。由于每个节点都保留自己的计数器，并且从不复制增量操作，因此不可能像读-修改-写场景所引入的竞争条件那样丢失计数。如果卡桑德拉接受了这封信，你的信肯定会有价值

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

也有可能丢失确认信息。如果你做了一个增量操作，并在回复之前断开了与Cassandra的连接，你就不知道你的写操作是否成功了。当你恢复连接时，你也不知道，因为在你增加之前你不知道计数是多少。这是选择可用性而不是一致性的系统的固有问题，也是您为许多其他好处付出的代价

最后，快速删除、增量、删除的问题是真实存在的，应该避免。问题是增量操作本质上会恢复列，如果这些操作彼此足够接近，它们可能会得到相同的时间戳。Cassandra严格来说是最后一次写入，并根据操作的时间戳确定最后一次写入。如果两个操作具有相同的时间戳，“较大”的一个操作获胜，这意味着在stric中排序的一个操作获胜