Codis--分布式redis架构设计

　　Codis是一个分布式Redis解决方案，与官方的纯P2P的模式不同，Codis采用的是Proxy-based的方案。今天我们介绍一下Codis及下一个大版本RebornDB的设计，同时会介绍一些Codis在实际应用场景中的tips。最后抛砖引玉，会介绍一下我对分布式存储的一些观点和看法，望各位首席们雅正(黄旭东)。
一、 Redis，RedisCluster和Codis
　　Redis：想必大家的架构中，Redis已经是一个必不可少的部件，丰富的数据结构和超高的性能以及简单的协议，让Redis能够很好的作为数据库的上游缓存层。但是我们会比较担心Redis的单点问题，单点Redis容量大小总受限于内存，在业务对性能要求比较高的情况下，理想情况下我们希望所有的数据都能在内存里面，不要打到数据库上，所以很自然的就会寻求其他方案。 比如，SSD将内存换成了磁盘，以换取更大的容量。更自然的想法是将Redis变成一个可以水平扩展的分布式缓存服务，在Codis之前，业界只有Twemproxy，但是Twemproxy本身是一个静态的分布式Redis方案，进行扩容/缩容时候对运维要求非常高，而且很难做到平滑的扩缩容。Codis的目标其实就是尽量兼容Twemproxy的基础上，加上数据迁移的功能以实现扩容和缩容，最终替换Twemproxy。从豌豆荚最后上线的结果来看，最后完全替换了Twem，大概2T左右的内存集群。
　　Redis Cluster ：与Codis同期发布正式版的官方cluster，我认为有优点也有缺点，作为架构师，我并不会在生产环境中使用，原因有两个:

• 　　cluster的数据存储模块和分布式的逻辑模块是耦合在一起的，这个带来的好处是部署异常简单，all-in-the-box，没有像Codis那么多概念，组件和依赖。但是带来的缺点是，你很难对业务进行无痛的升级。比如哪天Redis cluster的分布式逻辑出现了比较严重的bug，你该如何升级?除了滚动重启整个集群，没什么好办法。这个比较伤运维。
  
• 　　对协议进行了较大的修改，对客户端不太友好，目前很多客户端已经成为事实标准，而且很多程序已经写好了，让业务方去更换Redisclient，是不太现实的，而且目前很难说有哪个Rediscluster客户端经过了大规模生产环境的验证，从HunanTV开源的Rediscluster proxy上可以看得出这个影响还是蛮大的，否则就会支持使用cluster的client了。
  

　　Codis：和Redis cluster不同的是，Codis采用一层无状态的proxy层，将分布式逻辑写在proxy上，底层的存储引擎还是Redis本身（尽管基于Redis2.8.13上做了一些小patch），数据的分布状态存储于zookeeper(etcd)中，底层的数据存储变成了可插拔的部件。这个事情的好处其实不用多说，就是各个部件是可以动态水平扩展的，尤其无状态的proxy对于动态的负载均衡，还是意义很大的，而且还可以做一些有意思的事情，比如发现一些slot的数据比较冷，可以专门用一个支持持久化存储的server group来负责这部分slot，以节省内存，当这部分数据变热起来时，可以再动态的迁移到内存的server group上，一切对业务透明。比较有意思的是，在Twitter内部弃用Twmeproxy后，t家自己开发了一个新的分布式Redis解决方案，仍然走的是proxy-based路线。不过没有开源出来。可插拔存储引擎这个事情也是Codis的下一代产品RebornDB在做的一件事情。btw，RebornDB和它的持久化引擎都是完全开源的，见https://github.com/reborndb/reborn和https://github.com/reborndb/qdb。当然这样的设计的坏处是，经过了proxy，多了一次网络交互，看上去性能下降了一些，但是记住，我们的proxy是可以动态扩展的，整个服务的QPS并不由单个proxy的性能决定（所以生产环境中我建议使用LVS/HA Proxy或者Jodis），每个proxy其实都是一样的。

　　作者：黄旭东