4 ms·
Having played with NSQ off and on for the past few months, and having gone deeper with it over the past week or so in preparation for rolling out a production s
by joshrotenberg 12y ago
Having played with NSQ off and on for the past few months, and having gone deeper with it over the past week or so in preparation for rolling out a production service, here are a few things that have really impressed me, in no particular order:
It's super easy to run. A few command line params, if that, and I've got a local nsqd running that I can develop and test against. Great for those offline coding sessions on BART.
The tools it ships with are very handy, specifically to_nsq and nsq_tail. Again, both make developing stuff really easy because I can get stuff in and out with fast, native command line tools or http. In fact, when I was first playing around I built an entire prototype based on a few simple shell scripts and the provided tools, just to see what would happen.
The nsqadmin and nsq_stat tools give you a lot of visibility into what your producers and consumers are doing, how well things are performing, who is connected to what, etc. And again, part of the distribution and very easy to run locally.
The Go producer and consumer API is clean and easy to build around, pretty well documented with a lot of examples in the NSQ apps themselves.
So far very stable. I haven't seen any crashes on the server or producer/consumer side.
Helpful and friendly people on a low noise freenode channel.
- matticakes 12y agoThanks! This is something that I've always tried to stress when talking about NSQ... The "message queue" is the most boring and uninteresting aspect of the system. It's the combination of out-of-the-box tooling and conceptually simple primitives that really differentiate it from other systems.
- ryanjshaw 12y agoThe Features page says it is "horizontally scalable (no brokers, seamlessly add more nodes to the cluster)", but the Design page says you need to run a 'nsdq' daemon - which is a message broker - i.e. you cannot embed the daemon into your application?
- matticakes 12y agoYou can embed the daemon into your application. That sentence is missing an important word. No centralized brokers, meaning the typical/recommended deployment topology is an nsqd node on all hosts producing messages.
- joshrotenberg 12y agoYou can embed nsqd (in Go): https://gist.github.com/joshrotenberg/ad49d39dbee8b48789d9 https://gist.github.com/joshrotenberg/ad49d39dbee8b48789d9 That said, for a larger deployment you'd still probably want to run the lookupd as well, at which point, at least for a typical architecture, running nsqd standalone is probably fine. Embedding is darn handy for testing, though.
- retr0h 12y agoYeah, I love it. There are some good modules out there for installing it too. https://github.com/simplereach/chef-nsq https://github.com/simplereach/chef-nsq https://galaxy.ansible.com/list#/roles/2265 https://galaxy.ansible.com/list#/roles/2265