redis集群客户端_Redis系列专题13 -- 分区

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

为啥要分区

分区在Redis中主要有两个目的：

• 分区利用多台机器的内存构建一个更大数据库。如果不使用分区，数据库大小受限于单个计算机内存。
• 分区可以在多核和多计算机之间弹性扩展计算能力，并且分区可以在多计算机和网络适配器之间弹性扩展网络带宽。

Redis分区基础

有多种的分区标准。假设我们有4个Redis实例 R0,R1,R2,R3，很多表示用户的键例如 user:1,user:2等等，我们可以找到不同方式选择实例存储指定的键。换句话说有不同的系统映射一个指定的键到一个给定的Redis服务器。

一个最简单的方法是使用范围分区，并且通过映射某一范围的对象到特定的Redis实例。例如，我可以指定ID 0到10000的用户存储到实例R0，而ID 10001到20000的用户存储到实例R2等等。

该方案实际上是可以应用在实践中的，尽管他的缺点是需要一张映射对象范围与实例的表。这张表需要进行维护，并且我们需要为每种类型对象建立一张表，所以范围分区在Redis中常常是不受欢迎的，因为比其他分区方法更低效。

一个范围分区替代方法是哈希分区。此方案适用于任何形式键，无需键格式形如object_name:，就是这么简单：

使用哈希方法(例如crc32哈希方法)将键名转换成数字。例如一个键名是foobar，crc32(foobar)输出结果形如93024922。

我是使用取模操作将该数字转换成0到3的数字，以便映射到四个Redis实例中的一个。93024922对4取余数等于2，这样我知道foobar键应该存储到R2实例中。注意：模操作返回除法运算的余数，大部分编程语言使用%(取余)就可以了。

通过这两个例子，你应该可以想到还有很多其他方法进行分区。一个更先进的哈希分区是一致性哈希，并且是由几个Redis客户端和代理实现的。

分区不同实现方式

分区可以由一个软件栈的不同部分完成。

客户端分区：客户端直接选择正确节点读写指定键。很多Redis客户实现了这种分区方式。

代理辅助分区：是指我们的客户端通过Redis协议把请求发送给代理，而不是直接发送给真正的Redis实例服务器。这个代理会确保我们的请求根据配置分区策略发送到正确的Redis实例上，并返回给客户端。Redis和Memcached的代理都是用Twemproxy (这是twitter开源的一个代理框架)来实现代理服务分区的，国内的codis(豌豆荚开源)

查询路由：是指你可以把一个请求发送给一个随机的实例，这时实例会把该查询转发给正确的节点。通过客户端重定向(客户端的请求不用直接从一个实例转发到另一个实例，而是被重定向到正确的节点)，Redis集群实现了一种混合查询路由。

Redis分区缺点

虽然redis分区极大地提高了整个集群的性能，但缺点同样明显：

1.不支持事物(多个不同机器的key)

2.涉及多个key的操作通常是不被支持的,举例来说，当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作

3.当使用分区的时候，数据处理会更复杂，对于实例你必须处理多个RDB/AOF文件，为了备份数据，需要从多个实例和主机聚合持久文件。

4.增加或删除容量也比较复杂。redis集群大多数支持在运行时增加、删除节点的透明数据rebalance的能力，但是类似于客户端分区、代理等其他系统则不支持这项特性。我们还需要预分片(分区)技术来帮助实现。

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

什么是预分片技术

Sharding，译为分片，有时也用partitioning(分区)，这俩是同一个意思，说的是数据分散到Redis多个实例。

那presharding就是预分片的意思，这是Redis 3.0之前的概念。在Redis 3.0官方支持了Redis集群，在那之前，要想实现集群，用的是各种民间方法，如客户端侧的分片、代理等，典型的代表是Twitter的Twemproxy。同时，Redis作者也提出了一种集群方案，即为presharding。他戏称之为乞丐版的集群，正统的当然是之后的3.0集群方案啦。

如何分片，大家可能首先会想到如下的分片方案：Node = Hash(key) MOD N。hash是简单的，但rehash是很困难的，同时涉及到redis运行时key在不同实例间的迁移。

Redis Presharding不需要resharding，主要步骤如下：

0)在项目的开始阶段，在同一服务器上部署多个redis实例；

1)在扩容阶段，新增服务器，部署新的redis实例；

2)将新实例设为要迁移的旧实例的slave；

3)断开客户端；

4)更新配置：新实例的ip；

5)新实例执行slaveof no one，成为master；

6)重启客户端，使客户端使用新实例；

7)关闭旧实例。

以上拆分流程是Redis作者提出的一个平滑迁移的过程，不过该拆分方法还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。

重点说明：

1.presharding前后，集群中的redis实例总数是不变的。正因为如此，避免了resharding，不存在key值从一个区转移到另一个分片区。

2.集群的思想是用多台(可能性能相对差的)机器，得到高效的处理能力。随着业务的发展，单机上可能存储、CPU、内存不够用了，此时就需要增加机器，并进行实例的迁移，此时单机的实例数变少，单机的压力减小。因此，假设有N台机器，每台M个实例，随着业务的发展，N会逐渐增大，M逐渐减小，但N*M是保持不变的。

3.限制。该方案受限于初始设定的实例数，如果N*M个redis实例还满足不了需求，再增加机器就会出现resharding。作者建议初始单机部署32，64，128个redis实例，当然最终还是应该根据自己的业务实际情况和对未来的预估，或者直接升级redis版本。