cassandra kafka connect source and eventual consistency



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

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

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

您可以通过使用旧的 cassandra 公式来增加不这样做的机会NUM_NODES_RESPONDING_TO_READ + NUM_NODES_RESPONDING_TO_WRITE > REPLICATION_FACTOR但由于您使用的是 cassandra 的now(),节点时钟之间可能有毫秒偏移,因此如果您有高频数据,您甚至可能会错过数据。我知道有些系统,人们实际上正在使用带有GPS模块的树莓派来保持时钟偏差非常紧密:)

您必须提供有关您的用例的更多信息,但实际上,如果您不"小心",您可以完全跳过一些插入,但即便如此,也没有 100% 的保证,然后您处理带有一些偏移的数据,这足以让新数据进入并结算。

基本上,您必须在过去保留一些移动时间窗口,然后移动它,并确保您不会考虑比最后一分钟更新的任何内容。这样您就可以确保数据"稳定"。

我有一些用例,我们处理的感官数据会延迟好几天。在某些项目中,我们只是忽略了它,有些数据用于月份级别的报告,因此我们始终处理旧数据并将其添加到报告数据库中。即我们在历史记录中保留了 3 天的时间窗口。

这仅取决于您的用例。

相关内容

  • 没有找到相关文章

最新更新