database - 处理 Cassandra 写入失败的常见做法是什么?

标签 database cassandra consistency eventual-consistency

在文档[1]中,据说

if using a write consistency level of QUORUM with a replication factor
of 3, Cassandra will send the write to 2 replicas. If the write fails on
one of the replicas but succeeds on the other, Cassandra will report a 
write failure to the client. 

所以假设只有 2 个副本收到更新,写入失败。但由于最终一致性,所有节点最终都会收到更新。

那么,我应该重试吗?还是让它保持原样?

有什么策略吗?

[1] http://www.datastax.com/docs/1.0/dml/about_writes

最佳答案

那些文档不太正确。无论一致性级别 (CL) 是什么,写入都会发送到所有可用的副本。如果副本不可用,Cassandra 将不会向关闭的节点发送请求。如果从一开始就没有足够的可用空间来满足 CL,则会抛出 UnavailableException 并且不会尝试对任何节点进行写入。

但是,写入仍然可以在某些节点上成功,并向客户端返回一个错误。在 [1] 的示例中,如果在尝试写入之前一个副本已关闭,则写入的内容为真。

So assume only 2 replicas receive the update, the write failed. But due to eventually consistency, all the nodes will receive the update finally.

不过要小心:写入失败不会告诉您写入了多少个节点。它可能没有,因此写入可能最终不会传播。

So, should I retry? Or just leave it as it?

一般来说你应该重试,因为它可能根本就没有被写入。只有当您从写入中获得成功返回时,您才应该将您的写入视为已写入。

如果您使用计数器,您应该小心重试。因为您不知道是否进行了写入,所以您可能会得到重复计数。对于计数器,您可能不想重试(因为通常至少对一个节点进行写入,至少为了更高的一致性级别)。

关于database - 处理 Cassandra 写入失败的常见做法是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16018448/

相关文章:

mysql - 协助 SQL 查询返回不匹配的单元格

cassandra - native 传输请求全部被阻止

python - DataStax Enterprise 4.6.1/C* 使用 cqlengine 0.21.0 在 Python 中分页

c - Visual Studio 和 C 项目上的运行之间不一致

mysql - 从数据库中选择最新的历史记录

javascript - 来自数据库的依赖下拉列表值

OpenCL 2.0 - 在仅具有原子性的程序中进行竞赛

java - 数据存储和 Memcache 一致性 - Google App Engine 和 Objectify

database - 如何维护 LSM 树中的稀疏索引?

cassandra - cassandra 中的高读取延迟