matticakes

5 ms·

1.
by matticakes 9y ago
I'm one of the original authors, happy to answer any questions.
2.
by matticakes 12y ago
NSQ is a full-featured messaging platform out-of-the-box, whereas zeromq and nanomsq are lower level libraries that you could use to build (the same) functionality.
3.
by matticakes 12y ago
You 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.
4.
by matticakes 12y ago
Thanks! 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 conce
5.
by matticakes 12y ago
Yea, in the original announcement blog post (which became the design doc): http://nsq.io/overview/design.html
6.
by matticakes 12y ago
(project author) I appreciate all the work that Tyler has put into his series of blog posts on messaging systems (and NSQ bug reports!) but I think this particular article is one that misses the mark [1]. While raw performance is important,
7.
by matticakes 12y ago
(project author) NSQ is as much about what it doesn't do as it is what it does. To a certain extent this mirrors, and was inspired by, the language's philosophy (Go) [1]. Also, NSQ was designed to replace an existing home-grown s
8.
by matticakes 12y ago
check out NSQ, designed for (in part) exactly this use case (and also written in Go) http://bitly.github.io/nsq
9.
Go Advent Day 22 - A Journey Into NSQ(blog.gopheracademy.com)
2 points by matticakes 13y ago|0 comments
10.
by matticakes 13y ago
NSQ treats the message data as an opaque blob so the format wouldn't directly affect it (except on some lower level related to overall message size I suppose). It would impact your producers (encoding) and consumers (decoding), obviously.
11.
by matticakes 13y ago
there are a few (growing) number of production installations of NSQ... our (bitly's) cluster spans a a few datacenters and hits peaks of 80k messages/second. I can answer any questions you have (one of the authors)
12.
Disney Issues Press Release Confirming J.J. Abrams For ‘Star Wars Episode VII’(slashfilm.com)
2 points by matticakes 14y ago|0 comments
13.
by matticakes 14y ago
You can swap out the "metrics system" described in the post with any downstream system. I have a lot of experience with NSQ but have not used NewRelic. I can answer any specific questions you might have...
14.
by matticakes 14y ago
Thanks. For the record... NSQ is a generic messaging platform and is data format agnostic, there is nothing specific about metrics collection (it was just my contrived example).
15.
Spray some NSQ on it(wordbitly.tumblr.com)
25 points by matticakes 14y ago|7 comments
16.
by matticakes 14y ago
disclaimer: co-author of NSQ [1] here Agreed. Message queues play an important role for us (bitly) in being a layer of fault tolerance, buffering, and a means to perform various operational tasks. They're so important to us that we decided
17.
by matticakes 14y ago
It's a bit more explicit in NSQ but we essentially support multicast-like routing through "channels". A "channel" receives a copy (at the source) of all the messages for a "topic" and has its own set of clients subscribed.
18.
by matticakes 14y ago
The focal point is discovery. Not other queues (or other libraries that can build queues). This is an interesting way to approach it, thanks for open sourcing. We chose to solve the discovery problem a bit differently in NSQ ( https://githu
19.
by matticakes 14y ago
The truth is we wanted to use ZeroMQ initially. It would have been really awesome to have all that flexibility on the client side. The ZeroMQ documentation is fantastic as well. It inspired and helped shape some of the design choices we ma
20.
by matticakes 14y ago
That's fair, you certainly can use rabbitmq in a distributed and decentralized fashion. You bring up an important point though... What is important is the topology we're promoting and the platform we've built to support it. The actual queu
21.
by matticakes 14y ago
We looked into AMQP based solutions. Our understanding is that slaving, master-slave failover, or other strategies are used to mitigate the fact that there is a broker responsible for a given stream of messages. We wanted a brokerless, d
22.
by matticakes 14y ago
beanstalkd is a great project and it certainly inspired some of our thinking. I think of beanstalkd as a more fully functional alternative to simplequeue (what we built/used prior to NSQ - more details in our blog post http://word.bitly.c
23.
by matticakes 14y ago
Agreed, a comparison would be helpful for highlighting the tradeoffs behind the choices we made. We do talk about the evolution of our infrastructure and the genesis of NSQ in our blog post, http://word.bitly.com/post/33232969144/nsq .
24.
by matticakes 14y ago
it is data format agnostic so you can certainly serialize using the gob package.
25.
by matticakes 14y ago
one of the developers here... The protocols that exist in NSQ now are designed to be the simplest implementation that worked. You've correctly pointed out some of the issues. At this stage, the distinction of producer vs consumer was mostl
26.
NSQ: Realtime distributed message processing at scale (in Go)(github.com)
108 points by matticakes 14y ago|44 comments
27.
by matticakes 14y ago
perhaps its time to bring "the game programming megasite" back, too
28.
Dablooms - an open source, scalable, counting bloom filter library(github.com)
3 points by matticakes 14y ago|0 comments
29.
by matticakes 14y ago
bitly is overwhelmingly C and Python
30.
by matticakes 15y ago
For Sierra (kings quest, etc) fans there are a couple good options: http://sarien.net/ (web based!) http://www.agdinteractive.com/ (high-res remakes) http://www.tsl-game.com/ (The Silver Lining - a completely new game continuing the K

More ›