StreamBridge与EnableBinding定义MessageChannel绑定的性能差异对比

两种实现方式回顾 #

当前推荐的StreamBridge方式 #

@Autowired
StreamBridge streamBridge;
....

bridge.send("binding1" , message);
bridge.send("binding2" , message);

旧版EnableBinding方式 #

MessageChannel binding1();
MessageChannel binding2();

...
binding1.send(message);
binding2.send(message);

性能开销差异 #

• StreamBridge的send方法每次调用时，会先根据传入的binding名称查找对应的MessageChannel实例。不过Spring内部会对这些通道实例做缓存，第一次查找会有微小的开销，后续调用直接取缓存，整体开销可以忽略。
• EnableBinding方式是直接注入预先声明好的MessageChannel实例，调用send时直接操作实例，没有查找步骤。理论上第一次调用的开销比StreamBridge略小，但缓存后两者的性能差异几乎可以忽略不计。

消息吞吐量差异 #

两者底层最终都是调用相同的MessageChannel发送逻辑，吞吐量本质上取决于你使用的消息中间件（如Kafka、RabbitMQ）的配置、性能，以及MessageChannel的类型（比如用ExecutorChannel可以异步提升吞吐量）。只要通道配置一致，两种方式的吞吐量没有明显差异。

轮询机制差异 #

生产者本身不存在轮询逻辑，两种方式都是主动触发式发送：调用send方法后直接将消息投递到通道，再由绑定的适配器转发到消息中间件。所以在轮询机制上，两者没有任何差异。

内容的提问来源于stack exchange，提问作者Augustine Theodore