Redis集群的分析

　  Redis是目前最流行的键值(key-value)数据库，以异步方式数据集从内存同步至硬盘。由于Redis基于内存特性，所以性能极好，特别适合应对高并发场合，在NodeJS应用中多用来存储持久化的Session。

　　大约在2011年3月29我第一次提交有关Redis集群的代码。但是我只合并了别人的一个提交请求：集群分支的历史日志已经不可用了，因为它那一塌糊涂的“正在进行中的”提交，只是为了预留一些API与互动的接口。

　　现在这个项目已经4岁了。是整个Redis项目历史的三分之二。今天，我准备发布一个Redis3.0.0的候选版(RC)，这是正式支持群集的第一个版本。

　　一、一个不稳定的运行

　　为什么花了这么长时间？原因很简单：集群的支持开始的很仓促，在某一天，我意识到无法自动扩展的redis，看上去其实非常地弱，不能比mysql。现在并不是开始集群项目的正确时刻，而且Redis项目本身还非常不成熟，所以到现在还没有一个完全支持“集群”的版本。

　　为了避免在错误的时间开始一个新的项目所产生的问题，至少我没有办法无视社区里提交的各种问题/请求; 所以该项目被停止， 以将精力集中到更为重要的基本功能上。

•   Persistence(持久化)
•   replication(复制)
•   latency(延迟)
•   introspection(自我恢复)

   这些都比集群的功能更为重要。

　　该项目的另一个限制是，在刚开始时，我没有任何解决分布式编程的经验。如果我刚开始就开始生产环境的开发，这就太可怕了。真正的“产品”应该是：低延迟，可线性扩展，开销小。但是，实现的细节上都做错了，它比原来设想的更加复杂，使用的算法也不安全的，还有很多类似的问题。

　　我开始研究分布式编程的基础知识，虽然有小的进步，重新设计Redis的集群。两个系统中的分布式编程算法仍然非常原始，因为它们是异步的复制，最终达到一致的系统，所以我没有必要处理的同步与其他非琐碎的问题。但是，即使你处理一个简单的问题，但是你还需要了解你在做什么，否则你做出的系统可能完全是错误的。

　　尽管有这些问题，我继续在项目中合作，试图修复它，把它变成熟，这里有两个最为重要的问题：

1. 　　将N个节点之间的数据集分片
2. 　　响应故障转移并在遭遇异常后能继续工作

　　二、它(集群)具体是做什么的?

　　Redis Cluster 基本上是一种数据分段存储策略，让它们有相互访问碎片的能力，当在一起工作时又有故障转移能力，确保系统在遭遇异常时能正常工作。

　　但从分布式数据库的角度来看，Redis的Cluster提供的分区数量有限，一致性也比较弱。基本上它既不是CP的，也不是AP的系统。换句话说，Redis的集群，并不能达到分布式系统的理论极限，只为了获得一定的真实世界性能。

　　说明： CP/AP系统的概念： CP(一致的，包容的网络分区，但不可用); AP(容错的网络分区，但不一致)。

　　我们用“最终一致性”模型来保持一致性，如果节点因为分区的原因而无法同步，当分区恢复时，以确保所有的key获取它的值。

　　三、前进的道路

　　我们最终有了一个最小可用产品(MVP)，现在它已经足够稳定了，可以用在生产环境中。越多的采用，完善的空间也就越好。我从Redis与mysql上学到了一点，软件从可用到成熟是一个增量的过程。倾听用户的声音，修复缺陷，测试更多的代码。

　　同时，我也在开发下一代的Redis Cluster, 改进一些现在还没有添加但很有用的功能，像多数据中心支持，在少数分区中使用回播(commands replay)，以使写入更安全。

　　Redis Cluster RC1 已经开放下载 '3.0.0-rc1'，你可以在 Github或者 Redis.io 下载这个版本http://redis.io/download