Redis常见集群方案

Redis常见集群方案

Redis集群方案目前主流的有三种，分别是Twemproxy、Codis和Redis Cluster。

Redis Cluster

Redis Cluster 集群是去中心化通过客户端分片的结构，集群元数据信息分布在每个节点上，主备切换依赖于多个节点协商选主。

Redis cluster有slots 16384个，槽跟节点的映射关系保存在每个节点上，节点之间通过gossip协议交换集群元数据信息。

客户端操作key的时候先通过分片算法算出所属的槽，然后随机找一个服务端请求。可能这个槽并不归随机找的这个节点管，节点如果发现不归自己管，

就会返回一个MOVED ERROR通知，引导客户端去正确的节点访问，这个时候客户端就会去正确的节点操作数据。

Twemproxy

Twemproxy是一种代理分片机制，由Twitter开源。Twemproxy作为代理，可接受来自多个程序Client的访问，在 Twemproxy 也可以部署LVS或者 HAProxy等负载均衡设备。Twemproxy会按照路由规则，转发给后台的各个Redis/Memcache服务器，再原路返回。该方案很好的解决了单个Redis实例承载能力的问题。当然，Twemproxy本身也是单点，需要用Keepalived做高可用方案。通过Twemproxy可以使用多台服务器来水平扩张redis服务，Twemproxy减少后端资源的连接数以及为缓存横向扩展能力。 twemproxy 支持多种 hash 分片算法，同时具备失败节点自动剔除的功能，可以有效的避免单点故障问题。

Twemproxy的开源版本存在几个问题：

• 单线程模型无法利用多核，性能不够好，极端情况下代理和资源需要 1:1 部署；
  配置无法在线 Reload，twitter 内部版本应该是支持的，单元测试里面有针对 reload 的 case，PaaS 场景需要不断更新配置；
• Redis 不支持主从模式（Redis 在作为缓存的场景下确实没必要使用主从），但部分场景需要；
• 数据指标过少，延时指标完全没有、

Codis

• Codis是一个采用Proxy-based方式的分布式Redis解决方案。Codis采用一层无状态的proxy层，将分布式逻辑写在proxy上，底层的存储引擎还是Redis，数据的分布状态存储于zookeeper(etcd)中。
• Codis功能非常全，除了请求转发功能之外，还实现了在线数据迁移、节点扩容缩容、故障自动恢复等功能。
• 在Codis里面，它把所有的key分为1024个槽，每一个槽位都对应了一个分组，具体槽位的分配，可以进行自定义，现在如果有一个key进来，首先要根据CRC32算法，针对key算出32位的哈希值，然后除以1024取余，然后就能算出这个KEY属于哪个槽，然后根据槽与分组的映射关系，就能去对应的分组当中处理数据了

Codis的架构如下：

数据可靠性&高可用&容灾&故障转移

数据可靠性

作为codis的实现来讲，数据高可靠主要是redis本身的能力，通常存储层的数据高可靠，主要是单机数据高可靠+远程数据热备+定期冷备归档实现的。

高可用&容灾&故障转移

codis的架构本身分成proxy集群+redis集群，proxy集群的高可用，可以基于zk或者l5来做故障转移，而redis集群的高可用是借助于redis开源的哨兵集群来实现。proxy 通过监听sentinle集群的+switch-master事件来感知redis 主从切换。

对比

	Codis	Tweproxy	Redis Cluster
集群模式	中心化	中心化	无中心化
使用方式	通过Proxy访问	通过Proxy访问	使用Smart Client直连Redis，Smart Client内置路由规则
性能	有性能损耗	有性能损耗	高
支持的数据库数量	多个	多个	一个
Pipeline	支持	支持	仅支持单个节点Pipeline，不支持跨节点
需升级客户端SDK？	否	否	是
支持在线水平扩容？	支持	不支持	支持
Redis版本	仅支持3.2.8，升级困难	支持最新版	支持最新版
可维护性	组件较多，部署复杂	只有Proxy组件，部署简单	运维简单，官方持续维护
故障自动恢复	需部署哨兵	需部署哨兵	内置哨兵逻辑，无需额外部署