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

1 收藏


直接登录