Redis分区/分片详解

分区/分片详解

分区是分割数据到多个Redis实例的处理过程，因此每个实例只保存key的一个子集。

如果只使用一个redis实例时，其中保存了服务器中全部的缓存数据，这样会有很大风险，如果单台redis服务宕机了将会影响到整个服务。解决的方法就是我们可以采用分片/分区的技术，将原来一台服务器维护的整个缓存，现在换为由多台服务器共同维护内存空间。

为什么要分区？

• 在大数据高并发场景下，单个redis实例往往不足以应付。首先体现在内存上，单个redis的内存不宜过大，内存太大会导致rdb文件过大，进一步导致主从同步时全量同步时间过长，在实例重启恢复时也会消耗很长的数据加载时间，特别是在云环境下，单个实例内存大小往往都是受限的。其次体现在CPU的利用率上，单个redis实例只能利用单个核心，单个核心要完成海量数据的存取和管理工作，压力会非常大。

• 正是在这样的大数据高并发的需求之下，redis集群方案应运而生。它可以将众多小内存的redis实例整合起来，将分布在多台机器上的众多CPU核心的计算能力聚集在一起，完成海量数据存储和高并发读写操作。

Redis的分区方案

• 客户端分区

  在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取。大多数客户端已经实现了客户端分区。

  

  系统架构

  

  实现方案

  客户端分区方案 的代表为 Redis Sharding，Redis Sharding 是 Redis Cluster 出来之前，业界普遍使用的 Redis 多实例集群 方法。Java 的 Redis 客户端驱动库 Jedis，支持 Redis Sharding 功能，即 ShardedJedis 以及 结合缓存池 的 ShardedJedisPool。

  优点：

  客户端分片的好处就是所有的逻辑都是可控的，不依赖于第三方分布式中间件。开发人员清除怎么实现分片、路由的规则，不用担心踩坑。

  缺点：

  • 这是一种静态的分片方案，需要增加或者减少redis实例的数量，需要手动调整分片的程序

  • 可运维性差。集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了跨部门沟通的成本

  • 在不同的客户端程序中，维护相同的分片逻辑成本巨大。比如，系统中有两套业务系统共用一套redis集群，一套业务系统用java实现，另一套业务系统用php实现。为了保持分片逻辑的一致性，在java客户端中实现的分片逻辑也需要在php客户端实现一次。相同的逻辑在不同的系统中分别实现，这种设备本来就非常糟糕，而且需要耗费巨大的开发成本保证两套业务系统分片逻辑的一致性

• 范围分区
  映射一定范围的对象到特定的Redis实例。比如，ID从0到10000的用户会保存到实例R0，ID从10001到 20000的用户会保存到R1，以此类推
  hash一致算法实现分区
  hash一致算法实现分区，对key值进行hash一致性计算后得到结果，最终将数据保存到某一台redis实例中

• 代理分区

  

  实现方案：

  Twemproxy 也叫 nutcraker，是 twitter 开源的一个 redis 和 memcache 的 中间代理服务器 程序。Twemproxy 作为 代理，可接受来自多个程序的访问，按照 路由规则，转发给后台的各个 Redis 服务器，再原路返回。Twemproxy 存在 单点故障 问题，需要结合 Lvs 和 Keepalived 做 高可用方案。

  基本原理：

  • redis客户端把请求发送到Twemproxy

  • Twemproxy根据路由规则发送到正确的redis实例

  • 最后Twemproxy把结果汇集返回给客户端

  客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy

• 查询路由

  是客户端随机地请求任意一个redis实例，然后由Redis将请求转发给正确的Redis节点。Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个redis节点转发到另一个redis节点，而是在客户端的帮助下直接redirected到正确的redis节点

Redis分区不足：

1. 分区是多台redis共同作用，如果一台宕机，其实是整个分片故障。虽然缓解了内存压力，但是没有实现高可用。

2. 涉及多个key的操作就会不支持。比如当两个set映射到不同的redis实例时，因为他们可能被存储到不同的实例上，所有就无法完成交集操作。

3. 涉及到多个key的redis事务就不被支持。

4. 分区对于动态扩容，其实是非常复杂的。因为需要修改客户端代码。

   当两个set映射到不同的redis实例上时，因为他们可能被存储到不同的Redis实例，你就不能对这两个set执行交集操作

Redis一种推荐做法：

例子：

我们Redis容量变动在实际应用中是非常常见的，比如今天我需要10台Redis机器，明天可能就需要50台机器了。

• 我们可以开启多个Redis实例，尽管是一台物理机器，我们在刚开始的时候也可以开启多个实例。

• 我们可以从中选择一些实例，比如32或64个实例来作为我们的工作集群。

• 当一台物理机器存储不够的时候，我们可以将一般的实例移动到我们的第二台物理机上，依次类对，我们可以保证集群中Redis的实例数不变，又可以达到扩充机器的目的。

怎么移动Redis实例呢？当需要将Redis实例移动到独立的机器上的时候，我们可以通过下面步骤实现：

• 在新的物理机上启动一个新的Redis实例。

• 将新的物理机作为要移动的那台的slave机器。

• 停止客户端。

• 更新将要被移动的那台Redis实例的IP地址。

• 对于slave机器发送SLAVEOF ON ONE命令。

• 使用新的IP启动Redis客户端。

• 关闭不再使用的那个Redis实例。

Redis集群

数据分区是集群的实现基础。集群是数据分区的具体实现。

• 由于redis出众的性能，其在众多的移动互联网企业中得到广泛的应用。

• redis在3.0版本前只支持单实例模式，虽然现在的服务器内存可以到100GB、200GB的规模，但是单实例模式限制了redis没法满足业务的需求（比如新浪微博就曾经用redis存储了超过1TB的数据）。

• redis的开发者Antrres早在博客上就提出在redis3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。

• 各大企业在3.0版本还没有发布前为了解决redis的存储瓶颈，纷纷推出了各自的redis集群方案。这些方案的核心思想就是把数据分片（sharding）存储在多个redis实例中，每一片就是一个redis实例。

实现案例：

Redis cluster是redis作者自己提供的集群化方案