Codis的架构设计

https://blog.csdn.net/shmiluwei/article/details/51958359

最近学习了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