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

Merge branch 'v1.11' into low-application-helath-probe-timeout

This commit is contained in:
Hannah Hunter 2023-07-27 11:26:31 -04:00 committed by GitHub
parent 845c75fb9f 6c4ed26c7a
commit 15915714b2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 17 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-overview.md
View File

@ -102,14 +102,27 @@ Dapr solves multi-tenancy at-scale with [namespaces for consumer groups]({{< ref
Dapr guarantees at-least-once semantics for message delivery. When an application publishes a message to a topic using the pub/sub API, Dapr ensures the message is delivered *at least once* to every subscriber.
Even if the message fails to deliver, or your application crashes, Dapr attempts to redeliver the message until successful delivery.
All Dapr pub/sub components support the at-least-once guarantee.
### Consumer groups and competing consumers pattern
Dapr automatically handles the burden of dealing with concepts like consumer groups and competing consumers pattern. The competing consumers pattern refers to multiple application instances using a single consumer group. When multiple instances of the same application (running same Dapr app ID) subscribe to a topic, Dapr delivers each message to *only one instance of **that** application*. This concept is illustrated in the diagram below.
Dapr handles the burden of dealing with consumer groups and the competing consumers pattern. In the competing consumers pattern, multiple application instances using a single consumer group compete for the message. Dapr enforces the competing conusmer pattern when replicas use the same `app-id` without explict consumer group overrides.
When multiple instances of the same application (with same `app-id`) subscribe to a topic, Dapr delivers each message to *only one instance of **that** application*. This concept is illustrated in the diagram below.
<img src="/images/pubsub-overview-pattern-competing-consumers.png" width=1000>
<br></br>
Similarly, if two different applications (with different app-IDs) subscribe to the same topic, Dapr delivers each message to *only one instance of **each** application*.
Similarly, if two different applications (with different `app-id`) subscribe to the same topic, Dapr delivers each message to *only one instance of **each** application*.
Not all Dapr pub/sub components support the competing consumer pattern. Currently, the following (non-exhaustive) pub/sub components support this:
- [Apache Kafka]({{< ref setup-apache-kafka >}})
- [Azure Service Bus Queues]({{< ref setup-azure-servicebus-queues >}})
- [RabbitMQ]({{< ref setup-rabbitmq >}})
- [Redis Streams]({{< ref setup-redis-pubsub >}})
### Scoping topics for added security

2
daprdocs/content/en/developing-applications/building-blocks/pubsub/subscription-methods.md
View File

@ -223,7 +223,7 @@ Both of the handlers defined above also need to be mapped to configure the `dapr
app.UseEndpoints(endpoints =>
{
endpoints.MapSubscribeHandler();
}
});
```
{{% /codetab %}}