Redis集群,不再雾里看花


发布者 ourjs  发布时间 1413188719719
关键字 行业动态  开源  Redis  OnceDB 
作者: 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




回复 (2)
  • #
  • #1 郑叮导 1413204221962

    内容太少了吧

  • #2 ourjs 1413206806366

    @郑叮导 #0

    有些内容专业性很强,适合直接看原文去理解。

微信扫码 立即评论