Redis集群的三种方式

1.Why 集群？

当前各家互联网公司为了提高站点响应速度，使用缓存工具将热点数据保存在内存中，避免直接从后端数据库读取查询，降低后端压力。其中常见的cache工具有memcache和redis，相较于memcache，redis有着许多优势，这里不再赘述。
在大型站点应用中，热点数据几十上百G也很普遍，而无论是物理机、云主机（虚拟机），内存资源往往是有限的，虽然目前硬件成本降低，几十G几十核的主机也很常见，但是对于redis这种工作进程为单线程模式的工具来说，一台主机只运行一个实例就有些浪费，且出现单点故障时影响范围很大。同时，redis管理大内存时不如管理相对较小的内存高效，据第三方测试，redis单进程内存分配达到20G后性能急剧下降，因此普遍使用的方式为单进程分配8G内存，单主机开启多个redis instance.

2.How 集群？

⑴.Redis官方集群方案 Redis Cluster（服务端sharding）
Redis cluster是一种在服务端sharding（分片）的技术，在redis3.0版本开始正式提供。
Redis cluster的服务端sharding引入了slot（槽）的概念，一共分为16384（2^14）个slot，集群中的每个node节点负责分摊这些slot，每个进入redis的键值对，根据key进行hash运算，除以16384取模，匹配相应的slot，再分配进相应的node中的实例中。在redis cluster方案中，数据储存的粒度由原来的instance再次精细为slot。
Redis cluster提供一种叫做cluster bus（集群总线）的功能特性，采用特殊的二进制协议，通信及响应速度极快。它提供节点故障检测、故障转移、新节点识别等节点管理功能，该功能的进程间通信端口号为服务端口号值+10000，例如redis对外提供服务的端口号为6555，则cluster bus的端口号则为16555。
值得注意的是：redis cluster是官方在3.0以后的版本才正式推出的，虽然目前社区内比较活跃，但是成熟的生产案例还不多，需要时间考验。

优势：
在于服务端Redis集群拓扑结构变化时，客户端不需要感知，客户端像使用单Redis服务器一样使用Redis集群，运维管理也比较方便。

不过Redis Cluster正式版推出时间不长，系统稳定性、性能等都需要时间检验，尤其在大规模使用场合。

⑵.redis sharding 集群（客户端sharding）
Redis 3.0服务端sharding推出之前，采用的较普遍的client端集群方式，工作逻辑为：将键值对中的key使用hash算法散列，特定的key映射至特定的redis 实例上，然后由client端主动向该node set/get数据，server端则工作在被动模式。
目前java redis的客户端驱动jedis已经支持redis sharding的功能。

但是Redis sharding面临的问题：扩容。在client端sharding模式下，数据控制完全由client端掌控，redis集群各node间彼此独立，因此在扩容（或缩容）时，数据无法直接从原node转向新node，这时会造成缓存无法命中的问题，查询/写入请求会透过缓存层直接访问后端DB，给后端带来较大的压力，为了避免这个问题，官方给出了比较讨巧的解决方案：presharding。

优势：
服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。

缺点：
由于sharding处理放到客户端，规模进步扩大时给运维带来挑战。
服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。
连接不能共享，当应用规模增大时，资源浪费制约优化。

⑶.代理中间件sharding

上面分别介绍了多Redis服务器集群的两种方式，它们是基于客户端sharding的Redis Sharding和基于服务端sharding的Redis Cluster。

twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后(如sharding)，再转发给后端真正的Redis服务器。也就是说，客户端不直接访问Redis服务器，而是通过twemproxy代理中间件间接访问。twemproxy中间件的内部处理是无状态的，它本身可以很轻松地做LB/HA集群，这样可避免单点压力或故障。twemproxy又叫nutcracker，起源于twitter系统中redis/memcached集群开发实践，运行效果良好，后代码奉献给开源社区。其轻量高效，采用C语言开发。

GitHub link：
(https://github.com/twitter/twemproxy)

twemproxy后端不仅支持redis，同时也支持memcached，这是twitter系统具体环境造成的。由于使用了中间件，twemproxy可以通过共享与后端系统的连接，降低客户端直接连接后端服务器的连接数量。同时，它也提供sharding功能，支持后端服务器集群水平扩展。统一运维管理也带来了方便。当然，也是由于使用了中间件代理，相比客户端直连服务器方式，性能上会有所损耗，Twitter官方实测结果大约降低了20%左右，不过性能的部分损耗可以依靠增加集群节点数量来弥补。

结构图：

image.png

3.Twemproxy

Twemproxy介绍

Twemproxy 也叫 nutcraker。是 Twtter 开源的一个 Redis 和 Memcache 代理服务器，主要用于管理 Redis 和 Memcached 集群，减少与Cache 服务器直接连接的数量。

Twemproxy特性：

轻量级、快速

保持长连接

减少了直接与缓存服务器连接的连接数量

使用 pipelining 处理请求和响应

支持代理到多台服务器上

同时支持多个服务器池

自动分片数据到多个服务器上

实现完整的 memcached 的 ASCII 和再分配协议

通过 yaml 文件配置服务器池

支持多个哈希模式，包括一致性哈希和分布

能够配置删除故障节点

可以通过端口监控状态

支持 linux, *bsd,os x 和 solaris

Twemproxy安装配置参考官网： https://github.com/twitter/twemproxy 或

主要解决问题和缺点

其功能：

通过代理的方式减少缓存服务器的连接数。

自动在多台缓存服务器间共享数据。

通过不同的策略与散列函数支持一致性散列。

通过配置的方式禁用失败的结点。

运行在多个实例上，客户端可以连接到首个可用的代理服务器。

支持请求的流式与批处理，因而能够降低来回的消耗。

其缺点：

不支持针对多个值的操作，比如取sets的子交并补等。

不支持Redis的事务操作。

错误消息、日志信息匮乏，排查问题困难。

测试结论

功能

前端使用 Twemproxy 做代理，后端的 Redis 数据能基本上根据 key 来进行比较均衡的分布。

后端一台 Redis 挂掉后，Twemproxy 能够自动摘除。恢复后，Twemproxy 能够自动识别、恢复并重新加入到 Redis 组中重新使用。

Redis 挂掉后，后端数据是否丢失依据 Redis 本身的策略配置，与 Twemproxy 基本无关。

如果要新增加一台 Redis，Twemproxy 需要重启才能生效；并且数据不会自动重新 Reblance，需要人工单独写脚本来实现。

如同时部署多个 Twemproxy，配置文件一致（测试配置为 distribution ：ketama,modula），则可以从任意一个读取，都可以正确读取 key对应的值。

多台 Twemproxy 配置一样，客户端分别连接多台 Twemproxy可以在一定条件下提高性能。根据 Server 数量，提高比例在 110-150%之间。

如原来已经有 2 个节点 Redis，后续有增加 2 个 Redis，则数据分布计算与原来的 Redis 分布无关，现有数据如果需要分布均匀的话，需要人工单独处理。

如果 Twemproxy 的后端节点数量发生变化，Twemproxy 相同算法的前提下， 原来的数据必须重新处理分布，否则会存在找不到key值的情况 。

性能

不管 Twemproxy 后端有几台 Redis，前端的单个 Twemproxy 的性能最大也只能和单台 Redis 性能差不多。

总的来说，Twemproxy能实现Redis集群的分片和主备，性能还和单机差不多；

参考
https://blog.csdn.net/ywq935/article/details/77720441
https://www.jianshu.com/p/453205bc2d62