July 20th, 2016
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
Why does Kafka get all the attention if Kestrel is so reliable? I assume this is because Kafka can do so much more, though of course the devops work of Kafka can be frightening. I didn’t know about the Blaine Cook connection (of Twitter fame):
Before I get too far a long with this fairy tail, let’s talk about Kestrel — what is it and why did I pick it?
Kestrel is a simple, distributed message queue, based on Blaine Cook’s starling. Here are a few great paragraphs from the readme:
Each server handles a set of reliable, ordered message queues. When you put a cluster of these servers together, with no cross communication, and pick a server at random whenever you do a set or get, you end up with a reliable, loosely ordered message queue.
In many situations, loose ordering is sufficient. Dropping the requirement on cross communication makes it horizontally scale to infinity and beyond: no multicast, no clustering, no “elections”, no coordination at all. No talking! Shhh!
It features the memcached protocol, is durable (journaled), has fanout queues, item expiration, and even supports transactional reads.
My favorite thing about Kestrel? It is simple, soooo simple. Sound too good to be true? Probably is, but the honeymoon has been great so far.
Now that we’ve covered what Kestrel is and that it is amazing, let’s talk about how I rolled it out.
Also, I wonder if this is normal? I’ve never seen this before:
We override a method just to make sure that the method does nothing?Source