緩衝彈簧集成發佈 - 訂閱頻道

Question

我有一個彈簧集成應用程序，它有一個pub-sub頻道和兩個訂閱者 - 一個發佈消息給Kafka，另一個將消息寫入文件。問題在於將消息寫入文件的服務激活器無法跟上產生給Kafka的其他服務激活器的速度。這會導致整個消息處理速度變慢。爲了克服這個問題，我在pub-sub通道和寫入文件的服務激活器之間增加了一個額外的層。一個變壓器，除了消耗信息，並將信息放入由文件撰寫者消耗的直接通道中。這改善了我的情況，但我想知道這是否是正確的方法？下面的示例配置：

所有的

<int:publish-subscribe-channel id="pschannel"/> 
<int:service-activator id="kafkaSA" ref="producer" input- channel="pschannel" method="publish"/> 
<int:transformer input-channel="pschannel" ref="dummytransformer" method="doNothing" output-channel="directChannel"/> 
<bean id="dummytransformer" class="org.test.DummyTransformer"/> 
<int:channel id="directChannel"> 
    <int:queue capacity="200000" /> 
<int:channel> 
<int:service-activator id="fileSA" ref="filewriter" input-channel="directChannel" method="publish" > 
    <int:poller max-messages-per-poll="10000" fixed-delay="100" /> 
</int:service-activator> 

Answer 1

首先，它不是直接因爲真的是<queue>通過你的配置。

嗯，這真的是一種方式，你絕對不會阻止你的卡夫卡製片人（第一位訂閱者）。

您應該考慮隊列和輪詢無限的配置：

<int:channel id="directChannel"> 
    <int:queue/> 
<int:channel> 
... 
<int:poller fixed-delay="100" /> 

這樣對directChannel消費者將處理在其最好的步伐在其他地方不會造成滯後的消息。

另一種分配方式是publish-subscribe-channel的task-executor - 所有訂閱者都將在其一個線程中執行。

但是，是的，任何你應該記住的方式，你總是會有一個卡夫卡和文件製作人之間的滯後。

您不需要任何DummyTransformer，順便說一句。關於此事有一個特殊的<bridge>組件：http://docs.spring.io/spring-integration/reference/html/messaging-channels-section.html#bridge