[HN Gopher] New scalable, fault-tolerant, and efficient open-sou...
___________________________________________________________________
New scalable, fault-tolerant, and efficient open-source MQTT broker
Author : ashvayka
Score : 80 points
Date : 2023-12-18 14:28 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| statictype wrote:
| Is there programmable mqtt broker out there?
|
| Something that lets you integrate authentication with your auth
| provider and has built in multi-tenancy?
| rubenv wrote:
| RabbitMQ?
|
| https://www.rabbitmq.com/oauth2.html
| petre wrote:
| EMQX has several auth modules. We use the Mnesia auth module
| with HTTP API client id provisioning. They also have NanoMQ, a
| MQTT broker for IoT edge (on resource constrained devices). The
| documentation is also quite decent compared to this.
|
| https://www.emqx.io/docs/en/latest/access-control/authn/auth...
|
| They have a community edition available as a docker image or
| packages for popular Linux distros.
|
| https://www.emqx.com/en/try?product=broker
| efunnekol wrote:
| You should check out Solace's multi-protocol broker (free
| version: https://solace.com/downloads/) with support for MQTT,
| AMQP, SMF, REST, Websocket
|
| It supports integration with OAuth, LDAP, Radius, ,...
| adamcharnock wrote:
| Not sure about multi-tenancy, but I've been using VerneMQ with
| the Postgesql auth backend.
| discreteevent wrote:
| Have a look at Apache Artemis
| pkulak wrote:
| Wow, I had no idea there was even demand for this kinda thing. I
| guess I assumed all setups were like my MQTT server that takes
| events from a few Zigbee devices every few minutes.
| auspiv wrote:
| SCADA networks historically have very low available bandwidth
| (often due to being on the other end of a 10 mile radio link
| over 915 MHz with the radio & RTU powered by solar panels) and
| rely on a poll/response methodology. Even if nothing has
| changed, the poll happens, and the response sends the same
| exact data every poll. MQTT can be a far more efficient
| protocol if you only send updates. Multiply this situation by
| 1000x RTUs (now imagine you have a slightly better radio link
| from office to a remote tower, but that remote tower is
| communicating with 10x RTUs). You can see the need for
| efficient communication.
|
| Now - realize this is how natural gas pipelines are
| monitored/controlled in the mountains. You want that kind of
| communication to be reliable and scalable right?
| talldrinkofwhat wrote:
| Does MQTT offer anything novel to the call/response problem
| if it's not just updates (e.g. battery controlled nodes that
| need to know when to wake up and act)?
|
| I started developing a system ~a decade ago and ended up
| writing my own messaging protocols/queue systems. It's been
| an uphill battle, and if there's something a little more
| modern in the wings I'm all ears (I'm porting over to more
| modern uC's so it makes sense to re-evaluate the stack I
| suppose...)
| mannyv wrote:
| MQTT is heavily used in the IoT space because it's lightweight
| and doesn't require good connectivity.
| joezydeco wrote:
| I've taken to using MQTT as an interprocess communication bus
| for embedded systems.
|
| When you run the broker on the same device as your clients
| you can do some really nice things, like take messages out of
| the device and into your development machine. Or inject them.
| lfmunoz4 wrote:
| Apparently it is a spring boot app. Why are kafka and redis
| dependencies? Also I see Netty is used but not sure how was the
| MQTT protocol implemented, which library was used or was
| implemented in java from scratch?
|
| Also why wasn't emqx used? Why is this solution better for their
| use case?
| jsiepkes wrote:
| emqx presumably wasn't used because they are a Java shop and
| emqx is written in Erlang. Apparently they have a need for a
| massive scaling MQTT broker. At that point you need to be
| seriously comfortable with the tools you are using. Whether
| that's Java, Rust, Erlang, C#, C++ or whatever. Using an
| existing application in a language/ecosystem your team is not
| experts in is probably going to be a problem unless you
| seriously invest in the new language/ecosystem first. And it's
| going to take at least something like a thousand hours to
| really become good at something. The other option is writing an
| alternative in the language you are already familiar with. So
| in that regard I can understand why they did it.
|
| I guess they could have used the OSS HiveMQ version as a base
| though. No idea why they didn't do that.
| dlandiak wrote:
| Exactly, you described it well. I have answered above for the
| reasons why HiveMQ was not the final choice.
| crabbone wrote:
| I'm yet to see a project where Kafka was used for anything
| other than resume building. My guess would've been that this
| one is no different.
|
| Also, sometimes it could be used because in the previous
| company where the project author worked they've used Kafka. And
| the cycle continues.
| dlandiak wrote:
| We do not agree, but everyone has an opinion we should
| respect :)
| nurettin wrote:
| Nah, you don't need to respect cynicism.
| dlandiak wrote:
| You are correct. TBMQ is based on Spring Boot. We use Netty
| (https://netty.io/) as the source of the MQTT communication,
| and we build the MQTT features the MQTT broker should support
| ourselves on top of that. Kafka is used to implement scalable,
| fault-tolerant solution with reliable message persistence.
| Additionally, it helped to gain high-throughput processing and
| low-latency message delivery. We store published MQTT messages,
| client sessions, and subscriptions, etc., in Kafka. It proved
| its quality in practice and with performance tests. Redis is
| currently used for caching in cluster mode. In our roadmap, we
| also have a ticket to add the ability to store MQTT messages
| there. So, it will be a so-called Redis integration.
|
| Please see the architecture doc for more details:
| https://thingsboard.io/docs/mqtt-broker/architecture/
|
| We have implemented TBMQ to satisfy our enterprise customers'
| needs. Some of them used hivemq before but decided to ask us to
| build a new solution (TBMQ) as they were not fully satisfied
| with hivemq. One of the most important advantages we provided
| is cluster support in our open-source version compared to
| hivemq.
| bestouff wrote:
| If I must install a new long-running mission-critical daemon,
| it'll be written in Rust, not Java.
| deathtrader666 wrote:
| Long-running mission-critical stuff has been written in Erlang
| and running on BEAM since decades now.
| keep_reading wrote:
| Indeed, the correct solution here is emqx
| riku_iki wrote:
| they are java shop, learning/supporting new type of infra
| adds significant overhead.
| znpy wrote:
| Yeah but erlang it's not the current trendy thing, sadly.
|
| (I'm being ironic of course)
| ska wrote:
| And java is???
| __jonas wrote:
| Irony aside, Elixir definitely feels like a current trendy
| thing, or at the very least more trendy than Java.
| johnisgood wrote:
| Or Ada/SPARK.
| ComputerGuru wrote:
| Who is going to write it?
| verst wrote:
| And who is going to maintain it after the original developer
| moves on to another project?
| lelanthran wrote:
| Your computer must be woefully inadequate for use if you adhere
| to that principle.
| NortySpock wrote:
| https://github.com/bytebeamio/rumqtt
|
| Disclaimer: have not tried it myself. I was, however,
| considering using it to replace Mosquitto as a broker.
| BrandoElFollito wrote:
| Did you have a specific reason to replace mosquitto?
|
| I do not like mosquitto for several reasons, but I never
| really looked for a replacement (though I wild be happy to
| find one, and I see that rumqtt is bundled with docker so
| this could be it)
| frankfrank13 wrote:
| the rust cargo cult is real, pun not intended
| cmrdporcupine wrote:
| FWIW I'm a developer working full-time in Rust, advocate for
| the language, and am on a team of a half-dozen developers
| working on an (embedded) project in Rust...
|
| And none of us talk this way, nor do most people who work in
| and like the language that I encounter.
|
| There's always going to be a minority of people who talk this
| way about tech, doesn't make them representative.
| ecshafer wrote:
| There is probably 100,000x the actual computer runtime of
| actual mission critical software running java than Rust.
| Finance, Medical, Insurance. A huge amount of the actual
| critical software out there is Java.
| AeroNotix wrote:
| > TBMQ is an industry-ready MQTT broker developed and distributed
| under the ThingsBoard umbrella that facilitates MQTT client
| connectivity, message publishing, and distribution among
| subscribers.
|
| TBMQ is a scalable, fault-tolerant broker with the capacity to
| handle 4M+ concurrent client connections, supporting a minimum of
| 3M messages per second throughput per single cluster node with
| low latency delivery. In the cluster mode, its capabilities are
| further enhanced, enabling it to support more than 100M
| concurrently connected clients.
|
| You can refer to the TBMQ documentation to set up the broker and
| understand its primary features, including the MQTT protocol.
|
| These are strong numbers without benchmarks.
| ctippett wrote:
| They document their testing methodology here:
| https://thingsboard.io/docs/mqtt-broker/reference/100m-conne...
| AeroNotix wrote:
| Neat, thanks.
| dlandiak wrote:
| Right, we are not stating anything without proving it in
| the first place.
|
| You can find another test here:
| https://thingsboard.io/docs/mqtt-
| broker/reference/3m-through...
| _Microft wrote:
| Off-topic but maybe I'm speaking to the right audience here: are
| there any MQTT brokers for _very low loads_ that (ideally) run on
| a _microcontroller_? All I want to do is to collect and log power
| consumption reports from smart plugs and environmental data and I
| was thinking of something consuming orders of magnitude less
| power than a Raspberry Pi.
|
| Edit: thanks a lot!
| spdustin wrote:
| This is what you seek:
|
| https://github.com/alexCajas/EmbeddedMqttBroker
| chrisdalke wrote:
| Several different implementations exist, MQTT is a very
| lightweight protocol so this is very possible.
|
| https://github.com/hsaturn/TinyMqtt https://mongoose.ws/
| traceroute66 wrote:
| Why wasn't NATS[1] used ?
|
| Written in Go, single-binary deployment... there's a lot to love
| about NATS !
|
| [1]https://nats.io/
| znpy wrote:
| https://nats.io/about/ Says a lot of thing except what nats is
| ... is it like a service mesh? What is it, really? What does it
| do and what does it allow me to do ?
| crabbone wrote:
| I've used NATS before, and I might not have explored all the
| options, but what I used it for was a pub/sub model of
| messaging.
|
| I cannot speak to performance of NATS as we used it in low-
| traffic / low-demand setting. In terms of convenience, when
| used from Go, iirc, it offered some kind of built-in
| serialization (unlike eg. ZMQ, where you'd have to add your
| own).
|
| Debugging lost messages was painful, but I've never used a
| tool where it wasn't...
| alexisread wrote:
| NATS is equivalent to MQTT, just a different protocol. It has
| a persitence layer called Jetstream which is equivalent to
| Kafka ie. you can rewind through the message stream. The nice
| thing about NATS really is that it supports websockets unlike
| Kafka, it supports wildcard subtopics like MQTT, and it
| bridges very easily to both Kafka and MQTT (bidirectional).
|
| Other fancy stuff is yes, one binary to run it, and it can
| also through gossiping, support a distributed KV / object
| store like etcd / s3 except you can register watchers on it
| (https://docs.nats.io/nats-concepts/jetstream/key-value-
| store...).
| luma wrote:
| Because NATS isn't an MQTT broker?
| dlandiak wrote:
| We are not very familiar with NATS, does it support the whole
| functionality the MQTT broker should support? In addition, as
| it is not Java, but we are working with it, it could not be our
| solution.
| miovoid wrote:
| Java in 2023/2024?
| seabird wrote:
| Java is one of the most widely supported ecosystems available.
| I'm genuinely curious why throwing in on one of the most
| successful languages currently in existence warrants "in
| 2023/2024?".
| the_gipsy wrote:
| All depends in your definition of successful.
| cvalka wrote:
| Java is outdated and legacy. Avoid it if you can.
| assusdan wrote:
| Actually, it is up-to-date (new features twice a year, some
| of them, e.g. virtual threads, are truly SotA) and not
| legacy (things like graalvm and helidon 4 are relatively
| new and are awesome). Do not avoid Java if your project
| would benefit from it.
| miovoid wrote:
| Green threads, prevalent in the early 1990s, were utilized by
| Java in its initial stages but were replaced with native OS
| threads from JDK 1.2. Revived through Java's Project Loom
| around 2017, this initiative introduced "fibers" or "virtual
| threads" for a contemporary lightweight threading approach.
| Despite years of development, Project Loom hasn't been fully
| integrated into Java's standard releases. The Java ecosystem,
| struggling for decades to meet the demands for fault-
| tolerant, scalable software development, also faces
| significant memory usage problems, particularly in edge
| computing or when effectively utilizing cost-effective small
| virtual machines in clouds. Scylla 10 times faster successor
| of Cassandra written in C++. These issues compound the
| criticism of the Java ecosystem, leading to recommendations
| to avoid it both for developers and users. Opting for Java in
| greenfield projects in 2023/2024 can be seen as a blatant
| disregard for the evolution of technology and the current
| demands of the market, suggesting a profound lack of
| awareness in modern technological solutions and trends.
| xyst wrote:
| Java will be relevant for a very long time. Fortune 500 infra
| mostly built on Java at this point. Google. Apple.
|
| It's a very easy language to learn but at the same time can
| produce some of the worst codebases to maintain.
|
| Early versions of Java were kind of janky. Java 7 was
| notoriously verbose. But 8 and current LTS version have vastly
| improved performance of jvm and usability
| miovoid wrote:
| Green threads, prevalent in the early 1990s, were utilized by
| Java in its initial stages but were replaced with native OS
| threads from JDK 1.2. Revived through Java's Project Loom
| around 2017, this initiative introduced "fibers" or "virtual
| threads" for a contemporary lightweight threading approach.
| Despite years of development, Project Loom hasn't been fully
| integrated into Java's standard releases. The Java ecosystem,
| struggling for decades to meet the demands for fault-
| tolerant, scalable software development, also faces
| significant memory usage problems, particularly in edge
| computing or when effectively utilizing cost-effective small
| virtual machines in clouds. Scylla 10 times faster successor
| of Cassandra written in C++. These issues compound the
| criticism of the Java ecosystem, leading to recommendations
| to avoid it both for developers and users. Opting for Java in
| greenfield projects in 2023/2024 can be seen as a blatant
| disregard for the evolution of technology and the current
| demands of the market, suggesting a profound lack of
| awareness in modern technological solutions and trends.
| alternative_a wrote:
| How does this compare to using RabbitMQ's MQTT plugin?
|
| https://www.rabbitmq.com/mqtt.html
| Joel_Mckay wrote:
| RabbitMQ has MQTT support already, and is written for distributed
| systems.
|
| I often wonder if java is still really relevant these days... is
| it though? =)
___________________________________________________________________
(page generated 2023-12-18 23:00 UTC)