[HN Gopher] High-Performance server for NATS.io, the cloud and e...
___________________________________________________________________
High-Performance server for NATS.io, the cloud and edge native
messaging system
Author : Kinrany
Score : 66 points
Date : 2023-07-21 22:04 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| xupybd wrote:
| I'm using this in production. So far it's worked very well. Took
| a few hours to setup with certificates. Now it just works.
| zerbinxx wrote:
| What do you run it on?
| clumsysmurf wrote:
| I'm curious how this compares with MQTT, there seems to be some
| overlap.
|
| I was looking to stream sensor data from a mobile device using
| MQTT, but the Eclipse Paho Java client (1.2.5) hasn't seen a
| release in 3 years and I found it to be pretty buggy. There are
| lots of open issues on the GitHub page.
| ozarker wrote:
| MQTT is a protocol. Nats is a server that supports MQTT among
| other things
| pnpnp wrote:
| I have been a huge advocate of NATS.
|
| For anyone looking to support multiple message patterns on one
| message bus, this is what you want to check out.
|
| In AWS terms, it's like SNS/SQS/Kinesis all rolled into one bus &
| very intuitive to work with.
| vosper wrote:
| Any thoughts on NATS' JetStream? Looks quite compelling, to me.
|
| https://docs.nats.io/using-nats/developer/develop_jetstream
| jitl wrote:
| With all the message queue whatever thingies, as an outside I'm
| quite confused about ideal use cases.
|
| NATS vs MQTT vs Kafka vs Redis Queue vs Amazon SQS - how do they
| all stack up?
| atombender wrote:
| NATS is not a queue. It's distributed pub/sub message broker
| for communicating between applications.
|
| NATS's only responsibility is to route messages in near-real-
| time from publishers to consumers. Messages are ephemeral and
| dropped immediately after delivery; if nobody is listening, the
| messages vanish. Messages are only queued temporarily in RAM if
| the consumer is busy, and they can get dropped if a consumer
| doesn't handle them fast enough. In short, NATS is very
| lightweight and fast, and designed for things that are
| lightweight and fast. It's like a kind of distributed socket
| mechanism, and works best as a communication primitive you
| build stuff on top of (like TCP or UDP) rather than a fully
| fledged system.
|
| So it's very different from Kafka and other types of queues
| that are durable and database-like. Kafka is good for "fat
| pipes" that centralize data from producers into a log which is
| then consumed by massively parallel sets of consumers, and you
| don't constantly change this topology. NATS is good for
| networks of fast-changing producers and consumers that send
| small messages to each other, often one-on-one, although any
| fan-out topology works. It's great for firehose-type routing.
| For example, imagine you want your app to produce lots of
| different kinds of telemetry. Your app just sends messages to a
| topic "telemetry" or maybe a dotted topic like
| "telemetry.iostats" or "telemetry.errors". Then a client can
| "tap" into that topic by listening to it. If no client is
| listening, the firehose goes nowhere. But then a client can tap
| into "telemetry.errors" and get just the stream of error
| messages. Topics are just strings, so you can create unique
| topics for temporary things; an app can send a message to
| another app like "hey, do some work and then send the result to
| my temporary topic foobar726373".
|
| NATS is particularly notable for its "just works" design. The
| clustering, for example, ties together brokers with no effort.
| Clients typically don't need any configuration at all, other
| than the name of a NATS server.
|
| NATS _can_ be used as a low-level component to build stateful
| stuff. NATS Jetstream is a Kafka-like solution that stores
| durable logs, and uses NATS as its communication protocol.
| Liftbridge is another one.
| zerbinxx wrote:
| It is worth noting that the jetstream API (to me) (not that
| experienced) to lack some of the features of Kafka w.r.t.
| replayability - for instance I can't easily say "go back and
| re-run messages from X point-in-time". Instead it may be
| necessary to write custom handlers for replay or safeguard
| your systems to be very idempotent (a good pattern in event
| driven systems, but not one that is explicitly required by
| Kafkaesque messaging systems).
| Xeoncross wrote:
| Queues are often used for two reasons: as a way to throttle
| processing (just throw it into the queue and drain as you have
| time) and a way to avoid state loss (process the queue item and
| only ack/clear it once you've done X, Y, & Z. Of course there
| are more uses, but these are the two most common.
|
| Depending on the throughput you need, the number of clients
| pulling/putting into the queue, and other things you can rule
| out certain options. For example, Redis queue will be one of
| the fastest choices - but is very limited in capacity (memory
| size). SQS is basically unlimited capacity, but can often have
| 150ms or more of time elapse between when you put the item in
| and when it's available.
| paulgb wrote:
| MQTT is a protocol rather than an alternative to NATS; NATS
| supports MQTT (https://docs.nats.io/running-a-nats-
| service/configuration/mq...)
|
| As far as ideal use cases, we use NATS for https://plane.dev in
| two ways:
|
| - As a message bus, it is a layer of abstraction on top of the
| network. Instead of each node needing to establish a connection
| to every node it needs to connect to, it just connects to a
| NATS cluster and messages are routed by subject. This is great
| for debugging because we can "wiretap" messages on a given
| subject pattern and verify what's being sent. We even have a
| service that listens on NATS subjects and conditionally turns
| events into Slack messages.
|
| - It has a built-in RAFT implementation (via JetStream), which
| we piggyback on when we need to create consensus among nodes.
___________________________________________________________________
(page generated 2023-07-23 23:00 UTC)