Spark生态系统解析及基于Redis的开源分布式服务Codis

Codis

　　既然重新设计，那么Codis首先必须满足自动扩容和缩容的需求，其次则是必须避免单点故障和单点带宽不足，做一个高可用的系统。在这之后，基于原有的遗留系统，还必须可以轻松地将数据从Twemproxy迁移到Codis，并实现良好的运维和监控。基于这些，Codis的设计跃然纸面：

　　然而，一个新系统的开发并不是件容易的事情，特别是一个复杂的分布式系统。刘奇表示，虽然当时团队只有3个人，但是他们几乎考量了可以考量的各种细节：

• 尽量拆分，简化每个模块，同时易于升级
• 每个组件只负责自己的事情
• Redis只作为存储引擎
• Proxy的状态
• Redis故障判定是否放到外部，因为分布式系统存活的判定异常复杂
• 提供API让外部调用，当Redis Master丢失时，提升Slave为Master
• 图形化监控一切：slot状态、Proxy状态、group状态、lock、action等等

　　而在考量了一切事情后，另一个争论摆在了眼前——Proxy或者是Smart Client：Proxy拥有更好的监控和控制，同时其后端信息亦不易暴露，易于升级；而Smart Client拥有更好的性能，及更低的延时，但是升级起来却比较麻烦。对比种种优劣，他们最终选择了Proxy，无独有偶，在codis开源后，twitter的一个分享提到他们也是基于proxy的设计。

Codis主要包含Codis Proxy（codis-proxy）、Codis Manager（codis-config）、Codis Redis（codis-server）和ZooKeeper四大组件，每个部分都可动态扩容。

codis-proxy 。客户端连接的Redis代理服务，本身实现了Redis协议，表现很像原生的Redis （就像 Twemproxy）。一个业务可以部署多个 codis-proxy，其本身是无状态的。

codis-config。Codis 的管理工具，支持添加/删除Redis节点、添加/删除Proxy节点、发起数据迁移等操作。codis-config自带了一个http server，会启动一个dashboard，用户可以在浏览器上观察 Codis 集群的运行状态。

codis-server。Codis 项目维护的一个Redis分支，加入了slot的支持和原子的数据迁移指令。

ZooKeeper。Codis依赖ZooKeeper来存放数据路由表和codis-proxy节点的元信息，codis-config发起的命令会通过 ZooKeeper同步到各个存活的codis-proxy。

　　最后，刘奇还介绍详细的了Codis中Migration、lock (rwlock)等操作的实现过程和原理，以及从Twemproxy迁移到Codis的详细操作。更多Codis详情可移步Clodis开源页 GitHub。