Add doc for pubsub rabbitmq exchage kind (#2207)

* Add doc for pubsub rabbitmq exchage kind

Signed-off-by: zhangchao <zchao9100@gmail.com>

* fix review

Signed-off-by: zhangchao <zchao9100@gmail.com>

* fix review

Signed-off-by: zhangchao <zchao9100@gmail.com>
This commit is contained in:
Taction 2022-02-24 05:13:51 +08:00 committed by GitHub
parent f70adde726
commit 20f51d531d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 28 additions and 0 deletions

View File

@ -51,6 +51,8 @@ spec:
value: 3000
- name: maxLenBytes # Optional maximum length in bytes of a queue.
value: 10485760
- name: exchangeKind
value: fanout
```
{{% alert title="Warning" color="warning" %}}
The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described [here]({{< ref component-secrets.md >}}).
@ -81,6 +83,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
| enableDeadLetter | N | Enable forwarding Messages that cannot be handled to a dead-letter topic. Defaults to `"false"` | `"true"`, `"false"` |
| maxLen | N | The maximum number of messages of a queue and its dead letter queue (if dead letter enabled). If both `maxLen` and `maxLenBytes` are set then both will apply; whichever limit is hit first will be enforced. Defaults to no limit. | `"1000"` |
| maxLenBytes | N | Maximum length in bytes of a queue and its dead letter queue (if dead letter enabled). If both `maxLen` and `maxLenBytes` are set then both will apply; whichever limit is hit first will be enforced. Defaults to no limit. | `"1048576"` |
| exchangeKind | N | Exchange kind of the rabbitmq exchange. Defaults to `"fanout"`. | `"fanout"`,`"topic"` |
### Backoff policy introduction
@ -122,6 +125,31 @@ For example, if installing using the example above, the RabbitMQ server client a
{{< /tabs >}}
## Use topic exchange to route messages
Setting `exchangeKind` to `"topic"` uses the topic exchanges, which are commonly used for the multicast routing of messages.
Messages with a `routing key` will be routed to one or many queues based on the `routing key` defined in the metadata when subscribing.
The routing key is defined by the `routingKey` metadata. For example, if an app is configured with a routing key `keyA`:
```
apiVersion: dapr.io/v1alpha1
kind: Subscription
metadata:
name: order_pub_sub
spec:
topic: B
route: /B
pubsubname: pubsub
metadata:
routingKey: keyA
```
It will receive messages with routing key `keyA`, and messages with other routing keys are not received.
```
// publish messages with routing key `keyA`, and these will be received by the above example.
client.PublishEvent(context.Background(), "pubsub", "B", []byte("this is a message"), dapr.PublishEventWithMetadata(map[string]string{"routingKey": "keyA"}))
// publish messages with routing key `keyB`, and these will not be received by the above example.
client.PublishEvent(context.Background(), "pubsub", "B", []byte("this is another message"), dapr.PublishEventWithMetadata(map[string]string{"routingKey": "keyB"}))
```
For more information see [rabbitmq exchanges](https://www.rabbitmq.com/tutorials/amqp-concepts.html#exchanges).
## Related links
- [Basic schema for a Dapr component]({{< ref component-schema >}}) in the Related links section