【问题标题】:cassandra kafka connect source and eventual consistencycassandra kafka 连接源代码和最终一致性
【发布时间】:2017-09-07 19:21:12
【问题描述】:

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

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

【问题讨论】:

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


    【解决方案1】:

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

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

    您必须提供有关您的用例的更多信息,但实际上是的,如果您不“小心”,您可以完全跳过一些插入,但即使那样,也没有 100% 的保证,否则您处理带有一些偏移量的数据会足以让新数据进入并稳定下来。

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

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

    这取决于您的用例。

    【讨论】:

    • 感谢您的回答。所以我的假设并不是完全错误的。我正在考虑将数据从 Cassandra 发布到 Kafka,以“实时”将数据推送给其他消费者。我真的不想丢失数据,所以我的方法可能并不理想
    猜你喜欢
    • 1970-01-01
    • 2011-06-02
    • 2017-09-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-06-05
    • 2017-11-27
    • 1970-01-01
    相关资源
    最近更新 更多