5.理想中的Redis5.1 第二代Codis

Codis作者谈到第二代Codis，即Reborndb的发展方向，很值得学习：

“在开源Codis后，我们收到了很多社区的反馈，大多数的意见是集中在Zookeeper的依赖，Redis的修改，还有为啥需要Proxy上面，我们也在思考，这几个东西是不是必须的。当然这几个部件带来的好处毋庸置疑，上面也阐述过了，但是有没有办法能做得更漂亮。于是，我们在下一阶段会再往前走一步，实现以下几个设计：

1）使用proxy内置的Raft来代替外部的Zookeeper，zk对于我们来说，其实只是一个强一致性存储而已，我们其实可以使用Raft来做到同样的事情。将raft嵌入proxy，来同步路由信息。达到减少依赖的效果。

2）抽象存储引擎层，由proxy或者第三方的agent来负责启动和管理存储引擎的生命周期。具体来说，就是现在codis还需要手动的去部署底层的Redis或者qdb，自己配置主从关系什么的，但是未来我们会把这个事情交给一个自动化的agent或者甚至在proxy内部集成存储引擎。这样的好处是我们可以最大程度上的减小Proxy转发的损耗（比如proxy会在本地启动Redis instance）和人工误操作，提升了整个系统的自动化程度。

3）还有replication based migration。众所周知，现在Codis的数据迁移方式是通过修改底层Redis，加入单key的原子迁移命令实现的。这样的好处是实现简单、迁移过程对业务无感知。但是坏处也是很明显，首先就是速度比较慢，而且对Redis有侵入性，还有维护slot信息给Redis带来额外的内存开销。大概对于小key-value为主业务和原生Redis是1:1.5的比例，所以还是比较费内存的。在RebornDB中我们会尝试提供基于复制的迁移方式。

4）QDB：QDB使用LevelDB、RocksDB、GoLevelDB作为后端存储。我们喜欢Redis，并且希望超越它的局限，因此我们创建了一个服务叫做QDB，它兼容Redis，将数据保存在磁盘来越过内存大小的限制并且将热点数据保存在内存中以提高性能。”

除了第三点“基于复制的迁移”，这些改进思路在下面要介绍的Redis商业版(RLEC)中得到了印证。因为RLEC并未透露它的迁移实现方式，所以技术细节我们不得而知。

本文作者：geelou

本文来自云栖社区合作伙伴rediscn，了解相关信息可以关注redis.cn网站。