一、Redis-cluster
针对单节点Redis出现的扩容等问题，Redis官方在Redis3.0版本时推出了Redis集群模式，集群模式主要有以下4个特点：
1、redis cluster 采用无中心结构，每个节点都保存数据和整个集群的状态；
2、节点之间使用GOSSIP协议彼此互联（PING-PONG机制），这些连接保持活跃，内部使用二进制协议优化传输速度和带宽；
3、节点的fail是通过集群中超过半数的节点检测失效时才生效；
4、客户端与redis节点直连，不需要中间proxy层；client根据node返回的错误信息重定向请求
对应的缺陷有以下两点：
1、无中心化的结构使得每个节点需要同剩余的节点进行通信，随着节点增多，网络压力增大。
2、业务层和架构层高度耦合，出现问题难以拆分解决。
针对Redis cluster的问题，市场上出现了诸如Codis、Twemproxy等分布式解决方案，都是在架构顶层增加一层无状态的代理，
这样不仅解决了无中心结构互相通信造成的网络压力问题，也可以使得业务和架构低耦合，避免出现系统问题。
但是由于各种原因，开源的解决方案无法持续更新来跟上Redis版本升级的进度，Redis一些固有的问题无法解决，对使用者带来了一定的烦恼。Redis作者更新了官方集群版的proxy。
二、Redis-cluster-proxy
Redis集群代理和上述的Codis、Twemproxy方案类似，是基于Redis集群的上层代理，通过使用代理，集群被抽象出来，访问代理如图访问Redis节点。
Redis集群代理有以下几个特性：
1、路由:每个查询将自动路由到集群的正确节点
2、多线程
3、支持多路复用和私有连接模型
4、即使在多路复用上下文中，查询执行和返回顺序也得到保证
5、在ASK|MOVED错误后自动更新集群的配置:当这些类型的错误在返回中发生时，代理会通过重新映射所有slot来自动更新集群的内部配置。更新完成后，将重新执行所有查询。
6、跨slot/节点查询:支持在不同slot(甚至属于不同集群节点)的处理多个键的命令。这些命令将被分割成多个查询路由到不同的slot/节点。这些命令的结果返回是特定于命令的。
MGET、MSET或DEL等其他命令将对所有应答的结果进行求和。因为这些查询实际上破坏了命令的原子性，所以它们的使用是可选的(默认禁用)。
7、一些没有特定节点/slot的命令(如DBSIZE)被分发给所有节点，汇总每个节点的结果并返回。
8、PROXY命令可以展现一些代理特定的信息。
Redis-cluster-proxy解决了Redis-cluster无中心化的多节点网络通信压力、业务和架构高度耦合的问题，同时可以兼容底层Redis版本变更，是一个不错分布式解决方案的选择。
由于目前Redis-cluster-proxy仍处于非稳定版本，GitHub上仍有反馈bug，部分proxy参数无法动态修改，统计信息缺失不易监控，距离在生产环境大规模部署有一定距离。
