Codis与RedisCluster的原理详解

一、引言

Codis是一个分布式 Redis 解决方案，可以管理数量巨大的Redis节点。由于发票业务的需要，我们不单单只是需要单机节点，缓存的使用至关重要。为此我们选择了codis来做集群管理。

二、Redis简介

把Redis分为三个部分，分别是客户端、主节点以及从节点，如果从节点要同步主节点的数据，它首先会发Sync指令给主节点，主节点收到指令之后会执行BGSAVE命令生成RDB文件，这个RDB文件指的是快照文件，它是Redis两种备份方式的其中一种，另一种叫AOF，它的原理是将所有的写入指令存入文件，mysql的binlog原理是一样的。

如果主节点在生成RDB的过程当中，客户端发来了写入指令，这个时候主节点会把指令全部写入缓冲区，等RDB生成完了，会把RDB文件发送给从节点，最后再把缓冲区的指令发送给从节点。这样就完成了整个的复制。

只有主从的话在存储大量的数据，BGSAVE指令生成的RDB文件会非常巨大，文件传送给从节点也非常慢，所以需要做集群。

三、Redis常见的集群方案

选择Codis的原因：

随着公司业务规模的快速增长，我们对数据量的存储需求也越来越大，实践表明，在单个Redis的节点实例下，高并发、海量的存储数据很容易使内存出现暴涨。

此外，每一个Redis的节点，其内存也是受限的，主要有以下两个原因：

一是内存过大，在进行数据同步时，全量同步的方式会导致时间过长，从而增加同步失败的风险；

二是越来越多的redis节点将导致后期巨大的维护成本。
Redis集群方案目前主流的有三种，分别是Twemproxy、Codis和Redis Cluster。

因此，我们对Twemproxy、Codis和Redis Cluster 三种主流redis节点管理的解决方案进行了深入调研。

Twemproxy，是推特开源的，它最大的缺点就是无法平滑的扩缩容。而Redis Cluster要求客户端必须支持cluster协议，使用Redis Cluster需要升级客户端，这对很多存量业务是很大的成本。此外，Redis Cluster的p2p方式增加了通信成本，且难以获知集群的当前状态，这无疑增加了运维的工作难度。

而Codis解决了Twemproxy扩缩容的问题，而且兼容了Twemproxy，它是由豌豆荚开源的，和Twemproxy都是代理模式。其实Codis能发展起来的一个主要原因是它是在Redis官方集群方案漏洞百出的时候率先成熟稳定的。以现在的Redis官方集群方案，这两个好像没有太大差别了，不过我也没有去做性能测试，不清楚哪个最好。

Redis Cluster是由官方出品的，用去中心化的方式实现，不属于代理模式，今天主要讲codis，redis cluster后面也会过一下。下面，来看一下Codis的实现原理。

四、Codis介绍

Codis是一个分布式Redis解决方案，对于上层应用来说，连接Codis Proxy和连接原生的Redis Server没有明显的区别，有部分命令不支持；

Codis底层会处理请求的转发、不停机的数据迁移等工作，对于前面的客户端来说，Codis是透明的，可以简单地认为客户端（client）连接的是一个内存无限大的Redis服务。
Codis分为四个部分，分别是：

• Codis Proxy (codis-proxy)

• Codis Dashboard

• Codis Redis (codis-server)

• ZooKeeper/Etcd

五、Codis原理

Sentinel，中文名叫哨兵，它呢，在Redis里面主要负责监控主从节点，如果主节点挂了，就会把从拉起来。但是哨兵本身也存在单点问题，所以它也需要做集群。哨兵是如何做主从切换呢？来看下哨兵的运行机制。

假如有三个哨兵和一主两从的节点，下面是一主多从，哨兵之间会互相监测运行状态，并且会交换一下节点监测的状态，同时哨兵也会监测主从节点的状态。

如果检测到某一个节点没有正常回复，并且距离上次正常回复的时间超过了某个阈值，那么就认为该节点为主观下线。

这个时候其他哨兵也会来监测该节点是不是真的主观下线，如果有足够多数量的哨兵都认为它确实主观下线了，那么它就会被标记为客观下线，这个时候哨兵会找下线节点的从节点，然后与其他哨兵协商出一个从节点做主节点，并将剩余的从节点指向新的主节点。

