对于我用过它，它创建了另外一个桥接实例和另外两个kafka主题，这会导致数据之间流动的延迟问题 - >＆gt;小号
So - source
p - processor
s - sink
用例创建数据流
1）对于新的记录流程应该如此=＆gt;小号
2）对于更新记录流应该是这样=＆gt; p =＆gt;小号
DSL:
demo1=so|p > :foo
demo2=:demo1.so > :foo
demo3=:foo > s
的问题：
1）这里的数据将来自so - ＆gt;输入通道/队列 - ＆gt;桥接（内部使用的demo.so主题） - ＆gt; foo主题 - ＆gt;输出通道/队列 - ＆gt; s
这里数据使用4队列从源流到接收器，这可能与数据流相比具有延迟问题 source - ＆gt; kafka - ＆gt;使用普通的春季启动与kafka消费者/制作人使用1 kafka主题**下沉**
这将创建so和foo作为添加队列，这会消耗我的资源和硬件。
2）这也创建了额外的网桥实例，并且实时我可以配置亚马逊网络服务来扩展我的应用程序实例（所以，p，s）但是发生了缩放处理器.bridge的人和方式
这将为名为demo2.bridge的桥创建额外的spring boot应用程序，它将共享我的资源和硬件
如果我尝试连接到不同的流流，那么桥接有意义，但是在单一且简单的流中，桥接器听起来不像实时生产解决方案。
此外，如果我正在开发具有N扇出的复杂流，那么这将创建N桥实例和N + 2添加队列/主题，从而消耗额外资源并影响应用程序性能。
如果没有额外的队列和实例创建，你能否建议更好地实现上述用例
答案 0 :(得分：0)
让我们用一个具体的用例重播你的例子，因为你的帖子中的拓扑及其描述有点令人困惑。
假设您将以下内容作为主要管道。
stream1 = http --server.port=9001 | filter > :fooTopic
在这种情况下，http和filter个应用将与唯一主题（即stream1.http）相关联，并且只要您在下游位置拥有命名通道，内部就会出现SCDF使用桥接处理器将filter app的输出连接到命名目标。总的来说，对于上述管道，您将有2个主题（即stream1.http和fooTopic）。
这是设计的。
现在，假设您想要对此主要管道进行TAP，并将“未经过滤”的数据转储到同一fooTopic。
stream2 = ":stream1.http > :fooTopic"
在这种情况下，将会创建 no 新主题。桥接处理器将用于连接幕后的命名目的地。这也是设计的。
如果我尝试连接到不同的流流，那么桥接有意义，但是在单一且简单的流中，桥接器听起来不像实时生产解决方案。
重申一下，当您在源位置或接收位置（或两者）具有命名目标时，桥接处理器仅 。请清理现有的设置，然后通过一个简单的示例重试（还有有意义的应用/名称）。