构建高可用、可扩展的redis集群

单个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的代理方案。