Current best practices for pub/sub reliability/failover

[mike.ko...@deque.com]

We're looking at implementing Redis solely as a pub/sub back-end, but are concerned about it being a single point of failure.

What is the best practice for this? It looks like the obvious solution would be to set up Redis instances on multiple servers (one a master and the others slaves), and use Sentinel to monitor them and handle failover, but I'm concerned about that "beta"/"work-in-progress" descriptor for Sentinel.

Is Sentinel and this master/slave approach the recommended high-availability configuration for production environments today, or is that more experimental and something else would be recommended? Does the pub/sub-only focus change things at all?

[Josiah Carlson]

Sentinel has actually been pretty solid for quite a while, perhaps 6 months or more. If you want to use Redis + pubsub, and you want failover, Sentinel is your best bet right now without paying for a 3rd party Redis as a service offering, assuming that you want to use Redis*.

If you are already in AWS or one of the other hosting providers, paying for hosting may be an interesting deal. Most Redis hosts charge by data stored. With pubsub, there is 0 data stored, so you could possibly get the lowest-level service for almost nothing, and get automatic failover for free. Some common offerings are from Redis Labs, Redis To Go, and OpenRedis, but you should check features and pricing before committing to one.

* There are other platforms that offer publish/subscribe functionality, some with very interesting features. Pubsub with Redis is very reasonable, and very easy to program against, but other non-Redis platforms may offer different tradeoffs that suit your needs better. Look into ZeroMQ and RabbitMQ in particular.

 - Josiah

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.