我们都知道Redis是单机单程序的，在之前的测试中，我们也知道Redis的单机效能是有限的，并且高效能的机器其实非常昂贵。一个好汉三个帮，分散式系统正是利用了多台普通计算器从而被大量互联网公司所使用，今天我们来聊一聊Redis丛集的一种解决方案--Codis。
Codis，Github上面近万star，是一款由中国人开源的Redis丛集解决方案，由前豌豆夹团队提供。Codis，它是一款Redis的Proxy，主要负责把Redis的请求分发到不同的Redis例项当中。
我们从一次get请求来解释一下，Codis是如何工作的。因为Codis代理了Redis服务，所以我们发起请求的时候，并不是请求到Redis-server所在的机器上，而是到Codis机器上，Codis机器再根据一定的路由规则进行分发，最终请求到Redis-Server的机器上，也就是说，如果我们使用一个mget请求，可能会到多台机器上。
很显然，这样子Codis也会存在单点问题，好在Codis是一个无状态的服务，所以我们可以同时部署多个Codis例项。
Codis是如何把对应的key分配到不同机器的呢？奥秘就在于Codis的Slot，Codis切分出1024（可配置）个Slot，每个Slot会系结不同的Redis例项，这里为什么要切分到1024个呢？这是一个不错的思考题？可以从扩容缩容方向进行考虑。
那么不同的Codis实力是如何同步Slot的资料呢？Codis的方法非常简单粗暴，那便是使用ZooKeeper。ZooKeeper不是发现服务么？怎么还能用来储存资料？ZooKeeper其实为每个目录提供了1M的储存空间，通过Quorum的2pc机制来做资料一致性。所以，ZooKeeper可以偷偷用来做资料小，吞吐不是那么大的资料储存。
Codis提供一个Dashboard给使用者编辑Slot的情况，当用户编辑的时候，会由Zookeeper分发给所有的Codis例项。优点
Codis非常的简单，无论是理解上，问题排查上还是部署上，都非常的简单。他把一些分散式一致性的东西交给了另外的开源方案Zookeeper去解决，自身非常轻量级。
缺点
由于Codis的资料是落在多台机器上的，所以，Redis的事务功能就不能使用了，对于批量查询界面，Codis需要到多台机器上去获取结果，这就不能保证资料的一致性。会存在这样的情况，使用Codis同时获取key1与key2，同时Update两者的值，可能获取到的Value1是新版本，而Value2为旧版本。
Codis会对Slot进行资料迁移，如果key-value的资料太小太大的话，就会影响迁移的效率，所以Codis官方推荐Codis的key-value大小不要超过1M。
由于Codis不是Redis的官方专案，所以每当Redis释出新版本的时候，Codis都会瑟瑟发抖，随着Redis退出自己的亲儿子Redis-Cluster，Codis的竞争力都在减弱。
今天我们对Github上面10kstar的Codis就介绍到这里，如果你有兴趣，欢迎关注我，我们后面再继续分析,谈一谈Codis中是如何做资料迁移的。（同名公众号，沙茶敏碎碎念）
（此处已新增圈子卡片，请到今日头条客户端检视）关注我之后回复codis，注意全小写，获取专案github地址。
