Redis内存又不够用了?教你几种集群方案轻松甩掉存储难题

Redis，一款技术研发者们耳熟能详的内存数据库。作为数据库，存储数据的容量都是有限的，不能超过主机内存的大小。通常而言，一台主机服务器的内存只有十几G，较大可达100G或200G。

为了解决Redis存储瓶颈问题，各大企业纷纷开始寻找解决方案，将数据分片(sharding)存储在多个Redis实例之中，每一个分片就是一个Redis实例，然后实现多个Redis实例协同运行。这就是Redis集群原理。本篇将围绕Redis集群方案展开重点介绍。

Redis集群实现方式：

• 分区，将数据分割划分到多个Redis实例中去，然后保证每个实例只保存key的一个子集;
• 通过多台计算机的内存和值构造更大的数据库;
• 通过多台计算机扩展计算能力;
• 通过多台计算机机和网络适配，扩展网络宽带。

集群的实现方式：

• 客户端分片
• 基于代理的分片
• 路由查询

下面我们对三种实现方式展开介绍：

客户端分片

客户端分片就是将分片工作放在业务程序端实现，程序代码根据Redis客户端预先定义好的路由规则，直接对不同的Redis实例进行分布式访问，最终再把结果汇集在一起。

这种方案的优势就在于所有逻辑都是可以控制的，没有第三方中间件干预，开发人员很清楚如何实现分片及路由规则，实现方法完全由自己掌控。

但是客户端分片方案的弊端也是令开发者也是十分懊恼的。由于客户端分片方案是一种静态的分片方案，无论是增加或是减少Redis实例的数量，都必须要开发者手动调整分片程序，对开发者的依赖很强;其次在运维上，该方案运维性较差，一旦集群数据出现问题，就需要开发人员和运维人员共同解决，在不同的客户端程序中，维护相同的分片逻辑成本很大，需要消耗巨大的开发成本才能保证两套业务系统分片逻辑一致。所以，客户端分片方案并不适合中小型的企业使用。

基于代理的分片

基于代理分片就是客户端发送请求到一个代理，由代理来解析客户端的数据，再将请求转发到正确的节点，最终将结果回复给客户端。常用的基于代理的分片方案有两种，Twemproxy、codis。

Twemproxy

Twemproxy是一款由Twitter开源的redis proxy方案，在Twitter、Yahoo都有使用。当Twemproxy工作时，Redis客户端会把请求发送到Twemproxy，Twemproxy会使用一致性hash算法，根据路由规则发送正确的Redis实例，最后Twemproxy再把结果返给客户端，从而实现Redis集群。

由于Twemproxy是单线程方案，所以只能使用单核cpu，如果前端含keepalive或haproxy相关代理，可以为Twemproxy做1+1准备。

当Twemproxy应用于多台Redis服务器时，那么实现的性能只能达到单台Redis服务器80%，剩余20%性能损耗。Redis-Sentinel是Redis官方推荐的一种高可用性解决方案，当用Redis做Master-slave的高可用方案时，如果Master宕机了，Twemproxy会订阅Sentinel,完成主备切换。由于Redis-sentinel本身是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后可以进行自动切换。

Twemproxy优点：

• 支持Redis和memcached两种集群代理;
• 后端Redis和memcached无需任何改动，只需要提供IP和端口给Twemproxy即可，操作简单;
• 支持无效Redis实例的自动删除;
• 支持状态监控......

Twemproxy不足：

• 无法动态扩容，如果需要扩容功能，必须研发人员手动迁移，比较繁琐;
• 由于Redis客户端的请求都需要经过Twemproxy才能到达Redis服务器，期间难免会产生性能损失;
• 无法平滑地扩容/缩容，对于运维人员来说，如果业务需要增加Redis实例，工作量会非常大......

Codis

Codis是由豌豆荚于2014年11月在GitHub上开源，基于Go和C语言，支持平滑增加Redis实例的集群解决方案。使用Codis时，设置好下属的Redis实例，在需要连接Redis的地方改为连接Codis,之后Codis会以一个代理的身份接受请求，并使用一致性hash算法，将请求转接到具体Redis，最后再将结果返回到Codis。作为基于代理的分片，功能与Twemproxy类似。

Codis主要包含四大组件Codis Proxy(codis proxy)、Codis Manager(codisconfig)、Codis Redis(codis-server)和ZooKeeper，每一个组件都可以进行动态扩容。

Codis Proxy：客户端连接到Redis代理服务，本身已实现了Redis协议，Redis客户端连接到Codis Proxy可以进行各种操作。Codis Proxy是无状态的，一个业务可以通过Keepalived等负载均衡软件部署多个Codis Proxy;

Codisconfig：Codisconfig是Codis的管理工具，支持添加/删除Redis节点、添加/删除Proxy节点、发起数据迁移等操作。另外Codisconfig自带http server，里面集成一个管理界面，运维人员可以在浏览器上观察Codis集群的运行状态并进行相关操作;

Codis Redis：Codis Redis基于 redis-2.8.21 分支开发，是Codis项目维护的一个Redis分支，其中加入了slot支持和原子数据迁移指令;

ZooKeeper：Codis通过ZooKeeper来存放数据路由表和Codis Proxy节点的原信息，Codisconfig发起的命令都会通过ZooKeeper同步到各存活的Codis Proxy节点。

路由查询

路由查询是指将任务请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行任务。在Redis集群方案中使用的路由查询方案有Redis cluster。

Redis Cluster由Redis官方推出，是一种服务器Sharding技术，3.0版本开始正式提供，可线性扩展到1000个节点。在Redis Cluster中，Sharding将所有Key映射到slot中，slot个数一共16384个。Redis集群中，每个节点都会负责16384个slot中的一部分。当动态添加或减少节点时，需要将16384个slot重做分配，slot中对应的Key也要做迁移。这项工作目前是需要人工介入手动操作的。在使用Redis Cluster时，要确保16384个slot对应节点都能正常工作，如果有一个节点发生故障，整个集群都会无法工作。

为了增加集群的可访问性，Redis官方推荐将节点配置成主从结构(一个master主节点挂多个salve从节点)如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。

使用Redis cluster时，由于官方并未提供图形管理工具，所以运维比较复杂。而且集群管理与数据存储上存在耦合，一旦集群管理出现问题，整个Redis都需要升级整合。Redis Cluster自2015年发布以来，成功使用的企业还并不是很多。

需要的Java架构师方面的资料可以关注之后私信哈，回复“资料”领取免费架构视频资料，记得要点赞转发噢！！！