Simple Message Queue (formerly MNS)

alibabacloud Queuealibaba-mns

Distributed messaging service whose queues deliver each message to one consumer at least once, with a publish-subscribe topic model alongside.

Provider: alibabacloud
Kind: Queue
Category: Messaging
Official docs: https://www.alibabacloud.com/help/en/mns/

Properties · 3 set by this component

property	type	values	required	kind default	this component
backoff	enum	none \| fixed \| exponential \| exponential-jitter	no	—	inherited
deadLetterQueue	boolean	—	no	false	inherited
delivery	enum	at-most-once \| at-least-once \| exactly-once	yes	—	▸ at-least-once
instances	integer	—	no	—	inherited
managed	boolean	—	no	false	▸ true
maxAttempts	integer	—	no	—	inherited
messagingModel · component property	enum	queue \| topic	no	queue	inherited
networkAccess · component property	enum	internet \| vpc	no	—	inherited
ordering	enum	none \| per-key \| global	no	none	inherited
persistence	boolean	—	no	true	inherited
replay	boolean	—	no	false	inherited
retentionDays	integer	—	no	—	inherited
role	enum	work \| dlq \| retry \| offline-mailbox \| frontier	no	work	▸ work

Rules that apply · 3

Every rule whose selector covers this component's kind or its category. Whether a rule fires depends on the design: its properties, its edges and its groups.

Queue without dead-letter queueerror

queue-missing-dlq

A queue that receives asynchronous traffic and has no dead-letter queue either drops poison messages or retries them forever. Neither outcome leaves anything for a human to investigate.

— all of these hold:
— the node's `deadLetterQueue` is false
— the node has at least one asynchronous incoming edge

Retry queue without dead-letter queueerror

retry-queue-without-dlq

A retry queue is where poison messages end up. With no dead-letter queue they are retried forever or dropped in silence, and nobody ever looks at the failed payment.

— all of these hold:
— the node's `role` is "retry"
— the node's `deadLetterQueue` is false

Retry queue without backoffwarning

retry-without-backoff

Retrying a transient failure at full speed turns one slow dependency into a retry storm. A retry queue backs off, preferably exponentially and with jitter.

— all of these hold:
— the node's `role` is "retry"
— any of these hold:
— the node's `backoff` has no value
— the node's `backoff` is "none"

Use it in a design

nodes:
  - { id: "mns", component: "alibaba-mns" }

Source

1# yaml-language-server: $schema=../../schema/component.schema.json
2# Simple Message Queue (formerly MNS): a distributed messaging service for moving data and notifications
3# between components of an application ("What is Simple Message Queue (formerly MNS)?"). That page states the
4# queue-based model has each message consumed by only one client and that every message in a queue is
5# delivered at least once during its validity period; a retrieved message then enters a configurable
6# invisibility period. The same page describes a topic-based publish-subscribe model and Internet or VPC
7# access. No retention or dead-letter default is documented, so neither is set.
8schemaVersion: "1"
9type: "component"
10id: "alibaba-mns"
11kind: "queue"
12provider: "alibabacloud"
13docs: "https://www.alibabacloud.com/help/en/mns/"
14defaults:
15  managed: true
16  delivery: "at-least-once"
17  role: "work"
18properties:
19  messagingModel:
20    type: "enum"
21    values: ["queue", "topic"]
22    default: "queue"
23  networkAccess:
24    type: "enum"
25    values: ["internet", "vpc"]

The same page as markdown, for an agent: /catalogue/components/alibaba-mns.md