Redis Sharding | Redis分片

Partitioning(分片)

分片(partitioning)就是将你的数据拆分到多个Redis实例的过程，这样每个实例将只包含所有键的子集。Redis的分片承担着两个主要目标：

• 允许使用很多电脑的内存总和来支持更大的数据库。没有分片，你就被局限于单机能支持的内存容量。
• 允许伸缩计算能力到多核或多服务器，伸缩网络带宽到多服务器或多网络适配器。

分片的缺点(Disadvantages)

Redis的一些特性与分片在一起时玩转的不是很好：

涉及多个键的操作通常不支持。例如，你不能对映射在两个不同Redis实例上的键执行交集(事实上有办法做到，但不是直接这么干)。

涉及多个键的事务不能使用。

分片的粒度(granularity)是键，所以不能使用一个很大的键来分片数据集，例如一个很大的有序集合。

当使用了分片，数据处理变得更复杂，例如，你需要处理多个RDB/AOF文件，备份数据时你需要聚合多个实例和主机的持久化文件。

添加和删除容量也很复杂。例如，Redis集群具有运行时动态添加和删除节点的能力来支持透明地再均衡数据，但是其他方式，像客户端分片和代理都不支持这个特性。但是，有一种称为预分片(Presharding)的技术在这一点上能帮上忙。

分片基础(Basic)

有很多不同的分片标准(criteria)。假想我们有4个Redis实例R0，R1，R2，R3，还有很多表示用户的键，像user:1，user:2，…等等，我们能找到不同的方式来选择一个指定的键存储在哪个实例中。换句话说，有许多不同的办法来映射一个键到一个指定的Redis服务器。

Range Partitioning(范围分片)

最简单的执行分片的方式之一是范围分片(range partitioning)，通过映射对象的范围到指定的Redis实例来完成分片。例如，我可以假设用户从ID 0到ID 10000进入实例R0，用户从ID 10001到ID 20000进入实例R1，等等。这套办法行得通，并且事实上在实践中被采用，然而，这有一个缺点，就是需要一个映射范围到实例的表格。这张表需要管理，不同类型的对象都需要一个表，所以范围分片在Redis中常常并不可取，因为这要比替他分片可选方案低效得多。

Hash Partitioning(哈希分片)

一种范围分片的替代方案是哈希分片(hash partitioning)。这种模式适用于任何键，不需要键像object_name:这样的饿形式，就像这样简单：

• 使用一个哈希函数(例如，crc32哈希函数)将键名转换为一个数字。例如，如果键是foobar，crc32(foobar)将会输出类似于93024922的东西。
• 对这个数据进行取模运算，以将其转换为一个0到3之间的数字，这样这个数字就可以映射到我的4台Redis实例之一。93024922模4等于2，所以我知道我的键foobar应当存储到R2实例。注意：取模操作返回除法操作的余数，在许多编程语言总实现为%操作符。

分片实现

Client Side Partitioning

客户端分片(Client side partitioning)意味着，客户端直接选择正确的节点来写入和读取指定键，把分片的逻辑放在Redis客户端实现，通过Redis客户端预先定义好的路由规则，把对Key的访问转发到不同的Redis实例中，最后把返回结果汇集。

客户端分片的优势在于所有的逻辑都是可控的，不依赖于第三方分布式中间件。开发人员清楚怎么实现分片、路由的规则，不用担心踩坑。而缺点在于：

• 这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。
• 可运维性差，集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了跨部门沟通的成本。
• 在不同的客户端程序中，维护相同的分片逻辑成本巨大。例如，系统中有两套业务系统共用一套Redis集群，一套业务系统用Java实现，另一套业务系统用PHP实现。为了保证分片逻辑的一致性，在Java客户端中实现的分片逻辑也需要在PHP客户端实现一次。相同的逻辑在不同的系统中分别实现，这种设计本来就非常糟糕，而且需要耗费巨大的开发成本保证两套业务系统分片逻辑的一致性。

Proxy assisted partitioning:代理协助分片

我们的客户端发送请求到一个可以理解Redis协议的代理上，而不是直接发送请求到Redis实例上。代理会根据配置好的分片模式，来保证转发我们的请求到正确的Redis实例，并返回响应给客户端。Redis和Memcached的代理Twemproxy实现了代理协助的分片。

Query routing:查询路由方式

查询路由意味着，你可以发送你的查询到一个随机实例，这个实例会保证转发你的查询到正确的节点。Redis集群在客户端的帮助下，实现了查询路由的一种混合形式(请求不是直接从Redis实例转发到另一个，而是客户端收到重定向到正确的节点)。 Redis 3.0集群采用了P2P的模式，完全去中心化。Redis把所有的Key分成了16384个slot，每个Redis实例负责其中一部分slot。集群中的所有信息(节点、端口、slot等)，都通过节点之间定期的数据交换而更新。

Redis客户端在任意一个Redis实例发出请求，如果所需数据不在该实例中，通过重定向命令引导客户端访问所需的实例。

Redis 3.0集群的工作流程如图4所示。

图4Redis 3.0集群的工作流程图

如图4所示Redis集群内的机器定期交换数据，工作流程如下。

(1) Redis客户端在Redis2实例上访问某个数据。

(2)在Redis2内发现这个数据是在Redis3这个实例中，给Redis客户端发送一个重定向的命令。

(3) Redis客户端收到重定向命令后，访问Redis3实例获取所需的数据。

Redis 3.0的集群方案有以下两个问题。

• 一个Redis实例具备了“数据存储”和“路由重定向”，完全去中心化的设计。这带来的好处是部署非常简单，直接部署Redis就行，不像Codis有那么多的组件和依赖。但带来的问题是很难对业务进行无痛的升级，如果哪天Redis集群出了什么严重的Bug，就只能回滚整个Redis集群。
• 对协议进行了较大的修改，对应的Redis客户端也需要升级。升级Redis客户端后谁能确保没有Bug？而且对于线上已经大规模运行的业务，升级代码中的Redis客户端也是一个很麻烦的事情。

综合上面所述的两个问题，Redis 3.0集群在业界并没有被大规模使用。

High Available Cluster |高可用集群

避免集群倾斜