On Tue, Oct 30, 2012 at 7:17 PM, Timo Schoeler
<
timothy....@googlemail.com> wrote:
> Hi,
>
> there's the document
http://redis.io/topics/cluster-spec about Redis Cluster
> specs -- AFAICS there's neither a time stamp, nor any kind of version of
> this document.
>
> As Redis 2.6 was released recently, I'm pretty excited what the current
> state on this issues is?
Hello Timo,
the Redis Cluster specification is not really a "specification" in the
proper strict sense as "get me the specification, I can implement it".
There are a number of holes that must be filled, not much, but the
evil is in the details.
A lot of those unspecified points are actually sometimes *already*
implemented in the unstable branch, other are discussed, and a lot
more will be simply discovered as the implementation gets more
complete / mature.
So what we have *for now* in the unstable branch about Cluster?
1) Gossip to propagate information about the cluster, to link every
node with each other.
2) Gossip to propagate information about what node is responsible for
what hash slot.
3) Redirections. Node can redirect you to the right node if you ask a
question they can't reply to.
4) Atomic keys migration, that is the base of the resharding.
5) Failure detection. It is possible that this will get reworked using
experiences from Sentinel. Sentinel failure detection is probably
better already.
6) The user space tool to manage the cluster is a work in progress,
but can already do a "toy resharding" operation.
So that's the current state, but the good news is, Cluster and
Sentinel will be my main goals in the next months, and I want to bring
Cluster to beta-quality ASAP. I'll focus a lot into it because at this
point with Redis 2.6 we have a project that's pretty mature compared
to the past, and I can't see other big features apart form Sentinel
and Cluster to say, ok, let's block the development of these two
features and get XYZ ready instead. I'm also pretty confident we'll
stick with our single-thread-serves-all design for time to come, and
use Cluster to distribute Redis when there is need to use multiple
cores. Basically this means that in the Redis philosophy the approach
could be "another core or another computer for me is the same". I can
change idea, but *after* I'll see how Cluster will perform in this
regard :-)
Cheers,
Salvatore
--
Salvatore 'antirez' Sanfilippo
open source developer - VMware
http://invece.org
Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
— David Gelernter