redis：redis分区有哪些实现方案

蔚落 2022-08-28 09:46 259阅读 0赞

# Redis分区基础 #

实际应用中有很多分区的具体策略，举个例子，假设我们已经有了一组四个Redis实例分别为R0、R1、R2、R3，另外我们有一批代表用户的键，如：user:1，user:2，……等等，其中“user:”后面的数字代表的是用户的ID，我们要做的事情是把这些键分散存储在这四个不同的Redis实例上。

怎么做呢？最简单的一种方式是范围分区(range partitioning)，下面我们来看看基于范围分区怎么做。

## 范围分区 ##

*  范围分区，也叫做顺序分区，最简单的分区方式。
 *  通过映射对象的范围到指定的 Redis 实例来完成分片（将一个范围内的key都映射到同一个Redis实例中）。
 *  具体做法如下：我们可以将用户ID从0到10000的用户数据映射到R0实例，而将用户ID从10001到20000的对象映射到R1实例，依次类推。  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16]

这种方法虽然简单，但是在实际应用中是很有效的，不过还是有问题：

*  我们需要一张表，这张表用来存储用户ID范围到Redis实例的映射关系，比如用户ID0-10000的是映射到R0实例……。
 *  我们不仅需要对这张表进行维护，而且对于每种对象类型我们都需要一个这样的表，比如我们当前存储的是用户信息，如果存储的是订单信息，我们就需要再建一张映射关系表。
 *  如果我们想要存储的数据的key并不能按照范围划分怎么办，比如我们的key是一组uuid，这个时候就不好用范围分区了。

## 哈希分区 ##

哈哈希分区跟范围分区相比一个明显的优点是哈希分区适合任何形式的key，而不像范围分区一样需要key的形式为object\_name:< id>，而且分区方法也很简单，一个公式就可以表达：

id=hash(key)%N

其中id代表Redis实例的编号，公式描述的是

*  首先根据key和一个hash函数（如crc32函数）计算出一个数值型的值。接着上面的例子，我们的第一个要处理的key是user:1，hash（user:1）的结果是93024922。
 *  然后哈希结果进行取模，取模的目的是计算出一个介于0到3之间的值，因此这个值才可以被映射到我们的一台Redis实例上面。比如93024922%4结果是2，我们就会知道foobar将要被存储在R2上面。  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16 1]

# 不同分区的实现 #

分区可以在redis软件栈的不同部分被实现，我们来看看下面几种

## 客户端分区 ##

客户端分区就是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取。大多数客户端已经实现了客户端分区  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]

## 代理分区 ##

*  客户端将请求发往代理服务器，代理服务器实现了Redis协议，因此代理服务器可以代理客户端和Redis服务器通信。
 *  代理服务器通过配置的分区schema来将客户端的请求转发到正确的Redis实例中，同时将反馈消息返回给客户端。  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_14_color_FFFFFF_t_70_g_se_x_16]

## 查询路由 ##

查询路由是redis cluster实现的一种redis分区方式

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

Redis集群实现了一个通过和客户端协作的hybrid来做查询路由。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]

# redis分区的缺点 #

1、多键操作是不被支持的，比如我们将要批量操作的键被映射到了不同的Redis实例中。

2、多键的Redis事务是不被支持的。

3、分区的最小粒度是键，因此我们不能将关联到一个键的很大的数据集映射到不同的实例。

4、当应用分区的时候，数据的处理是非常复杂的，比如我们需要处理多个rdb/aof文件，将分布在不同实例的文件聚集到一起备份。

5、添加和删除机器是很复杂的，例如Redis集群支持几乎运行时透明的因为增加或减少机器而需要做的rebalancing,然而像客户端和代理分区这种方式是不支持这种功能的。

# 持久存储还是缓存 #

尽管数据分区对于redis来说无论是数据持久化存储还是缓存，在概念上来说都是一样的，然而对于数据持久化存储还是有很大的一个限制。

*  当我们使用Redis来作为持久化存储的时候，每一个key必须一直被映射到同一个Redis实例。
 *  而当Redis被当做缓存使用的时候，对于这个key，如果一个实例不能用了，这个key还可以被映射到其他的实例中。

Consistent hashing实现通常使得当一个key被映射到的实例不能用的时候将这个key映射到其他实例成为可能。类似，如果增加了一台机器，一部分的key将会被映射到这台新的机器上，我们需要了解的两点如下：

*  如果redis被用来当做缓存，而且要求容易增加或者删除机器，使用consistent hashing是非常简单的
 *  如果Redis被用来当做（持久）存储，一个固定的key到实例的映射是需要的，因此我们不能够再灵活的添加或删除机器。否则，我们需要在增加或删除机器的时候系统能够rebalace，当前Redis Cluster已经支持

# Pre-Sharding #

通过上面的介绍，我们知道Redis分区应用起来是有问题的，除非我们只是使用Redis当做缓存，否则对于增加机器或删除机器是非常麻烦的。

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

鉴于Redis是很轻量级的服务（每个实例仅仅占用1M），对于上面的问题一种简单的解决办法是：

*  我们可以开启多个Redis实例，尽管是一台物理机器，我们在刚开始的时候也可以开启多个实例。
 *  我们可以从中选择一些实例，比如32或64个实例来作为我们的工作集群。
 *  当一台物理机器存储不够的时候，我们可以将一般的实例移动到我们的第二台物理机上，依次类对，我们可以保证集群中Redis的实例数不变，又可以达到扩充机器的目的。

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

*  在新的物理机上启动一个新的Redis实例。
 *  将新的物理机作为要移动的那台的slave机器。
 *  停止客户端。
 *  更新将要被移动的那台Redis实例的IP地址。
 *  对于slave机器发送SLAVEOF ON ONE命令。
 *  使用新的IP启动Redis客户端。
 *  关闭不再使用的那个Redis实例。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/d4b84a0f6aeb495e995c74b5dd196430.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/a6aa76b73e8c4df4afca74f0d7a53189.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/4008d42148404de6b0f20e6a490340e2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_14_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/aa76f45ddcd0400580ae9dba79f10676.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/9ca4dc28546a493c9465e263a83f71f0.png