当Cassandra端出现“掉落的突变”时，它是否将相应的故障返回给调用客户端？或者，即使在服务器端删除了相应的突变并导致数据丢失，对调用事务的调用客户端总是成功的响应吗？
在一个特定的实例中，当我们的TPS约为80K / sec，并且延迟增加了4000+ ms时，我们观察到了许多丢弃的突变（每秒约6k丢弃的突变）。该群集是6节点群集。现在不要与我节点/ cassandra yaml配置。总的来说，如何解决这种“掉落的突变”。 奇怪的是，即使后来，我们也无法重现这种行为。
答案 0 :(得分：0)
写入时，如果有足够多的副本在write_request_timeout_in_ms（默认为2秒）内响应，您将在客户端看到成功的响应。
因此，考虑这种情况，您正在以一致性QUORUM进行复制，复制因子为3。当从客户端向协调器发送写操作时，协调器会同时向所有三个副本发送写请求。如果2个副本能够在write_request_timeout_in_ms内进行响应，则协调器会将成功的响应发送回客户端。同时，如果第三个副本无法开始处理write_request_timeout_in_ms中的写突变，它将删除该突变。
在这种情况下，客户端看不到删除突变的事实，但是从客户端的角度来看这是可以的！您只需要一个法定数量的节点即可确认写入。
但是，从操作角度来看，这是一个令人担忧的问题。您的副本甚至在超时时间过去之前甚至无法开始处理突变，这不好！
有多种可能的原因，垃圾回收崩溃，硬件问题，或者您的群集配置不足。监视丢失的突变以识别这些情况是了解正在发生的事情的好一步。
如果您担心副本之间的一致性问题，则cassandra使用多种反熵机制进入一致状态。如果在读取数据时发现不一致，则通过应用具有最高时间戳的单元，读取修复将使副本在这些节点上进入一致状态。即使数据确实在必需的副本之间匹配，也可能会基于表的已配置读取修复机会来触发读取修复，以确保所有副本之间的数据一致。您还应该运行预定的repairs。
最后一点，如果没有足够多的副本来满足您的一致性级别，您将看到WriteTimeoutException出现在客户端。这可能意味着您的副本正在删除突变，但不一定是这种情况。他们本可以开始处理变异，但未在超时时间内完成处理。在这种情况下，写操作将应用于这些副本。