在单个 Redis 的节点实例下，存储的数据量大和高并发的情形下，内存很随意马虎就暴涨。同时，一个 Redis 的节点，内存也是受限的，两个缘故原由，一个是内存过大，在进行数据同步的时候，全量同步的时候会导致韶光过长，会增加同步失落败的风险；另一个缘故原由便是一样平常的 Redis 都是支配在云做事器上的，这个也会受到CPU的利用率的影响。
以是，在面对着大数据量的时候，就会 Redis 集群的方案来管理，同时也是把这么多 Redis 实例的CPU打算能力搜集到一起，从而完成关于大数据和高并发量的的读写操作。
Redis 的集群办理方案有社区的，也有官方的，社区的办理方案有 Codis 和Twemproxy,Codis是由我国的豌豆荚团队开源的，Twemproxy是Twitter团队的开源的；官方的集群办理方案便是 Redis Cluster，这是由 Redis 官方团队来实现的。下面的列表可以很明显地表达出三者的不同点。
很明显codis上风比较大。
02Codis 集群Codis 是一个代理中间件，用的是 GO 措辞开拓的，如下图，Codis 在系统的位置是这样的。
Codis分为四个部分，分别是Codis Proxy (codis-proxy)、Codis Dashboard (codis-config)、Codis Redis (codis-server)和ZooKeeper/Etcd.
Codis便是起着一个中间代理的浸染，能够把所有的Redis实例当成一个来利用，在客户端操作着SDK的时候和操作Redis的时候是一样的，没有差别。
由于Codis是一个无状态的，以是可以增加多个Codis来提升QPS,同时也可以起着容灾的浸染。
03Codis 分片事理在Codis中，Codis会把所有的key分成1024个槽，这1024个槽对应着的便是Redis的集群，这个在Codis中是会在内存中掩护着这1024个槽与Redis实例的映射关系。这个槽是可以配置，可以设置成 2048 或者是4096个。看你的Redis的节点数量有多少，偏多的话，可以设置槽多一些。
Codis中key的分配算法，先是把key进行CRC32 后，得到一个32位的数字，然后再hash%1024后得到一个余数，这个值便是这个key对应着的槽，这槽后面对应着的便是redis的实例。(可以思考一下，为什么Codis很多命令行不支持，例如KEYS操作)
CRC32:CRC本身是“冗余校验码”的意思，CRC32则表示会产生一个32bit（8位十六进制数）的校验值。由于CRC32产生校验值时源数据块的每一个bit（位）都参与了打算，以是数据块中纵然只有一位发生了变革，也会得到不同的CRC32值。
Codis中Key的算法如下
//Codis中Key的算法hash = crc32(command.key)slot_index = hash % 1024redis = slots[slot_index].redisredis.do(command)复制代码
Codis之间的槽位同步
思考一个问题：如果这个Codis节点只在自己的内存里面掩护着槽位与实例的关系,那么它的槽位信息怎么在多个实例间同步呢？
Codis把这个事情交给了ZooKeeper来管理，当Codis的Codis Dashbord 改变槽位的信息的时候，其他的Codis节点会监听到ZooKeeper的槽位变革，会及时同步过来。如图：
04Codis中的扩容
思考一个问题：在Codis中增加了Redis节点后,槽位的信息怎么变革，原来的key怎么迁移和分配？如果在扩容的时候，这个时候有新的key进来，Codis的处理策略是怎么样的？
由于Codis是一个代理中间件，以是这个当须要扩容Redis实例的时候，可以直接增加redis节点。在槽位分配的时候，可以手动指定Codis Dashbord来为新增的节点来分配特定的槽位。
在Codis中实现了自定义的扫描指令SLOTSSCAN，可以扫描指定的slot下的所有的key，将这些key迁移到新的Redis的节点中(话外语：这个是Codis定制化的个中一个好处)。
首先，在迁移的时候，会在原来的Redis节点和新的Redis里都保存着迁移的槽位信息，在迁移的过程中，如果有key打进将要迁移或者正在迁移的旧槽位的时候，这个时候Codis的处理机制是，先是将这个key逼迫迁移到新的Redis节点中，然后再见告Codis,下次如果有新的key的打在这个槽位中的话，那么转发到新的节点。代码策略如下：
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)复制代码05Codis的捐躯
由于Codis在Redis的根本上的改造，以是在Codis上是不支持事务的，同时也会有一些命令行不支持，在官方的文档上有(Codis不支持的命令)
官方的建议是单个凑集的总容量不要超过1M,否则在迁移的时候会有卡顿感。在Codis中，增加了proxy来当中转层，以是在网络开销上，是会比单个的Redis节点的性能有所低落的，以是这部分会有些的性能花费。可以增加proxy的数量来避免掉这块的性能损耗。
06MGET的过程思考一个问题：如果熟习Redis中的MGET、MSET和MSETNX命令的话，就会知道这三个命令都是原子性的命令。但是，为什么Codis支持MGET和MSET,却不支持MSETNX命令呢？
缘故原由如下: 在Codis中的MGET命令的事理是这样的，先是在Redis中的各个实例里获取到符合的key，然后再汇总到Codis中，如果是MSETNX的话，由于key可能存在在多个Redis的实例中，如果某个实例的设值成功，而另一个实例的设值不堪利，从实质上讲这是不堪利的，但是分布在多个实例中的Redis是没有回滚机制的，以是会产生脏数据，以是MSETNX便是不能支持了。
总结Codis是一个代理中间件，通过内存保存着槽位和实例节点之间的映射关系,槽位间的信息同步交给ZooKeeper来管理。个中不支持事务和官方的某些命令，缘故原由便是分布多个的Redis实例没有回滚机制和WAL,所以是不支持的。
后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~
