在大数据的并发场景中，单个Redis实例往往非常困难。 首先出现在内存中。 单个Redis的内存不能太大。 内存太大，rdb文件太大，主从同步时的总量同步时间太长，实例重新启动恢复时也需要很长的数据加载时间。 特别是在云环境中，各个实例的内存经常受到限制。 下面，就CPU的使用率进行说明。 一个Redis实例只能使用一个核心。 用这一个核心完成大量数据的访问和管理工作是非常沉重的负担。 在这样大数据高的同时需求下，Redis集群方案应运而生。 它整合了许多内存小的Redis实例，整合了分布在多台计算机上的许多CPU内核的处理能力，实现了大量的数据存储和高并发读写。 Codis是Redis集群方案之一，我们感到自豪的是，它是中国人开发和开源的，来自前豌豆荚中间件团队。 虽然大多数国内开源项目不太可靠，但Codis非常可靠。 有了Codis技术的积累之后，项目“顶撞人”的精心日记本还开发了中国人自己的开源分布式数据库——TiDB，可以从6飞起来。 从Redis的广泛流行到Redis集群的广泛使用之间存在着多年的差距，Codis就是在这种市场空缺的机遇下发展起来的。 大型企业有明确的Redis在线扩展需求，但市场上没有专门的中间件来实现这一点。
Codis是用Go语言开发的代理中间件，与Redis一样使用Redis协议向外部提供服务。 当客户端向Codis发送指令时，Codis会将指令转发给后续的Redis实例
然后将结果返回给客户机。 所有连接到Codis的Redis实例都配置一个Redis群集，如果群集容量不足，可以通过动态添加Redis实例来实现扩展需求。 客户端操作Codis与操作Redis几乎没有区别。 或者可以使用相同的客户端SDK。 不需要任何变更。 因为Codis是无状态的，所以它只是一个传输代理中间件。 也就是说，可以启动多个Codis实例供客户端使用，并且每个Codis节点是对等的。 由于单个Codis代理可支持的QPS相对有限，启动多个Codis代理可以明显增加整体的QPS需求，还可以发挥灾难恢复功能，断开一个Codis代理也没问题，可以继续服务
Codis瓷砖的原理Codis负责将特定的密钥传输给特定的Redis实例，那么这种对应关系Codis是如何管理的呢？ Codis默认将所有密钥分割为1024个插槽(slot )，首先对从客户端发送来的密钥进行crc32运算，计算哈希值，将散列后的整数值模拟为1024这个整数，得到余数。 其余的是与key对应的槽位。
每个槽位唯一地映射到后续多个Redis实例之一，而Codis则维护内存中槽位和Redis实例的映射关系。 这样，如果有与上述key对应的槽位，应该传输到哪个Redis实例
很清楚。 hash=crc32 (命令密钥)插槽索引=hash 24 redis=slots (插槽索引).redisredis.do )命令插槽数是缺省值如果Codis的槽位映射关系只存储在内存中，则不同的Codis实例之间的槽位关系不会同步。 因此，Codis还需要专门构建的分布式配置存储数据库来持久化时隙位关系。
Codis开始使用ZooKeeper，之后一直支持到etcd。
Codis将槽的位关系保存在zk中，可以提供Dashboard来观察和修改槽的位关系。 当时隙的比特关系发生变化时，Codis Proxy会拦截变化，重新同步时隙的比特关系，从而实现多件事。
在Codis Proxy之间共享相同的时隙比特关系结构。 刚开始扩展的Codis后端只有一个Redis
实例，1024 个槽位全部指向同一个 Redis。然后一个 Redis 实例内存不够了，所以又加了一个 Redis 实例。这时候需要对槽位关系进行调整，将一半的槽位划分到新的节点。这意味着需要对这一半的槽位对应的所有 key 进行迁移，迁移到新的 Redis 实例。
那 Codis 如果找到槽位对应的所有 key 呢？ Codis 对 Redis 进行了改造，增加了 SLOTSSCAN 指令，可以遍历指定 slot 下所有的key。Codis 通过 SLOTSSCAN 扫描出待迁移槽位的所有的 key，然后挨个迁移每个 key 到新的 Redis 节点。在迁移过程中，Codis 还是会接收到新的请求打在当前正在迁移的槽位上，因为当前槽位的数据同时存在于新旧两个槽位中，Codis 如何判断该将请求转发到后面的哪个具体实例呢？Codis 无法判定迁移过程中的 key 究竟在哪个实例中，所以它采用了另一种完全不同的思路。当 Codis 接收到位于正在迁移槽位中的 key 后，会立即强制对当前的单个 key 进行迁移，迁移完成后，再将请求转发到新的 Redis 实例。
slot_index = crc32(command.key) % 1024if slot_index in migrating_slots:do_migrate_key(command.key) # 强制执行迁移redis = slots[slot_index].new_rediselse:redis = slots[slot_index].redisredis.do(command) 我们知道 Redis 支持的所有 Scan 指令都是无法避免重复的，同样 Codis 自定义的SLOTSSCAN 也是一样，但是这并不会影响迁移。因为单个 key 被迁移一次后，在旧实例中它就彻底被删除了，也就不可能会再次被扫描出来了。
自动均衡 Redis 新增实例，手工均衡 slots 太繁琐，所以 Codis 提供了自动均衡功能。自动均衡会在系统比较空闲的时候观察每个 Redis 实例对应的 Slots 数量，如果不平衡，就会自动进行
迁移。Codis 的代价 Codis 给 Redis 带来了扩容的同时，也损失了其它一些特性。因为 Codis 中所有的 key 分散在不同的 Redis 实例中，所以事务就不能再支持了，事务只能在单个 Redis 实例中完成。同样 rename 操作也很危险，它的参数是两个 key，如果这两个 key 在不同的 Redis 实例中，rename 操作是无法正确完成的。Codis 的官方文档中给出了一系列不支持的命令列表。同样为了支持扩容，单个 key 对应的 value 不宜过大，因为集群的迁移的最小单位是key，对于一个 hash 结构，它会一次性使用 hgetall 拉取所有的内容，然后使用 hmset 放置到另一个节点。如果 hash 内部的 kv 太多，可能会带来迁移卡顿。官方建议单个集合结构的总字节容量不要超过 1M。如果我们要放置社交关系数据，例如粉丝列表这种，就需要注意了，可以考虑分桶存储，在业务上作折中。Codis 因为增加了 Proxy 作为中转层，所有在网络开销上要比单个 Redis 大，毕竟数据包多走了一个网络节点，整体在性能上要比单个 Redis 的性能有所下降。但是这部分性能损耗不是太明显，可以通过增加 Proxy 的数量来弥补性能上的不足。Codis 的集群配置中心使用 zk 来实现，意味着在部署上增加了 zk 运维的代价，不过大部分互联网企业内部都有 zk 集群，可以使用现有的 zk 集群使用即可。
Codis 的优点 Codis 在设计上相比 Redis Cluster 官方集群方案要简单很多，因为它将分布式的问题交给了第三方 zk/etcd 去负责，自己就省去了复杂的分布式一致性代码的编写维护工作。而Redis Cluster 的内部实现非常复杂，它为了实现去中心化，混合使用了复杂的 Raft 和Gossip 协议，还有大量的需要调优的配置参数，当集群出现故障时，维护人员往往不知道从何处着手。
MGET 指令的操作过程
mget 指令用于批量获取多个 key 的值，这些 key 可能会分布在多个 Redis 实例中。Codis 的策略是将 key 按照所分配的实例打散分组，然后依次对每个实例调用 mget 方法，最后将结果汇总为一个，再返回给客户端。架构变迁Codis 作为非官方 Redis 集群方案，近几年来它的结构一直在不断变化，一方面当官方的 Redis 有变化的时候它要实时去跟进，另一方面它作为 Redis Cluster 的竞争方案之一，它还得持续提高自己的竞争力，给自己增加更多的官方集群所没有的便捷功能。比如 Codis 有个特色的地方在于强大的 Dashboard 功能，能够便捷地对 Redis 集群进行管理。这是 Redis 官方所欠缺的。另外 Codis 还开发了一个 Codis-fe(federation 联邦) 工具，可以同时对多个 Codis 集群进行管理。在大型企业，Codis 集群往往会有几十个，有这样一个便捷的联邦工具可以降低不少运维成本。
Codis 的尴尬 Codis 不是 Redis 官方项目，这意味着它的命运会无比曲折，它总是要被官方 Redis 牵着牛鼻子走。当 Redis 官方提供了什么功能它欠缺时，Codis 就会感到恐惧，害怕自己被市场甩掉，所以必须实时保持跟进。同时因为 Codis 总是要比 Redis 官方慢一拍，Redis 官方提供的最新功能，Codis 往往要等很久才能同步。比如现在 Redis 已经进入到 4.0 阶段，提供了插件化 Redis-Module 支持，目前 Codis 还没有提供解决方案。现在 Redis-Cluster 在业界已经逐渐流行起来，Codis 能否持续保持竞争力是个问题，我们看到 Codis 在不断的差异化竞争，竞争的方法就体现在工具上，而不是内核，这个和官方的路线真是相反的，官方对工具无暇顾及，只提供基本的工具，其它完全交给第三方去开发。
Codis 的后台管理 后台管理的界面非常友好，使用了最新的 BootStrap 前端框架。比较酷炫的是可以看到实时的 QPS 波动曲线。同时还支持服务器集群管理功能，可以增加分组、增加节点、执行自动均衡等指令，还可以直接查看所有 slot 的状态，每个 slot 被分配到哪个 Redis 实例。