我们都知道Redis是单机单进程的。在之前的测试中，我们也知道Redis的单机性能是有限的，高性能的机器其实是非常昂贵的。一个英雄和三个帮派。分布式系统使用多台普通计算机，被大量互联网公司使用。今天我们就来说说Redis集群的一个解决方案——Codis。Codis，在Github上拥有近万星数，是国人开源的Redis集群解决方案，由原豌豆夹团队提供。Codis，也就是一个RedisProxy，主要负责将Redis请求分发到不同的Redis实例。让我们解释一下Codis是如何从get请求中工作的。因为Codis代理了Redis服务，所以当我们发起请求时，并不是到Redis-server所在的机器，而是到Codis机器，Codis机器按照一定的路由规则进行分发，最后请求到Redis-Server在机器上，也就是说，如果我们使用一个mget请求，它可能会去到多台机器。显然，Codis这种方式也会出现单点问题。好在Codis是无状态服务，所以我们可以同时部署多个Codis实例。Codis是如何将对应的key分发到不同的机器上的？奥秘在于Codis的插槽。Codis拆分出1024个（可配置）Slots，每个Slot绑定不同的Redis实例。为什么要拆分为1024？这是一个值得思考的好问题吗？可以从膨胀和收缩的方向来考虑。那么不同的Codis实力如何同步Slot数据呢？Codis的方法很简单粗暴，就是用ZooKeeper。ZooKeeper不是发现服务吗？它怎么还能用来存储数据呢？ZooKeeper实际上为每个目录提供了1M的存储空间，通过Quorum的2pc机制实现数据的一致性。所以ZooKeeper可以偷偷用于数据量不大，吞吐量不是很大的数据存储。Codis提供了一个Dashboard供用户编辑Slots。当用户编辑时，Zookeeper会分发给所有Codis实例。优点Codis非常简单，无论是理解、排查还是部署，都非常简单。他把一些分布式的一致性问题交给了另一个非常轻量级的开源方案Zookeeper。缺点由于Codis的数据落在多台机器上，无法使用Redis的事务功能。对于批量查询接口，Codis需要从多台机器获取结果，无法保证数据的一致性。会出现这样的情况，用Codis同时获取key1和key2，同时更新两者的值，获取到的Value1可能是新版本，Value2是旧版本。Codis会在Slot上进行数据迁移。key-value数据过小或过大都会影响迁移效率。所以Codis官方建议Codis的key-value大小不要超过1M。由于Codis不是Redis的官方项目，每当Redis发布新版本时，Codis都会颤抖。随着Redis退出自己的儿子Redis-Cluster，Codis的竞争力正在减弱。今天我们在这里介绍了Github上的10kstarCodis。如果你有兴趣，请关注我。后面我们会继续分析，说说Codis是如何进行数据迁移的。
