Codis的架构设计

最近学习了Codis的源码实现，把一些收获整理一下放在这里。

 

为什么会有Codis？

RedisCluster架构

Codis是怎么做的

Codis架构

 

首先，为什么会有Codis？

Codis是用来管理Redis集群的，那么Codis就是因为Redis而存在的，但是这并不是终极答案，对吧？为什么会有Redis呢？因为这个人。Redis的作者。

 这是一个大帅哥，一点也不像一个程序员屌丝。 他是Redis之父，意大利人，名字读不出来。大家有兴趣可以去搜一下。 Redis的设计也很简单，大家可以花时间来研究一下。

Redis的集群

可能有人会有疑问，Redis应该有自己的集群啊，就像MySql集群一样，既然是一个正式的中间件产品，那么官方也应出品类似的集群。 那么RedisCluster就是这样的东西。

下图是Redis集群的架构的图，RedisCluster是官方的产品，可以看到这个架构是一个平面的。这里的分布式的逻辑和Redis的存储模块是在一起的。 好处是部署简单。 集群的一致性和容错 都由这些节点自己保证。每个Redis集群的节点，负责了很多的功能。

优点是： 

真正的无中心节点，客户端与redis节点直连,不需要中间proxy层.

客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

对于客户端来说请求的性能不会损失太多

缺点是：

分布式逻辑和存储模块耦合

对协议进行了较大的修改，对客户端不太友好

他和Codis也有点像，在集群内部，把所有的Key映射到了16384个Slot中，在客户端访问时，有各个节点，把请求转发。

Codis的架构

这幅图是Codis官方的架构图，个人觉得比较难看，但是也反应了Codis的架构，Codis可以对Redis分组，一个RedisGroup里有一个Master，和多个Slave，Redisclient可以直接访问Proxy。还有一个CodisHA的客户端。但是这幅图有些内容还没有体现出来， 于是我就画了一幅更丑的。

 

Codis的内部，有三个主要的模块， Router，Model，Redis。 Router负责将前端的请求转发给Redis， Model负责和ZK交互，保持数据一致性，这里的数据主要是Group配置，Proxy配置，Slot的配置。Redis模块负责和Redis交互，将前端的命令转发给Redis，并将结果返回。刚才说了Model在负责把Proxy的配置变化发送给ZK， ZK再变化同步到Codisclient。

 

好了，现在切换到这幅图。刚才的那副是Codis的一个骨架， 这里是细化到肉了，这幅图稍微好看点。首先说Router，这里负责和Client通信，建立session，通过Mapper来过滤所有的请求。Slots中封装了Redis的连接。 下面这块Redis封装了Decode和EncodeRedis协议的过程，这里值得提一下，Redis是有自己的标准协议的，在Redis之间的交互，Codis使用的就是标准协议，这块的代码大家有兴趣可以看一下。

Model模块是和ZK交互的对象，负责发送指令给客户端，并解析返回结果。后面也会给大家主要介绍这块内容。

 

Codis除了支持Zk以外还支持ETCD，ETCD也是个牛逼的中间件。ETCD是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，它使用Go语言编写。

 

 

Zookeeper保存的一些配置信息

Proxy

Server

Slot

Slot 是一个逻辑概念，一共 1024 个，使用 crc32(key) % 1024 计算 Slot id，而且一个(或多个) Slot 属于一个 ServerGroup，1024 个 Slot 一起分用多个 ServerGroup 资源；

Action

 

 

 

 

从Codis中可以学习到什么？

 Zookeeper的交互设计  ----- GO

 Redis的交互设计   ------ GO

 Jodis的交互设计  ------ Java

 Go语言本身的设计  —— GO