I'm looking for a pub/sub engine, with the following requirements:
- Very low latency < 0.5 sec
- Scalable
- Shardable (based on geo localisation)
I'd like to be able to have multiple pub/sub servers and be able to publish or subscribe to channels from any server, no matter on which server the channel is declared.
For example:
If user A is connected to server SRV1 and user B connected to server SRV2, If user B subscribe to "开发者_开发技巧;MyChannel" and user A publish something on channel "MyChannel", user B will get the message even if he's not connected to the same server.
I don't know if Redis is able to do that. I didn't find anything about the subject.
We've been using ZeroMQ and it's pub/sub features for while now and we're very happy with what we're seeing.
It's also worth looking at what's coming up in the next version (reducing network bandwidth by pushing subscription requests upstream)
I suggest you look at Data Distribution Service for Real Time Systems (DDS) standard. It's specifically designed to be a scalable pub/sub middleware both for real-time and non-real-time systems.
It has a few mature implementations all of which has it's own strength points, but generally the implementations are scalable and low latency.
These are the implementations I would suggest you look at (If you need them to work on a WAN environment, I guess the first two ones have great support for that):
- RTI DDS
- OpenSplice DDS
- OpenDDS
- CoreDX DDS
It seems you are looking for some sort of messaging. Try RabbitMQ, with shovel or federation plugins
nanomsg
is a successor to ZeroMQ
, written by the same author, and with many language-bindings.
It is written in C and uses zero-copy mechanisms. If you're looking for exceptional latency, and are willing to get your hands dirty ( which you should if you aim for something extreme ), I would recommend one of those two.
If you're looking for exceptional throughput, go with Kafka
.
Note, none of those solutions implement geolocation out of the box, Redis 3.2 will have something : http://antirez.com/news/89
If you are looking for an easy, "good enough" solution, I'd go with Redis
( be sure to read this blog post from aphyr first ).
精彩评论