dapr
/
docs
mirror of https://github.com/dapr/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-subscribe-statefulset.md 

Co-authored-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com>
Signed-off-by: Artur Souza <asouza.pro@gmail.com>
This commit is contained in:
Artur Souza 2023-02-15 09:17:29 -08:00 committed by GitHub
parent 90aa48914b
commit 40851fffc5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-subscribe-statefulset.md
View File

@ -39,7 +39,10 @@ spec:
When subscribing to a pub/sub topic via Dapr, the application can define the `consumerID`, which determines the subscriber's position in the queue or topic. With the StatefulSets sticky identity of Pods, you can have a unique `consumerID` per Pod, allowing each horizontal scale of the subscriber application. Dapr keeps track of the name of each Pod, which can be used when declaring components using the `{podName}` marker.
On scaling the number of subscribers of a given topic, each component in Dapr has its unique settings to determine the behavior. Usually, there are two options for multiple consumers: broadcast or shared. In the broadcast configuration, each message published to the topic will be consumed by all subscribers. While in the shared option, a message is consumed by any subscriber (but not all).
On scaling the number of subscribers of a given topic, each Dapr component has unique settings that determine the behavior. Usually, there are two options for multiple consumers:
- Broadcast: each message published to the topic will be consumed by all subscribers.
- Shared: a message is consumed by any subscriber (but not all).
Kafka isolates each subscriber by `consumerID` with its own position in the topic. When an instance restarts, it reuses the same `consumerID` and continues from its last known position, without skipping messages. The component below is an example on how a Kafka component can be used by multiple Pods: