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
参考资料
ZooKeeper开发手册
http://my.oschina.net/sundiontheway/blog/346498
作者访谈
http://www.open-open.com/lib/view/open1436360508098.html
codis 源码理解
http://www.nosa.me/2016/02/21/codis-%E6%BA%90%E7%A0%81%E7%90%86%E8%A7%A3/
Codis性能结果
https://github.com/CodisLabs/codis/blob/master/doc/benchmark.md