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组件，部署简单 | 运维简单，官方持续维护 |
| 故障自动恢复 | 需部署哨兵 | 需部署哨兵 | 内置哨兵逻辑，无需额外部署 |
