Redis集群方案对比

本文专注于从程序角度看如何使用Redis集群，以及相关的方案。

概要

为何要做集群？主要原因就是为了做Sharding/Partitioning，所以Redis集群方案等价为Redis Sharding/Partitioning方案。

Partitioning: how to split data among multiple Redis instances 对Redis做集群的利弊和考量做了详细说明。因此，在确定方案之前，要先确定你的Redis是用来做什么的？做Cache还是数据持久化，不同方案对此的支持程度是不同的。不言自明的是，如果Redis用途是Cache，整个集群方案会更简单。

需要注意的是，无论采取何种方案，因为Sharding的存在，天然会导致有些命令在集群环境下是无法（正常）工作的，因此对于程序的改造是不可避免的。

Redis集群的方案基本上由以下组件构成：

• Client
• Proxy
• Redis实例

集群管理组件和Redis Sentinel不在本文的探讨范围之内。

而这些组件又可以做出以下细分：

组件

具体讲讲集群的各个组件，以及可用的开源项目。

Proxy

不管何种Proxy，其目的都是伪装成一个Simple Redis实例，使得程序无需改造就能够利用Redis集群。

sharding类型

这种类型的Proxy连接多个simple redis实例，根据自己的Sharding/LB算法，把请求分配到各个redis实例上。

这类Proxy 需要配合 Dashboard（管理组件）才能够更新节点列表。更复杂的运维任务也需要Dashboard配合。

cluster类型

这种类型的Proxy直接连接在Redis Cluster上，集群的管理工作全部交给Redis Cluster，Proxy能够感知到集群节点变化，并且路由命令到正确的Slot上，避免MOVED/ASK重定向，提升执行效率。

开源项目

Client

Client方案和Proxy方案类似，可以类比为把Proxy的基本功能以类库的形式集成到Client里。

simple （傻瓜式）client没什么好谈的，就是最简单的客户端，只能连接一个Redis实例。

随着技术的发展，有些simple client也渐渐支持sharding和cluster特性。

不过需要注意的是，某些Client的实现不是太好，不同模式的API形式不一致，这意味着一定的改造成本。

sharding类型

这种类型的Client连接多个simple redis实例，根据自己的Sharding/LB算法，把请求分配到各个redis实例上。

这类Client 需要配合 Dashboard（管理组件）才能够更新节点列表。更复杂的运维任务也需要Dashboard配合。

cluster类型

这种类型的 Client 直接支持 Redis Cluster 协议，能够感知到集群中节点的变化。

开源项目

结论

根据上面的信息，可以组合出以下几种方案（方案顺序最便利->最麻烦）：

注意：这里的程序改动指的是建立连接或者API的改动，不包括Redis命令的改动，这部分改动是不可避免的。