关于主从节点的切换有两个环节，第一个是哨兵要选举出领头人来负责下线机器的故障转移，第二是从Slave中选出主节点，领头人的选举规则是谁发现客观下线谁就可以马上要求其他哨兵认自己做老大，其他哨兵会无条件接受第一个发过来的人，并告知老大，如果超过一半人都同意了，那他老大的位置就坐实了。

关于从节点选举，一共有四个因素影响选举的结果，分别是断开连接时长、优先级排序、复制数量、进程id，如果连接断开的比较久，超过了某个阈值，就直接失去了选举权，如果拥有选举权，那就看谁的优先级高，这个在配置文件里可以设置，数值越小优先级越高，如果优先级相同，就看谁从master中复制的数据最多，选最多的那个，如果复制数量也相同，就选择进程id最小的那个。

如果有存储海量数据的需求，同步会非常缓慢，所以我们应该把一个主从结构变成多个，把存储的key分摊到各个主从结构中来分担压力。
就像这样，代理通过一种算法把要操作的key经过计算后分配到各个组中，这个过程叫做分片，我们来看一下分片的实现原理。

六、分片算法

在Codis里面，它把所有的key分为1024个槽，每一个槽位都对应了一个分组，具体槽位的分配，可以进行自定义，现在如果有一个key进来，首先要根据CRC32算法，针对key算出32位的哈希值，然后除以1024取余，然后就能算出这个KEY属于哪个槽，然后根据槽与分组的映射关系，就能去对应的分组当中处理数据了。

CRC全称是循环冗余校验，主要在数据存储和通信领域保证数据正确性的校验手段。

我们继续回过来，刚才所讲的槽位和分组的映射关系就保存在codis proxy当中，但是codis proxy它本身也存在单点问题，所以需要对proxy做一个集群。

部署好集群之后，有一个问题，就是槽位的映射关系是保存在proxy里面的，不同proxy之间怎么同步映射关系？

在Codis中使用的是Zookeeper来保存映射关系，由proxy上来同步配置信息，其实它支持的不止zookeeper，还有etcd和本地文件。在zookeeper中保存的数据格式就是这个样子。除了这个还会存储一些其他的信息，比如分组信息、代理信息等，感兴趣可以自己去了解一下。

现在还有一个问题，就是codis proxy如果出现异常怎么处理，这个可能要利用一下k8s中pod的特性，在k8s里面可以设置pod冗余的数量，k8s会严格保证启动的数量与设置一致，所以只需要一个进程监测Proxy的异常，并且把它干掉就可以了，k8s会自动拉起来一个新的proxy。

codis给这个进程起名叫codis-ha，codis-ha实时监测proxy的运行状态，如果有异常就会干掉，它包含了哨兵的功能，所以豌豆荚直接把哨兵去掉了。

但是codis-ha在Codis整个架构中是没有办法直接操作代理和服务，因为所有的代理和服务的操作都要经过dashboard处理。所以部署的时候会利用k8s的亲和性将codis-ha与dashboard部署在同一个节点上。

除了这些，codis自己开发了集群管理界面，集群管理可以通过界面化的方式更方便的管理集群，这个模块叫codis-fe，我们可以看一下这个界面。

最后就是redis客户端了，这个没什么好讲的，客户端是直接通过代理来访问后端服务的。

七、Redis Cluster原理

下面来看一下redis cluster的原理，它和codis不太一样，Codis它是通过代理分片的，但是Redis Cluster是去中心化的没有代理，所以只能通过客户端分片，它分片的槽数跟Codis不太一样，Codis是1024个，而Redis cluster有16384个，槽跟节点的映射关系保存在每个节点上，每个节点每秒钟会ping十次其他几个最久没通信的节点，其他节点也是一样的原理互相PING ，PING的时候一个是判断其他节点有没有问题，另一个是顺便交换一下当前集群的节点信息、包括槽与节点映射的关系等。客户端操作key的时候先通过分片算法算出所属的槽，然后随机找一个服务端请求。

但是可能这个槽并不归随机找的这个节点管，节点如果发现不归自己管，就会返回一个MOVED ERROR通知，引导客户端去正确的节点访问，这个时候客户端就会去正确的节点操作数据。
这是RedisCluster大概的原理，下面看一下Codis跟RedisCluster简要的区别。