Cassandra、计数器和写入冲突答案

【问题标题】：Cassandra, Counters, and Write ConflictsCassandra、计数器和写入冲突
【发布时间】：2018-05-09 17:17:14
【问题描述】：

我们正在探索使用 Cassandra 作为存储时间序列类型数据的一种方式，所以这可能有点像个菜鸟问题。其中一个用例是从 Kafka 流中读取数据，查找匹配项，并增加一个计数器（例如，5 个客户点击了 beta 页面上的链接 alpha，将 (beta, alpha) 递增 5）。但是，我们希望非常广泛的并行度能够跟上负载，因此可能会有多个消费者同时从 Kafka 读取数据。

我的问题是：Cassandra 如何解决多个来源对给定计数器的多个同时写入？

据我了解，对具有不同时间戳的计数器的多次写入将按照收到的时间戳顺序添加到计数器中。但是，如果要同时写入 exact 相同的时间戳，Cassandra 的 LWW 模型会抛出其中一个计数器增量吗？

如果我们有一个大型集群（超过 100 个节点），ALL 或 QUORUM 写入的性能可能不足以跟上消息流量。使用 THREE 写入似乎可能会导致进程 #1 写入节点 A、B 和 C，但进程 #2 可能会写入 X、Y 和 Z。LWT 会在这里工作，还是不能擅长反击？

【问题讨论】：

标签： cassandra distributed-transactions consistency eventual-consistency

【解决方案1】：

我会尝试概念验证并对其进行基准测试，它很可能会正常工作。但在 Cassandra 中，计数器的性能并不是超级好，尤其是在存在大量争用的情况下。

计数器不像使用简单 LWW 的普通写入，它使用带有一些悲观锁定和专用缓存的 paxos。分区锁争用会使其速度变慢，而且 paxos 是一个昂贵的多网络跃点进程，先读后写。

使用 quorum，不要尝试用 CL 和计数器做一些时髦的事情，尤其是在进行基准测试以了解您是否需要它之前。只要您不尝试不断更新所有相同的分区，100 个节点的集群应该能够处理很多事情。

【讨论】：