cassandra kafka连接源和最终一致性

时间:2017-04-12 06:49:11

标签: cassandra apache-kafka eventual-consistency apache-kafka-connect

我正在考虑使用Kafka connect将来自Cassandra的更新流式传输到Kafka主题。 StreamReactor的现有连接器似乎使用时间戳或uuidtimestamp来提取自上次轮询以来的新更改。使用insert语句中的now()插入时间戳的值。然后连接器保存上次接收的最大时间。

由于Cassandra最终是一致的,我想知道在使用时间范围进行重复查询以获得新变化时实际发生了什么。错过插入Cassandra的行是否存在风险,因为当使用WHERE create> = maxTimeFoundSoFar时,它“迟到”到查询的节点?

1 个答案:

答案 0 :(得分:1)

是的,您的"游标"前面可能会有更新的数据。如果您使用一致性级别1进行读写,那么当您已经继续处理时,即使您使用更高的一致性,也可能会遇到问题"取决于您的设置。基本上有很多事情都可能出错。

你可以通过使用旧的cassandra公式NUM_NODES_RESPONDING_TO_READ + NUM_NODES_RESPONDING_TO_WRITE > REPLICATION_FACTOR来增加不这样做的可能性,但由于你使用cassandra中的now(),节点时钟之间可能有毫秒的偏移,所以你甚至可能会错过数据如果您有高频数据。我知道一些系统,人们实际上使用覆盆子pi和gps模块来保持时钟偏差非常紧张:)

你必须提供更多关于你的用例的信息,但实际上是的,你可以完全跳过一些插入,如果你不是"小心"但即使这样,也没有100%的保证,除此之外你用一些偏移来处理数据,这足以让新数据进入并解决。

基本上你必须在过去保留一些移动时间窗口,然后再移动它,确保你没有考虑比最后一分钟说的更新的东西。这样你就可以确保数据已经解决了#34;。

我有一些用例我们处理过多天延迟的感官数据。在某些项目中,我们忽略了一些项目,因为我们总是处理旧数据并将其添加到报告数据库中。也就是说,我们在历史上保留了3天的时间窗口。

这取决于您的使用案例。