What is the ServiceStack story with Redis and high availability (multi-zone setup) on AWS? Redis is something I’ve only used with ServiceStack so there’s a lot about it I don’t know. ElastiCache isn’t multi-zone automatically like RDS. Or taking a step back, what’s the recommended setup for ServiceStack on AWS? As I see we could move to DynamoDB now for sessions and basic cache by the looks of it. Is that better? We also have message queues on Redis, we’d at least like to have fall over to B zone if A goes down. (Don’t want to have to use sticky sessions.)
Nicklas Laine Overgaard:
I’m using http://redislabs.com/ (I’m not affiliated with them), and they provide cheap options for multi-az deployments of Redis, with transparent failover, as you’re just connecting via an URL. Their prices are very competitive with Amazons, and they have options which they claim allows the Redis instances to scale “infinitely” (the Pays-as-you-go pricing tier).
Using them frees your hands to focus on coding, rather than managing Redis 
It does appear
http://redislabs.com/blog/aws-elasticache-now-with-a-dash-of-redis#.U4NSkZRdUnc offers a few advantages over AWS elasticcache, esp. in regards to transparent failover.
The Redis ClientManagers work by iterating over a static list of master(write) and slave(read) IP’s provided at configuration to find a valid connection it can use for read/writes. The RedisClient doesn’t auto promote slaves themselves to master but the clientManagers do offer a FailoverTo() API’s to switch over to the new master/slave IP’s.
Aaron Langley:
Unfortunately it looks like RedisLabs doesn’t provide a multi-AZ service in my region, at least not yet.
Are the redis client managers used by ServiceStack MQ implementation? I’ve a hunch it might not be, so in that case it wouldn’t work for us.
yeah it’s a required argument in the RedisMqServer constructor:
https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack.Server/Messaging/Redis/RedisMqServer.cs#L130