mirror of
https://github.com/taigrr/nats.docs
synced 2025-01-18 04:03:23 -08:00
Adding links, slight rewording, adding matcher example
Signed-off-by: Matthias Hanel <mh@synadia.com>
This commit is contained in:
parent
ec03a97d3c
commit
29deb9206d
@ -6,5 +6,4 @@ NATS makes it easy for programs to communicate across different environments, la
|
||||
|
||||

|
||||
|
||||
NATS core offers an **at most once** quality of service. If a subscriber is not listening on the subject \(no subject match\), or is not active when the message is sent, the message is not received. This is the same level of guarantee that TCP/IP provides. By default, NATS is a fire-and-forget messaging system. If you need higher levels of service, you can use [NATS Streaming](../nats-streaming-concepts/intro.md) or build additional reliability into your client applications with proven and scalable reference designs.
|
||||
|
||||
NATS core offers an **at most once** quality of service. If a subscriber is not listening on the subject \(no subject match\), or is not active when the message is sent, the message is not received. This is the same level of guarantee that TCP/IP provides. By default, NATS is a fire-and-forget messaging system. If you need higher levels of service, you can use [NATS Streaming](../nats-streaming-concepts/intro.md) or build additional reliability into your client applications with proven and scalable reference designs such as [acks](acks.md) and [sequence numbers](seq_num.md).
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
Request-Reply is a common pattern in modern distributed systems. A request is sent and the application either waits on the response with a certain timeout or receives a response asynchronously. The increased complexity of modern systems requires features such as location transparency, scale up and scale down, observability and more. Many technologies need additional components, sidecars and proxies to accomplish the complete feature set.
|
||||
|
||||
NATS supports this pattern with its core communication mechanism, publish and subscribe. A request is published on a given subject with a reply subject, and responders listen on that subject and send responses to the reply subject. Reply subjects are usually a subject called an \_INBOX that will be directed back to the requestor dynamically, regardless of location of either party.
|
||||
NATS supports this pattern with its core communication mechanism, publish and subscribe. A request is published on a given subject with a reply subject, and responders listen on that subject and send responses to the reply subject. Reply subjects are unique subjects called _inbox_ that are dynamically directed back to the requestor, regardless of location of either party.
|
||||
|
||||
NATS allows multiple responders to run and form dynamic queue groups for transparent scale up. The ability for NATS applications to drain before exiting allows scale down with no requests being dropped. And since NATS is based on publish-subscribe, observability is as simple as running another application that can view requests and responses to measure latency, watch for anomalies, direct scalability and more.
|
||||
|
||||
|
@ -40,4 +40,4 @@ Subject to your security configuration, wildcards can be used for monitoring by
|
||||
|
||||
### Mix Wildcards
|
||||
|
||||
The wildcard `*` can appear multiple times in the same subject. Both types be used as well. For example, `*.*.*.>` will receive `time.us.east.atlanta` as it is at least 4 tokens long.
|
||||
The wildcard `*` can appear multiple times in the same subject. Both types be used as well. For example, `*.*.east.>` will receive `time.us.east.atlanta`.
|
Loading…
x
Reference in New Issue
Block a user