此前的文章中,我们介绍了三种 redis 集群和搭建方法。 redis 集群详解及搭建过程
事实上,第三种 redis 原生的 redis-cluster 同时具备了前两种的特性,既能够实现主备也能够实现故障时的自动选举和切换,因此通常在生产环境中会直接使用 redis-cluster 的方案。 但是原生的 redis-cluster 存在 MOVED 和 ASK 转向。 Redis 的 MOVED 转向与 ASK 转向
MOVED 转向与 ASK 转向必须由客户端进行处理,而为了增加系统性能,客户端必须维护路由表,这无疑增加了客户端的开发难度。 业务中也需要考虑使用非集群客户端还是使用支持集群功能的客户端,这对业务开发来说也在很大程度上增加了复杂度,尤其是在不同环境需要切换非集群与集群的场景下,这都是业务开发不愿意面对的。 而另一方面,MOVED 转向与 ASK 转向的存在意味着,集群中的每个节点都必须暴露给客户端,这通常不是我们希望看到的。 同时,redis-cluster 还限制我们只能使用 0 号数据库。 上述这些问题让很多人觉得抓狂,但事实上,生产环境中还有另外两种 redis 集群管理方式可以供我们选择 — Twemproxy 与 Codis。
temproxy 是 twitter 公司开发的一套后端缓存代理,他通过代理实现数据分片,而后端依赖于原生的 redis 节点与 redis-sentinel,由于原生的 redis 节点与 redis-sentinel 组成的集群没有了上述 redis-cluster 的诸多限制,让我们可以十分方便的使用。
Twemproxy 搭建 redis 集群有以下的优势:
Twemproxy 也有着明显的缺点:
Codis 是由豌豆荚于2014年11月开源的 redis 集群解决方案,他针对 Twemproxy 上述弱点,实现了一套。 他通过使用 go 和 C 语言在 redis 源码基础上二次开发,实现了 redis 分布式、高可用集群的实现,在 value 长度低于 888 字节的情况下,性能优于 Twemproxy 一倍左右。
Codis引入了Group的概念,每个Group包括1个Redis Master及至少1个Redis Slave。 同时,Codis 提供了一套运营监控界面,运维人员可通过Dashboard“自助式”地进行主从切换。 与 redis-cluster 一样,Codis 也采用预分片的机制,整个集群分成 1024 个 slot,由 Zookeeper 维护分片路由表,最新版本的 codis-3.2 允许自定义分片路由表存储方式。
Codis 有着以下优点:
除此以外,Codis 还提供了从 Twemproxy 到 Codis 的一键迁移工具。 目前来说,国内对 Codis 的使用非常普遍,也是对其优点的群众认可吧。
Codis 也具有以下明显的缺点:
https://github.com/CodisLabs/codis/blob/release3.2/doc/tutorial_zh.md。