事件驱动架构：Event Broker是推送事件还是由Event Processor监听？

阿华AIGC实验室

2026-5-26

Hey there! Great question—this is a super common point of confusion when you're just getting started with Event-Driven Architecture (EDA), and the short answer is both statements are correct! It all comes down to the two main messaging models supported by most Event Brokers: push and pull. Let me break this down for you:

Push Model: Broker主动推送事件

This is the more widely used pattern in typical EDA setups (think tools like RabbitMQ or Kafka's default behavior). Here's how it works:

An Event Creator generates an event and sends it to the Event Broker.
The Broker keeps track of all subscribers (Event Processors) that have signed up for that event type or topic.
As soon as the Broker receives the event, it actively pushes it out to every subscribed Event Processor—no need for the processors to constantly check for new events.
This model is great for real-time event delivery since events reach processors as soon as they're available.

Pull Model: Processor主动拉取事件

This is the scenario described as "Event Processors always listening to the Broker to receive events":

Instead of waiting for the Broker to send events, Event Processors initiate requests to the Broker to fetch new events whenever they're ready to handle them.
Tools like Kafka explicitly support this model—consumers (your Event Processors) can poll the Broker for messages at a rate they control.
This is useful when you want to limit how many events a processor handles at once (to avoid overwhelming it) or when you need more control over the timing of event processing.

Why the conflicting info online?

Different resources focus on different Broker implementations or use cases. Many Brokers actually support both models (Kafka is a perfect example), so authors might highlight the one that's most relevant to their specific scenario. Neither statement is wrong—they're just describing two sides of the same EDA coin.