【问题标题】:Proper pattern for funneling processing of multiple streams into a single stream将多个流合并到单个流中的正确模式
【发布时间】:2019-01-09 05:56:49
【问题描述】:

现在我在 SCDF 中有一个流应用程序,它从数据库中的多个表中提取数据并将其复制到另一个数据库。目前,我们的目标是减少给定流正在执行的工作量,因此我们希望将流拆分为多个流并继续将数据复制到第二个数据库中。

是否有任何推荐的设计模式可以将这些不同流的处理整合为一个?

【问题讨论】:

    标签: java spring-cloud-dataflow


    【解决方案1】:

    如果我正确理解此要求,您可能希望按每个应用程序的 DB/表拆分摄取片段,然后将它们全部合并为一个“有效负载类型”以进行下游处理。

    如果您确实想按 DB/Table 拆分摄取,可以,但您可能需要考虑利弊。一个明显的好处是粒度,你可以独立地更新应用程序,也许还可以重用。当然,它也带来了其他挑战。个别应用的维护、修复和发布等等。

    也就是说,您可以将数据扇入到单个消费者。这是一个例子:

    foo1 = jdbc |变换 |高清晰度电视

    foo2 = jdbc > :foo1.jdbc

    foo3 = jdbc > :foo1.jdbc

    foo4 = jdbc > :foo1.jdbc

    这里,foo1 是从特定 DB/表组合读取数据的主要管道。同样,foo2foo3foo4 可以从其他 DB/表组合中读取。然而,这 3 个流正在将消费数据写入一个命名目标,在这种情况下恰好是 foo1.jdbc(又名:主题名称)。此目的地由 SCDF 在部署foo1 管道时自动创建;专门用于将“jdbc”和“transform”应用与foo1.jdbc 主题连接起来。

    总的来说,我们将不同的表数据路由到同一个目的地,因此下游应用程序,在这种情况下,transform 处理器从不同的表中获取数据。

    如果数据的相关性很重要,您可以通过每个jdbc 源的唯一键(例如,customer-id = 1001)在生产者处对数据进行分区,因此特定于上下文的信息位于相同的@987654332 @处理器实例(假设您有“n”个处理器实例用于横向扩展处理)

    【讨论】:

    • 这正是我想要的,谢谢。我在 SCDF 中找到了一些关于命名目的地的信息,这些信息在这里非常有用:docs.spring.io/spring-cloud-dataflow/docs/1.2.3.RELEASE/…
    • 不错!不过,请务必使用最新版本。 v1.2.3 已经很老了。当前的 GA 版本为 v1.6 - 您可以关注项目站点中的 platform table 以获取版本位和相应的平台特定文档。
    猜你喜欢
    • 1970-01-01
    • 2021-05-22
    • 1970-01-01
    • 1970-01-01
    • 2019-04-02
    • 1970-01-01
    • 1970-01-01
    • 2023-03-18
    • 1970-01-01
    相关资源
    最近更新 更多