最近在学习Redis，看到官方文档中的Partioning部分不错，顺手翻译过来，加深理解。文中很多思路和方法虽然比较常见，但是值得重新阅读，并且也适用于其他KV或cache方案。 原文地址：http://redis.io/topics/partitioning 分区：如何在多个Redis实例中分割数
最近在学习Redis，看到官方文档中的Partioning部分不错，顺手翻译过来，加深理解。文中很多思路和方法虽然比较常见，但是值得重新阅读，并且也适用于其他KV或cache方案。
原文地址：http://redis.io/topics/partitioning
分区是分割数据到多个Redis实例的处理过程，因此每个实例只保存key的一个子集。文档的第一部分会介绍分区的概念，第二部分会展示Redis分区的可选方案。
Redis分区有两个主要目的：
可以支持更大的数据库，使用很多计算机的所有内存。没有分区，就被限制在单台计算机所能支持的最大内存。
可以扩展多核和多个计算机的计算能力，还有多个计算机和网络适配器的网络带宽。
有不同的分区标准。假设有4个Redis实例 R0，R1，R2，R3，和类似user:1，user:2这样的表示用户的多个key，对既定的key有多种不同方式来选择这个key存放在哪个实例中。也就是说，有不同的系统来映射某个key到某个Redis服务。
最 简单的分区方式是按范围分区，就是映射一定范围的对象到特定的Redis实例。比如，ID从0到10000的用户会保存到实例R0，ID从10001到 20000的用户会保存到R1，以此类推。这种方式是可行的，并且在实际中使用，不足就是要有一个区间范围到实例的映射表。这个表要被管理，同时还需要各 种对象的映射表，通常对Redis来说并非是好的方法。
另外一种分区方法是hash分区。这对任何key都适用，也无需是object_name:
用一个hash函数将key转换为一个数字，比如使用crc32 hash函数。对key foobar执行crc32(foobar)会输出类似93024922的整数。
对这个整数取模，将其转化为0-3之间的数字，就可以将这个整数映射到4个Redis实例中的一个了。93024922 % 4 = 2，就是说key foobar应该被存到R2实例中。注意：取模操作是取除的余数，通常在多种编程语言中用%操作符实现。
有很多实现分区的其他方法，基于这两个例子，你应该有了认识。hash分区的一种更高级形式叫一致性hash，有些Redis客户端和代理已经实现。
分区可以是软件系统中不同部分来实现。
客户端分区 意味着客户端直接选择对应的节点，被给定key读取或写入。很多Redis客户端实现了客户端分区。
代理辅助分区 意味着客户端发送请求给实现Redis协议的代理，而非直接发送请求给对应的Redist实现。代理会参照配置好的分区策略，保证转发请求给正确的Redis实例，也会给客户端返回响应。Redis和Memcached代理Twemproxy实现了代理辅助分区。
查询路由 意味着发送请求给一个随机的实例，这个实例会保证转发请求到正确的节点。在客户端的帮助下，Redis集群实现了一种混合形式的查询路由（请求不是直接从一个Redis实例转发到另一个实例，而由客户端重定向到正确的节点）。
Redis的某些特性在分区环境下不能充分发挥：
多key操作通常无法支持。比如，如果两个key被映射到不同的Redis实例，无法对两个set取交集（实际有方法实现，但不能非直接实现）。
多key的事务无法使用。
分区粒度是关键，因此，不可能对一个key下面有非常多元素的sorted set分片。
使用分区时，数据处理更复杂。不得不处理多个RDB/AOF文件，做数据备份时需要合并来自多个实例和机器的持久文件。
添加或删除容量可能会复杂。比如，Redis集群计划支持透明重新平衡数据的能力，以支持运行时添加和删除节点，但是其他采用客户端分区和代理的系统就不支持这个特性。但是，Presharding预分片技术在这方面会有帮助。
使 用Redis做为存储或cache，分区在概念上是相同的， 但是有一个巨大的差别。Redis做为数据存储时，要保证给定key总是映射到相同的实例，而Redis做为cache时，一个给定节点不可用，如果开始 使用一个不同的node，不会有太大问题，只要我们愿意，更新key和实例的映射以提升系统可用性（即，对查询响应的系统能力）。
如果给定key的首选节点不可用，一致性hash实现常可以切换到其他节点。类似的，如果添加一个新节点，部分新key开始存到新节点上。
以下是主要概念：
如果Redis用作cache，使用一致性hash容易向上向下扩展。
如果Redis用作存储，要在key和固定节点之间做映射，并且有固定数量的节点。否则在增加或删除节点时，就需要一个系统节点之间对key做迁移。当前，只有Redis集群可以实现，但是在生产环境还不能用。
我们了解到，分区是个问题，除非我们使用Redis做为cache，添加删除节点可能会困难，使用固定的key和实例映射会简单的多。
数据存储需求随着时间变化，今天我可能使用10个Redis节点，明天可能就需要50个节点。
Redis非常小和轻量（一个备用实例仅适用1mb内存容），解决分片问题的一个简单方法是一开始就启动多个实例。即使你只启动一个服务器，第一天就使用分布式，单台服务器上运行多个Redis实例，来使用分区。
从一开始你可以将实例数开的很大，比如32或64个实例，对大多数用户足够满足增长需要。
随着你的存储需求增长，需要更多的Redis服务器，使用这种方式，要做的就是简单的将实例从一台服务器移到另一台。一旦添加了第一个额外的服务器，需要将一半的Redis实例从第一台服务器移到第二台，以此类推。
使用Redis复制你可能会最小代价迁移，对用户无需停机：
在你的新服务器上启动空实例
迁移数据配置这些新实例做为源实例的备机
停止客户端
使用新的服务器IP更新迁移实例的配置
发送SLAVEOF NO ONE命令到新服务器上的备机
用新更新的配置重启客户端
最后关闭老服务器上不再使用的实例
到现在，理论上覆盖了Redis分区，但是实际中怎么样？你会使用什么方案？
不幸的是，Redis集群现在还不能在生产环境使用，但是可以阅读规范或了解现在不稳定分支的部分实现，以获得更多相关信息。
一旦Redis集群可用，并且Redis集群兼容客户端在你所用编程语言中可用，Redis集群会成为事实上的Redis分区标准。
Redis集群是一种查询录用和客户端分区的混合解决方案。
Twemproxy 是Twitter为Memchache ASCII和Redis协议开发的一个代理。单线程，C语言开发，非常快。基于Apache 2.0 license的开源软件。
Twemproxy支持自动在多个Redis实例间自动分区，节点不可用时可以屏蔽（这会改变key和实例映射关系，应该在将Redis做为cache使用时才用这项特性）。
没有单点故障，因为你可以启动多个代理引导客户端连接首先接受连接的那个。
基本上，Twemproxy是一个介于客户端和Redis实例之间的中间层，用最小的额外复杂度来可靠的分区。目前是处理Redis分区的推荐方式。
可以通过这篇blog了解更多关于Twemproxy的信息。
Twemproxy的可选方案是，使用使用一致性 hash或类似算法的客户端分区。有多个Redis客户端都支持一致性hash，特别是Redis-rb和Predis。
查看完整的Redis客户端列表，以检查是否有你使用的编程语言的实现一致性hash的合适客户端。
原文地址：Redis分区方案, 感谢原作者分享。
