基于 Twemproxy 与 Codis 的 redis 集群方案比较

1. 引言

此前的文章中，我们介绍了三种 redis 集群和搭建方法。 redis 集群详解及搭建过程

事实上，第三种 redis 原生的 redis-cluster 同时具备了前两种的特性，既能够实现主备也能够实现故障时的自动选举和切换，因此通常在生产环境中会直接使用 redis-cluster 的方案。 但是原生的 redis-cluster 存在 MOVED 和 ASK 转向。 Redis 的 MOVED 转向与 ASK 转向

MOVED 转向与 ASK 转向必须由客户端进行处理，而为了增加系统性能，客户端必须维护路由表，这无疑增加了客户端的开发难度。 业务中也需要考虑使用非集群客户端还是使用支持集群功能的客户端，这对业务开发来说也在很大程度上增加了复杂度，尤其是在不同环境需要切换非集群与集群的场景下，这都是业务开发不愿意面对的。 而另一方面，MOVED 转向与 ASK 转向的存在意味着，集群中的每个节点都必须暴露给客户端，这通常不是我们希望看到的。 同时，redis-cluster 还限制我们只能使用 0 号数据库。 上述这些问题让很多人觉得抓狂，但事实上，生产环境中还有另外两种 redis 集群管理方式可以供我们选择 — Twemproxy 与 Codis。

2. Temproxy

temproxy 是 twitter 公司开发的一套后端缓存代理，他通过代理实现数据分片，而后端依赖于原生的 redis 节点与 redis-sentinel，由于原生的 redis 节点与 redis-sentinel 组成的集群没有了上述 redis-cluster 的诸多限制，让我们可以十分方便的使用。

2.1. Twemproxy 的特性

Twemproxy 搭建 redis 集群有以下的优势：

1. 快速 — 据测试，直连 twenproxy 和直连 redis 相比几乎没有性能损失，读写分离后更是能够极大地提高集群响应能力
2. 轻量级 — Twemproxy 通过透明连接池、内存零拷贝以及 epoll 模型实现了足够的快速和轻量化，源码较为简洁精炼
3. 降低负载 — 透明连接池保持前端的连接数，减少后端的连接数，让后端的 redis 节点负载大为降低
4. 分片 — Twemproxy 通过一致性 hash 算法将数据进行分片，从而实现 redis 集群的高速缓存，降低负载
5. 多协议 — 同时支持 redis 与 memcache 集群的搭建
6. 多算法 — 支持多种算法实现一致性哈希分片，包括crc32，crc16，MD5等
7. 配置简单
8. 监控报警丰富 — 虽然他提供的原生监控功能一般较少使用，但其提供的统计信息，如发送了多少读写命令还是有很大的价值的

2.2. Twemproxy 的缺点

Twemproxy 也有着明显的缺点：

1. 单点 — Twemproxy 只实现了静态分片的功能，本身不具备集群功能，但可以通过 keepalive 来解决
2. 运维不友好 — 没有提供控制面板
3. 无法平滑地扩容/缩容 — 这是一个非常大的缺陷，虽然我们可以通过技术手段和方案来尽量避免，但对于运维人员来说仍然是有很大压力的

3. Codis

Codis 是由豌豆荚于2014年11月开源的 redis 集群解决方案，他针对 Twemproxy 上述弱点，实现了一套。 他通过使用 go 和 C 语言在 redis 源码基础上二次开发，实现了 redis 分布式、高可用集群的实现，在 value 长度低于 888 字节的情况下，性能优于 Twemproxy 一倍左右。

3.1. Codis 的架构

Codis引入了Group的概念，每个Group包括1个Redis Master及至少1个Redis Slave。 同时，Codis 提供了一套运营监控界面，运维人员可通过Dashboard“自助式”地进行主从切换。 与 redis-cluster 一样，Codis 也采用预分片的机制，整个集群分成 1024 个 slot，由 Zookeeper 维护分片路由表，最新版本的 codis-3.2 允许自定义分片路由表存储方式。

3.2. Codis 的优势

Codis 有着以下优点：

1. 数据热迁移 — 这是 Redis 最大的优势，这也是他被广为使用的最大原因，
2. 运维界面友好 — 提供 slot状态、Proxy状态、group状态、lock、action 等的丰富监控和显示
3. 故障处理灵活 — 本身只监控和报告故障，提供 API 对故障进行处理，从而让运维能够实现灵活的故障处理方案
4. 架构清晰 — 如上图所示，整个架构清晰，组件高度内聚，故障的发现和处理变得更为容易

除此以外，Codis 还提供了从 Twemproxy 到 Codis 的一键迁移工具。 目前来说，国内对 Codis 的使用非常普遍，也是对其优点的群众认可吧。

3.3. Codis 的缺点

Codis 也具有以下明显的缺点：

1. 版本滞后 — 因为在 redis 源码基础上进行二次开发，所以很难跟上最新版 redis 的脚步，目前最新的 Codis-3.2 基于 Redis-3.2.8 版本
2. 部署复杂 — 部署过程至少要进行 codis-dashboard、codis-proxy、codis-server、codis-fe 四个组件的部署和启动
3. 单节点性能低 — 如果仅有一个 codis-server，性能低于原生 redis 20% 左右
4. 更新频率低

4. 参考资料

https://github.com/CodisLabs/codis/blob/release3.2/doc/tutorial_zh.md。