原文地址：http://redis.io/topics/partitioning

分区：如何在多个redis实例之间分割数据

    分区就是把你的数据分割到多个redis实例的过程，以便每个实例只包含你所拥有的key的子集。文档的第一部分将向你介绍分区的概念，第二部分将向你展示区分可选择的策略。

为什么分区是有用的

在redis服务器中的分区主要包含两个目标：

• 通过利用多台计算机内存的和值，允许我们构造更大的数据库。
• 通过多核和多台计算机，允许我们扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽。

分区基础知识

    这里有不同的分区标准。设想我们有4个redis实例R0，R1，R2，R3，很多 key表现为user:0，user:1，......等等，我们可以找到不同的方式来定位一个给定的key存储在哪台实例上。换句话说就是有不同的系统用来映射给定的key与给定的redis实例。

一种最简单的分区方式是范围分区，它是通过把范围内的对象映射到特定的redis实例来实现的。例如，我可以定义id 0-10000将进入R0，而id10001-20000进入R1等等。

    这种系统，在实践中确实被采用，然而，它存在不足，它需要一个表用来映射范围与redis实例。这个表是需要管理的，并且对于每种类型的对象，我们都需要一个表。通常来讲，这对于redis不是个好主意。

范围分区的一个替代方案就是hash分区。

• 对key做hash运算，获得一个数字。例如，可以采用crc32函数，结果会输出类似于93024922的数值。
• 对获得数值取模，就能够获得实例。

不同的分区实现

• 客户端实现分区

由客户端直接选择正确的节点来读写key。

• 代理辅助分区

        客户端发送请求给代理，代理能够通过redis协议与redis会话。代理通过配置的分区方案，确保把我们的请求转发到正确的redis实例上，并且把响应返回给客户端。redis和memcached代理Twemproxy实现了代理辅助分区。

• 查询路由

你可以发送你的请求到一个随机的实例，这个实例将确保把你的请求转发到正确的实例。在客户端的帮助下，redis集群实现了混合形式的查询路由(请求不是直接从一个redis实例转发到另外一个实例，而是客户端获得重定向后，访问正确的节点)

分区的不足

redis的一些特性在分区方面表现的不是很好：

• 涉及多个key的操作通常是不被支持的。举例来说，当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作。
• 涉及多个key的redis事务不能使用。
• 当使用分区时，数据处理较为复杂，比如你需要处理多个rdb/aof文件，并且从多个实例和主机备份持久化文件。
• 增加或删除容量也比较复杂。redis集群大多数支持在运行时增加、删除节点的透明数据平衡的能力，但是类似于客户端分区、代理等其他系统则不支持这项特性。然而，一种叫做presharding的技术对此是有帮助的。

数据是要存储还是缓存？

    当使用redis作为数据存储和缓存时，分区在概念上是相同的，然而这里还是有很大的不同。当redis作为数据存储使用时，你必须确定，一个给定的key应该总是映射到同一个实例上，当redis被用作缓存使用时，如果我们使用了不同的节点，即使给定的一个节点是无法获得的，这也不是一个大问题。当我们希望提供系统的可用性时，可以通过改变key到实例的映射来实现这一点。

    如果对于一个给定的key，其首选节点不可用，一致性hash实现通常能够把key切换到其他节点。同样，如果添加一个新节点，部分新key也将被存储到新节点中，主要概念如下：

• 如果redis被用作cache scale up 、scale down时，使用一致性hash比较容易。
• 如果redis被用作存储，我们需要固定key与节点之间的映射，并且固定节点的数量。否则在增加或者删减节点时，我们需要一个有能力再平衡key与节点的系统。而且目前只有redis集群能够做到这一点，但目前redis集群仍是beta版，还没有考虑生产环境的准备。

Presharding

    我们知道，分区面临的问题是，除非我们使用redis作为缓存，否则增加、删除节点可能是棘手的，并且使用固定的key到实例的映射是比较简单的。

然而，数据存储的需求可能会随时间而变化的。今天，我可能需要10个节点，但是明天，我可能需要50个节点。

    由于redis占用空间较小且是轻量级的，一个解决该问题的简单方法就是，一开始的时候就启动大量实例。即使你开始只启动一台服务器，自第一天起，你可以决定生活在一个分布式的世界里，在你唯一的服务器上运行多个redis实例，使用分区。

    你可以在启动时选择足够数量的实例，比如，32或者64个实例可能是大多数用户的常见做法，同时这种做法也提供了足够的增长空间。

这样，当你的数据存储需要增加或者需要更多的redis服务器时，你所需要做的就是把实例从一台服务器迁移到另外一台。一旦你增加第一个额外的服务器，你就需要把半数的redis实例从第一台服务器迁移第二台，依此类推。

使用redis复制技术，你就有可能非停机或者最小数据量迁移实施。

• 在新服务器上启动空实例。
• 移动数据，配置这些新实例为源实例的从库。
• 停止client。
• 更改被移动的实例的配置为新服务器ip。
• 向新服务器上的从库发送SLAVEOF NO ONE命令。
• 按更新的配置，重启client。
• 最后关闭老的服务器上不再使用的实例。

redis分区实现

到目前为止，我们从理论上讨论了redis分区，但应如何实践？我们该采用什么系统？

redis 集群

    redis集群是获得自动切分和高可用性的首选方法。它现在还不具备实施到生产环境，但已经进入到最后的测试阶段，所以我们建议你开始尝试它。你可以在 Cluster tutorial.获得过多redis集群信息。

    一旦redis集群可用，且如果对于你使用的语言，有配套的redis集群客户端，那么redis集群将成为redis分区的事实标准。

redis集群是介于查询路由与客户端分区的混合体。

Twemproxy

    Twemproxy是由Twitter开发的支持Memcached ASCII和Redis协议的一个代理。它是单线程的，C语言实现，且相当的快。它是在Apache 2许可条款下开源的。

    Twemproxy支持多个redis实例之间的自动分区，并支持不可用节点弹出的功能(这将改变key到实例的映射，如果你把redis作为缓存使用，可以利用这个特性)。

    Twemproxy是非单点故障的，因为你可以启动过个代理，并且通知客户端连接到第一个可接受连接的代理。

    Twemproxy是客户端与redis实例之间的中间层，它能以最小的额外复杂度为我们处理分区。从目前来看，它是建议的redis分区处理方式。

你可以从这里获得更多关于Twemproxy的信息。
Twemproxy介绍：http://www.cnblogs.com/yuxingfirst/archive/2013/02/05/2892947.html

支持一致性hash的客户端

    另外一种替代Twemproxy的方案，就是使用实现分区(一致性hash或者其他算法)的客户端。有不少客户端都支持一致性hash特别是Redis-rb 和Predis。请查看完整的redis客户端列表，检查是否存在使用你的语言实现了一致性hash的成熟的客户端。