单个redis实例无论是存储容量还是请求处理能力最后都会受限于单机的性能，随着数据量和请求量的增长，必然要寻求redis集群的解决方案。在redis推出早期，redis自身并没有集群的方案，但是业界在使用redis的时候有不少集群方案。到了redis 3.0，redis内建了集群方案，称之为redis cluster。集群设计核心是将众多的key分散存放到多个不同的实例上去，另外要考虑的问题就是高可用以及可扩展。
为了实现集群的功能，从服务端、客户端的角度来看，可以分为以下三类：
- 客户端实现： 典型的是支持一致性哈希的客户端
- 代理层实现： 典型代表twemproxy、codis
- redis服务端实现： redis cluster
客户端实现redis集群
在客户端实现redis集群，通常的使用场景是把redis单纯当作简单的缓存来使用，就像使用memcache那样使用redis。一般的策略是使用一致性哈希。实际应用中，在客户端实现redis集群功能并不是一个好方案，它存在维护管理困难的问题，当需要这么做时请考虑在代理层做。
代理层实现redis集群
在redis 3.0推出redis cluster之前，代理层实现redis集群是首选方案，twemproxy和codis是最常见的两个代理。
twemproxy实现redis集群
twemproxy实现redis集群的方案主要通过twemproxy配置里的distribution来控制的，不同的distribution可以适用于不同的场景，比较如下：
| 项目 | ketama | modula | random |
|---|---|---|---|
| KEY分布 | 一致性哈希方式将key分布到不同的redis实例上 | 通过对key的哈希值求模分布到相应的redis实例上 | 随机分布key |
| 高可用 | 可以通过开启自动屏蔽失效节点来自动更新一致性哈希环，从而实现依赖一致性哈希的高可用 | 内建没有对高可用的支持，可以通过外部控制在有节点失效时更新配置并重启 | 开启自动屏蔽失效节点功能，或同modula |
| 可扩展 | 直接添加redis节点重启代理即可 | 只能双倍扩容，数据同步过程中需要重启twemproxy，重启过程中可能丢失一点最新的数据，扩容后各redis实例里会残留垃圾数据，如果未设置超时时间的话需要手工清理 | 直接添加redis节点重启代理即可 |
| 适用场景 | 缓存使用 | 缓存或存储使用 | 队列使用，较少使用 |
| 问题 | 一致性哈希虽然既可以实现高可用也可以实现可扩展，但实际上这两点做的都不够好，在一致性哈希环改变的时候会造成短期的缓存命中率下降，在大量请求的情况下这可能是不可接受的，有可能瞬间把后端数据库击垮;在网络抖动情况下，哈希环可能持续多次改变，这可能会带来脏数据的问题;在有多个代理的时候，还可能因为种种原因导致各代理上哈希环不一致的问题。 | 高可用需要额外依赖其它组件来实现，可扩展问题上面已提出 | 较少使用 |
codis实现redis集群
与twemproxy不一样，codis不单纯是一款代理软件，它包括了好几个组件，不过在这里我们不细讲，只介绍其实现redis集群的基本原理。两个主要的组件是codis-server（redis修改版本）和codis-proxy，codis在逻辑上划分出1024个slot，每个codis-server实例可以拥有多个slot，而key则通过计算哈希值来求模分布到这1024个slot中，codis-proxy知道每个slot位于哪个codis-server里。对高可用的支持codis依赖redis-sentinel，而对可扩展的支持是通过迁移slot到新的codis-server实例上来实现的。
redis cluster
redis cluster原理上和codis差不多，同样是引入了slot的概念，不过redis cluster有16384个slot。redis cluster自身集成了高可用的功能，可扩展也是通过迁移slot来实现的。但是对客户端来说，redis cluster和单个redis实例相比它在请求响应上带来了MOVE/ASK语义，也就意味着之前的redis客户端无法直接获得全部集群功能，需要增加对MOVE/ASK响应的支持才可以访问整个集群。
为了让客户端透明的访问redis cluster，可以在中间加一层代理，predixy是一个不错的选择
方案选择
基于客户端的方案任何时候都要慎重考虑，在此我们不予推荐。
基于twemproxy的方案虽然看起来功能挺全面，但是实际使用中存在的问题同样很多，具体见上述，目前也不推荐再用twemproxy的方案。
codis在redis cluster出来之前应该是最理想的一种redis集群解决方案，但是codis需要采用其自身修改版的redis，因此这和redis社区版本会有差异，因此无法及时跟进redis社区版本更新，而对于那些自己对redis有所改动的用户来讲，那更不便使用codis。同时codis-proxy是go语言编写，在性能方面，尤其是耗时表现损耗较多。
redis cluster自redis 3.0推出以来，目前已经在很多生产环境上得到了应用，目前来讲，构建redis集群，推荐采用redis cluster搭配一款支持redis cluster的代理方案。