Codis作者黄东旭细说分布式Redis架构设计和踩过的那些坑(1)
黄东旭，Ping CAP CTO，开源项目Codis的co-author。之前在豌豆荚从事infrastructure相关的工作，现在在创业公司PingCAP，方向依然是分布式存储领域(NewSQL)。
本次分享的内容主要包括五个大部分：
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其实都是一样的。
二、我们更爱一致性
很多朋友问我，为什么不支持读写分离，其实这个事情的原因很简单，因为我们当时的业务场景不能容忍数据不一致，由于Redis本身的replication模型是主从异步复制，在master上写成功后，在slave上是否能读到这个数据是没有保证的，而让业务方处理一致性的问题还是蛮麻烦的。而且Redis单点的性能还是蛮高的，不像mysql之类的真正的数据库，没有必要为了提升一点点读QPS而让业务方困惑。这和数据库的角色不太一样。所以，你可能看出来了，其实Codis的HA，并不能保证数据完全不丢失，因为是异步复制，所以master挂掉后，如果有没有同步到slave上的数据，此时将slave提升成master后，刚刚写入的还没来得及同步的数据就会丢失。不过在RebornDB中我们会尝试对持久化存储引擎qdb）可能会支持同步复制(syncreplication)，让一些对数据一致性和安全性有更强要求的服务可以使用。
说到一致性，这也是Codis支持的MGET/MSET无法保证原本单点时的原子语义的原因。 因为MSET所参与的key可能分不在不同的机器上，如果需要保证原来的语义，也就是要么一起成功，要么一起失败，这样就是一个分布式事务的问题，对于Redis来说，并没有WAL或者回滚这么一说，所以即使是一个最简单的二阶段提交的策略都很难实现，而且即使实现了，性能也没有保证。所以在Codis中使用MSET/MGET其实和你本地开个多线程SET/GET效果一样，只不过是由服务端打包返回罢了，我们加上这个命令的支持只是为了更好的支持以前用Twemproxy的业务。
在实际场景中，很多朋友使用了lua脚本以扩展Redis的功能，其实Codis这边是支持的，但记住，Codis在涉及这种场景的时候，仅仅是转发而已，它并不保证你的脚本操作的数据是否在正确的节点上。比如，你的脚本里涉及操作多个key，Codis能做的就是将这个脚本分配到参数列表中的第一个key的机器上执行。所以这种场景下，你需要自己保证你的脚本所用到的key分布在同一个机器上，这里可以采用hashtag的方式。
比如你有一个脚本是操作某个用户的多个信息，如uid1age，uid1sex，uid1name形如此类的key，如果你不用hashtag的话，这些key可能会分散在不同的机器上，如果使用了hashtag(用花括号扩住计算hash的区域)：{uid1}age，{uid1}sex，{uid1}name，这样就保证这些key分布在同一个机器上。这个是twemproxy引入的一个语法，我们这边也支持了。
在开源Codis后，我们收到了很多社区的反馈，大多数的意见是集中在Zookeeper的依赖，Redis的修改，还有为啥需要Proxy上面，我们也在思考，这几个东西是不是必须的。当然这几个部件带来的好处毋庸置疑，上面也阐述过了，但是有没有办法能做得更漂亮。于是，我们在下一阶段会再往前走一步，实现以下几个设计：
使用proxy内置的Raft来代替外部的Zookeeper，zk对于我们来说，其实只是一个强一致性存储而已，我们其实可以使用Raft来做到同样的事情。将raft嵌入proxy，来同步路由信息。达到减少依赖的效果。
抽象存储引擎层，由proxy或者第三方的agent来负责启动和管理存储引擎的生命周期。具体来说，就是现在codis还需要手动的去部署底层的Redis或者qdb，自己配置主从关系什么的，但是未来我们会把这个事情交给一个自动化的agent或者甚至在proxy内部集成存储引擎。这样的好处是我们可以最大程度上的减小Proxy转发的损耗比如proxy会在本地启动Redis instance）和人工误操作，提升了整个系统的自动化程度。
还有replication based migration。众所周知，现在Codis的数据迁移方式是通过修改底层Redis，加入单key的原子迁移命令实现的。这样的好处是实现简单、迁移过程对业务无感知。但是坏处也是很明显，首先就是速度比较慢，而且对Redis有侵入性，还有维护slot信息给Redis带来额外的内存开销。大概对于小key-value为主业务和原生Redis是1:1.5的比例，所以还是比较费内存的。
在RebornDB中我们会尝试提供基于复制的迁移方式，也就是开始迁移时，记录某slot的操作，然后在后台开始同步到slave，当slave同步完后，开始将记录的操作回放，回放差不多后，将master的写入停止，追平后修改路由表，将需要迁移的slot切换成新的master，主从半）同步复制，这个之前提到过。
