作者： antirez
注* Antirez是Redis项目的作者和主要维护者，译自其博客有删减； Redis是目前最流行的键值(key-value)数据库，数据集以异步方式从内存同步到硬盘。由于其基于内存特性，性能极好，特别适合应对高并发场合，在NodeJS应用中多用来存储持久化的Session。
我第一次提交有关Redis集群的代码大约在2011年3月29。但我只是合并了别人的一个提交请求：集群分支的历史日志已经不可用了，因为它那一塌糊涂的“正在进行中的”提交，只是为了预留一些API和互动的接口。
现在这个项目已经4岁了。是整个Redis项目历史的三分之二。今天，我准备发布一个Redis3.0.0的候选版（RC），这是正式支持群集的第一个版本。
一个不稳定的运行
为什么花了这么长时间的原因很简单：集群的支持开始的很仓促，在某一天，我突然意识到无法自动扩展的redis，看上去非常地弱。现在并不是开始集群项目的正确时刻，Redis项目本身还非常不成熟，所以到现在还没有一个完全支持“集群”的版本。
为了避免在错误的时间开始一个新的项目所产生的问题，至少我没有办法无视社区里提交的各种问题/请求； 因此该项目被停止， 以将精力集中到更为重要的基本功能上。Persistence（持久化）, replication（复制）, latency（延迟）, introspection（自我恢复）, 这些都比集群的功能更为重要。
该项目的另一个限制是，开始时，我没有任何解决分布式编程的经验。如果我刚开始就开始生产环境的开发，这就太可怕了。真正的“产品”应该是：低延迟，可线性扩展，和开销小。但是，实现的细节上都做错了，它比原来设想的更加复杂，使用的算法也不安全的，还有很多类似的问题。
我开始研究分布式编程的基础知识，虽然做小的进步，重新设计Redis的集群。两个系统中的分布式编程算法仍然非常原始，因为它们是异步的复制，最终达到一致的系统，所以我没有必要处理的同步和其他非琐碎的问题。但是，即使你处理一个简单的问题，但你还需要了解你在做什么，否则你做出的系统可能完全是错误的。
尽管有这些问题，我继续在项目中合作，试图修复它，把它变成熟，这里有两个最为重要的问题：
1）将N个节点之间的数据集分片
2）响应故障转移并在遭遇异常后能继续工作
它（集群）具体是做什么的？
Redis Cluster 基本上是一种数据分段存储策略，让它们有相互访问碎片的能力，在一起工作时又有故障转移能力，确保系统在遭遇异常时能正常工作。
但是从分布式数据库的角度来看，Redis的Cluster提供的分区数量有限，一致性也比较弱。基本上它既不是CP的，也不是AP的系统。换句话说，Redis的集群，并不能达到分布式系统的理论极限，只为了获得一定的真实世界性能。
注* CP/AP系统的概念： CP（一致的，包容的网络分区，但不可用）； AP（容错的网络分区，但不一致）。
我们用“最终一致性”模型来保持一致性，如果节点因为分区的原因而无法同步，当分区恢复时，以确保所有的key获取它的值。
前进的道路
我们最终有了一个最小可用产品（MVP），现在它已经足够稳定了，可以用在生产环境中。越多的采用，完善的空间也就越磊。我从Redis和Sentinel上学到了一点，软件从可用到成熟是一个增量的过程。倾听用户的声音，修复缺陷，测试更多的代码。
同时，我也在开发下一代的Redis Cluster, 改进一些现在还没有添加但很有用的功能，像多数据中心支持，在少数分区中使用回播（commands replay），以使写入更安全。
Redis Cluster RC1 已经开放下载 '3.0.0-rc1'，你可以在 Github或 Redis.io 下载这个版本 http://redis.io/download
内容太少了吧
@郑叮导 #0
有些内容专业性很强，适合直接看原文去理解。