Redis cluster, no longer vaporware
antirez.com
Redis cluster, no longer vaporware
1–10 of 52 posts
Re: Redis cluster, no longer vaporware
#2Can't wait to see it get the Jepsen treatment.
Re: Redis cluster, no longer vaporware
#3Anyone know how AWS clusters Redis?
I had alwas just assumed Redis released this a while ago and that is why AWS started to support Redis along with Memcache in their clustered ElastiCache product
http://aws.amazon.com/about-aws/whats-new/2013/09/04/amazon-...
Re: Redis cluster, no longer vaporware
#4Single-master Redis and replication overhead of current Redis architecture not ideal for getting Redis beyond the "it's a great cache" use case, so I'm been looking forward to this.
Re: Redis cluster, no longer vaporware
#5Anyone know how AWS clusters Redis? I had alwas just assumed Redis released this a while ago and that is why AWS started to support Redis along with Memcache in their clustered ElastiCache product http://aws.amazon.com/about-aws/whats-new/2013/09/04/amazon-...
That's failover -- essentially Redis Sentinel.
Redis Cluster on the other hand orchestrates multiple redis instances to function as one, thereby preventing the need for redis servers that are very large and preventing the need for presharding[1].
[1] http://blog.zawodny.com/2011/02/26/redis-sharding-at-craigsl...
Re: Redis cluster, no longer vaporware
#6Anyone know how AWS clusters Redis? I had alwas just assumed Redis released this a while ago and that is why AWS started to support Redis along with Memcache in their clustered ElastiCache product http://aws.amazon.com/about-aws/whats-new/2013/09/04/amazon-...
I have very little evidence to support this, but they probably use twemproxy. twemproxy is a proxy for redis that automatically manages routing commands to multiple redis servers efficiently.
They definitely don't use redis cluster, because redis cluster requires explicit client-side support. That support is only available in a limited number of clients today.
Re: Redis cluster, no longer vaporware
#7Anyone know how AWS clusters Redis? I had alwas just assumed Redis released this a while ago and that is why AWS started to support Redis along with Memcache in their clustered ElastiCache product http://aws.amazon.com/about-aws/whats-new/2013/09/04/amazon-...
If I remember correctly they only have read replicas. I don't think they even have proper Fail over. You manually have to promote one of the read replicas to master... Feel free to correct me :)
Re: Redis cluster, no longer vaporware
#8Can't wait to see it get the Jepsen treatment.
It won't do well, but at least Antirez is up front about the shortcomings.
The article itself states that Redis Cluster will lose acknowledged writes during partitions (no P), will be eventually consistent (no C), and won't be available during partitions (no A).
Re: Redis cluster, no longer vaporware
#9Anyone know how AWS clusters Redis? I had alwas just assumed Redis released this a while ago and that is why AWS started to support Redis along with Memcache in their clustered ElastiCache product http://aws.amazon.com/about-aws/whats-new/2013/09/04/amazon-...
I have very little evidence to support this, but they probably use twemproxy. twemproxy is a proxy for redis that automatically manages routing commands to multiple redis servers efficiently. They definitely don't use redis cluster, because redis cluster requires explicit client-side support. That support is only available in a limited number of clients today.
Never used it, but as far as I know twemproxy does not support the select command to select another Redis database on the current connection, which would be a good indicator of it being in use at Amazon or not.
Re: Redis cluster, no longer vaporware
#10Can't wait to see it get the Jepsen treatment.
It won't do well, but at least Antirez is up front about the shortcomings. The article itself states that Redis Cluster will lose acknowledged writes during partitions (no P), will be eventually consistent (no C), and won't be available during partitions (no A).
Yep, Jepsen is more suitable to check systems that claim either linerizability, or at least write safety, during partitions. I guess that a modified version of Jepsen could be used in order to validate the failure modes or to discover other unexpected ones that at human inspection look easy to reproduce in actual production environments. Also I don't know if Jepsen is good at this, but in theory it could be instrumented in order to check how good the implementation is, which is, even if it is not designed for write safety during partitions, how better the countermeasures are working?