分区在我的理解就是原本一个Redis处理所有的get/set请求，现在用多个Redis实例来分担get/set 请求。
- 为什么要使用分区？
- 扩容
- 提升计算能力，提高带宽
分区标准
- 范围分区
就是将不同范围的对象映射到不同Redis实例。比如说，用户ID从0到10000的都被存储到R0,用户ID从10001到20000被存储到R1,依此类推。
这是一种可行方案并且很多人已经在使用。但是这种方案也有缺点，你需要建一张表存储数据到redis实例的映射关系。这张表需要非常谨慎地维护并且需要为每一类对象建立映射关系，所以redis范围分区通常并不像你想象的那样运行，比另外一种分区方案效率要低很多。 - Hash分区
1. 使用散列函数 (如 crc32 )将键名称转换为一个数字。例：键foobar, 使用crc32(foobar)函数将产生散列值93024922。
2. 对转换后的散列值进行取模，以产生一个0到3的数字，以便可以使这个key映射到4个Redis实例当中的一个。93024922 % 4 等于 2, 所以 foobar 会被存储到第2个Redis实例。 R2 注意: 对一个数字进行取模，在大多数编程语言中是使用运算符%
分区的实现方案
- 客户端分区
就是由客户端自己决定要将Key存放在哪个实例，再去哪个实例获取 - 代理分区
客户端依赖一个代理，代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy - 查询路由
客户端随机地请求任意一个redis实例，然后由Redis将请求转发给正确的Redis节点
分区的缺点
- 涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，多个Key的事务
- 备份/恢复 复杂化
- 分区使用的粒度是key，zset 功能受到限制
- 扩容和缩容操作复杂
用作缓存和持久化分区的不同
使用途径不一样Redis分区的实现还是有点不一样的。当把Redis当做一个持久化存储时，一个key必须严格地每次被映射到同一个Redis实例。当把Redis当做一个缓存时，即使Redis的其中一个节点不可用,就算数据发生了丢失，我们还可以去Mysql等数据库拉取数据，淡然我们可用任意的规则更改映射，提高系统的高可用性，比如使用一致性Hash算法，这种方法能够实现当一个key的首选的节点不可用时切换至其他节点。同样地，如果你增加了一个新节点，立刻就会有新的key被分配至这个新节点。
- 重要结论如下:
- 如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。
- 如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样 - Redis 集群已经可用 2015.4.1.
预分片
如果我们要将Redis作为持久化，一般情况下随着时间的推移，数据存储需求总会发生变化。今天可能10个Redis节点就够了，但是明天可能就需要增加到50个节点，这是十分麻烦的。为防止以后的扩容，最好的办法就是一开始就启动较多实例。即便你只有一台服务器，你也可以一开始就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例（伪集群）。
一开始就多设置几个Redis实例，例如32或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。
这样的话，当你的数据不断增长，需要更多的Redis服务器时，你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已（而不用考虑重新分区的问题）。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。
大概的操作步骤是这样：
- 启动一个空的实例
new在另外一台机子上； - 把
new配置为你的的源实例（要扩容的实例）的从节点； - 关闭客户端
- 更改客户端的配置（连接到新机子的Ip）
- 将
new设置为主节点SLAVEOF NO ONE - 重启客户端
- 关闭源实例
分区的可选方案
- 首选Redis Cluster
- 使用推特开源的代理
twemproxy - 使用支持一致性哈希的客户端
