本文转载自[url]http://skynetdoc.com/?p=119[/url]
本人顺便修正了一些文字上的复制粘贴小错误，以及更新了一些文字以和英文版保持一致。
Partitioning 能够将你的数据发布在多个redis node(node和instance一个意思)上，因此每一个node仅仅保存了你keys的一个subset。这个文档的第一部分将会给你介绍Partitioning 的概念，第二部分将会描述Redis Partitioning可供选择的方案。
[b]为什么Partitioning 是有用的?[/b]
redis Partitioning 主要有2个目标:1.通过使用多台计算机的内存总和使得我们可以得到一个更大的数据库。如果不使用partitioning 将局限于单台计算机的内存限制。2.它能够测试多核机器和多计算机的计算能力，以及多台机器的网络带宽和网络适配器问题。
[b]Partitioning 的基本要素[/b]
有一些不同的Partitioning 算法。假设我们有redis node [b]R0, R1, R2, R3[/b],并且有许多keys代表users比如user:1, user:2…等等。我们可以使用不同的方式来选择node保存key。换句话说，可以采用不同的方式来实现key-redis_node之间的映射。一个简单的实现叫[b]range partitioning[/b]，在objects范围内映射到特殊的redis_node。例如，可以将users ID [0, 10000]映射到R0，users ID[10001, 20000]映射到R1…等等。这种实现实际上有被使用，但是这里有个缺点是这里将这个table的范围映射到了redis_node上。因此，这个table需要你手工去管理，需要包含我们有的各种类型。一般来讲对于redis这不是一个好的主意。
另外一种可供选择的策略是 [b]hash partitioning[/b]。这种策略可以用于任何key，并且不需要一个由object_name:id组成的key，更加简单。1.使用一个hash函数将一个key_name转换成一个number。例如，我使用crc32哈希函数，对于key_name foobar: -> crc32(foobar)将输入类似于93024922的值。2.我对这个计算出来的number进行取模运算得到[0, 3]的值，这样我就可以将这个number映射到4个redis_node之一了。93024922 %4 = 2，因此 key_name foobar就应该被存储在R2 redis_node里面。NOTE: %仅仅是除法运算的余数，在很多编程语言中通常它被实现为%操作符。
还有其他一些partitioning的实现方法，但是看了这2种你应该有想法了。其中一个哈希partitioning 叫做[b]consistent hashing(一致性哈希算法)[/b]，并且它被一些redis 的clients和proxies所实现。
[b]partitioning不同的实现[/b]
Partitioning由一个软件栈的不同部分所负责
· [b]Client side partitioning[/b] 这种方法意味着客户端在在读写key的时候，直接选择一个正确的redis_node。许多redis client都实现了这种方法。
· [b]Proxy assisted partitioning[/b] 这种方法client发送请求到proxy而不是直接发送到redis_node，proxy能够解析redis协议。proxy能够根据预先配置好的 partitioning schema将请求发送到正确的redis_node，并且将redis_node的返回发送给client。Redis和Memcached proxy[url=https://github.com/twitter/twemproxy]Twemproxy[/url]实现了proxy assisted partitioning。
· [b]Query routing[/b] 这种方法你将你的请求发送到一个随机的node，这个node会将你的请求发送到正确的node。redis Cluster(redis集群服务)实现了一个混合query routing，实现依赖于client将请求从一个redis_node发送到另外一个，但是返回的时候是得到重定向的正确的node。
[b]partitioning的弊端[/b]
readis的一些特性在partitioning表现不是特别好
1.包含多个key的操作通常是不被支持的。例如：如果2个set它们保存的keys被映射到了不同的redis_node，你就不能再它们之间形成交叉。(事实上也有方法解决这个问题，只是不直接。)
2.包含多个keys的事务不被支持
3.由于分区的粒度是关键，所以不可能切分一个巨大的key，比如一个大型的排好序的set。
4.当partitioning被使用的时候，数据处理将更加复杂。比如，有些时候你需要处理多个RDB/AOF文件来恢复你的数据， 你需要从多个node或者多台机器上收集这些文件。
5.添加或者删除节点将变得复杂。例如，redis集群支持在运行时透明地添加和删除redis节点，但是其他像client side partitioning 和 proxies 都不支持这个特性。然而，一项叫做[b]Presharding[/b]技术 被考虑中。
[b]数据存储或者作为Cache？[/b]
对于Partitioning而言使用redis作为数据存储或者Cache是相同的概念，然而这里也有一个巨大的不同。当我们使用redis作为一个存储时你必须确保同一个key每次都映射到相同的redis_node, 但是如果你使用redis作为一个Cache，如果node不可用这不是什么大的问题，系统将使用一个不同的node，并且修改key-node之间的映射关系，这样将提高系统的可用性。这样系统就可以响应我们的请求。Consistent hashing经常用于解决node不可用的问题。同样地，如果你添加了一个新的节点，新keys将被存储在new node。主要的概念如下：
·如果redis被当做cache来用，使用一致性哈希算法来[b]scaling up and down[/b]是容易的。
·但是如果把redis作为存储数据的服务器，[b]就需要在key和节点之间实现一个map，节点的数量也必须固定。[/b]否则的话我们需要一个系统来维护key_nods之间的平衡，当我们添加或者删除nodes的时候。目前只有redis集群服务能做这个，但是目前集群服务还是beta版，还不足以在产品中使用它。
[b]Presharding技术[/b]
对于redis partitioning 上的一些问题，我们知道除非我们使用redis作为一个cahe这样add和remove nodes都是比较容易管理的，并且更加的简单的方法是使用归哪个的key-node映射。然而我们数据存储通常变化是很大的，今天我需要10个redis_nodes，明天我就可能需要50个。
因为redis node是非常轻量的(一个空闲的node仅仅使用1M内存)，所以一个简单的方案是可以在一开始就启动大量的node。你甚至可以在一台服务器上启动多个redis实例来达到partition的效果。
你可以一开始就选择一个大的数字作为redis的实例数量，比如，32或者64个nodes能解决大多数人的需求，并且对于空间的增长提供足够的需求。
这样当需要存储的数据增加，你需要更多的redis服务器，通过这种方式你可以简单的将这些nodes从一台服务器迁移到另一台。一旦你添加了新的服务器，你需要将redis node的一半数据迁移到新的服务器…等等。
使用redis的[b]replication（复制）[/b]功能，你可以使停机时间最小化甚至为零。
·在新的服务器上启动空的node
·配置这些新的nodes作为你原来node的从服务器（slaves）
·stop所有的clients
·更新那些被移动节点的配置，使用新的IP地址.
·发送命令 SLAVEOF NO ONE 到新的服务器上
·重启clients 使用新的配置
·关闭老服务器上那些很久没有使用的nodes
[b]Redis partitioning 的实现[/b]
到目前为止我们涵盖了Redis partitioning 的理论知识，但是实际中呢？你应该使用什么系统？
[b]redis 集群[/b]
Redis集群是推荐的方法，可以实现自动sharding和高可用性。现在处于beta阶段还没有发布，建议你可以开始尝试一下。你可以在[url=http://www.redis.io/topics/cluster-tutorial]Cluster tutorial[/url]得到更多的信息。（有中文版）
一旦redis的集群功能可用了，而且支持集群的客户端（相应语言的）也有了，实际上redis集群将成为Redis partitioning的事实标准。
redis集群是一个query routing 和 client side partitioning的混合实现。
[b]Twemproxy[/b]
[url=https://github.com/twitter/twemproxy]Twemproxy[/url]是Twitter开发的一个proxy，用于Redis 协议和Memcached ASCII 。它是c的单线程程序但是非常快。它支持自动的partitioning ，并且如果一个node不可用了可以剔除掉。(这会改变key-node的映射，因此你应该使用它，当把 redis作为一个Cach时)
[b]客户端支持consistent hashing[/b]
相对于Twemproxy，一种可供选择的方法是使用实现 client side partitioning的客户端(通过一致性哈希或者别的算法)。
比如著名的有[url=https://github.com/redis/redis-rb]Redis-rb[/url]（ruby） 和 [url=https://github.com/nrk/predis]Predis[/url]（php）
请检查[url=http://redis.io/clients]完整的客户端列表[/url]，看一下你需要的语言的客户端是否实现了一致性哈希算法。
本人顺便修正了一些文字上的复制粘贴小错误，以及更新了一些文字以和英文版保持一致。
Partitioning 能够将你的数据发布在多个redis node(node和instance一个意思)上，因此每一个node仅仅保存了你keys的一个subset。这个文档的第一部分将会给你介绍Partitioning 的概念，第二部分将会描述Redis Partitioning可供选择的方案。
[b]为什么Partitioning 是有用的?[/b]
redis Partitioning 主要有2个目标:1.通过使用多台计算机的内存总和使得我们可以得到一个更大的数据库。如果不使用partitioning 将局限于单台计算机的内存限制。2.它能够测试多核机器和多计算机的计算能力，以及多台机器的网络带宽和网络适配器问题。
[b]Partitioning 的基本要素[/b]
有一些不同的Partitioning 算法。假设我们有redis node [b]R0, R1, R2, R3[/b],并且有许多keys代表users比如user:1, user:2…等等。我们可以使用不同的方式来选择node保存key。换句话说，可以采用不同的方式来实现key-redis_node之间的映射。一个简单的实现叫[b]range partitioning[/b]，在objects范围内映射到特殊的redis_node。例如，可以将users ID [0, 10000]映射到R0，users ID[10001, 20000]映射到R1…等等。这种实现实际上有被使用，但是这里有个缺点是这里将这个table的范围映射到了redis_node上。因此，这个table需要你手工去管理，需要包含我们有的各种类型。一般来讲对于redis这不是一个好的主意。
另外一种可供选择的策略是 [b]hash partitioning[/b]。这种策略可以用于任何key，并且不需要一个由object_name:id组成的key，更加简单。1.使用一个hash函数将一个key_name转换成一个number。例如，我使用crc32哈希函数，对于key_name foobar: -> crc32(foobar)将输入类似于93024922的值。2.我对这个计算出来的number进行取模运算得到[0, 3]的值，这样我就可以将这个number映射到4个redis_node之一了。93024922 %4 = 2，因此 key_name foobar就应该被存储在R2 redis_node里面。NOTE: %仅仅是除法运算的余数，在很多编程语言中通常它被实现为%操作符。
还有其他一些partitioning的实现方法，但是看了这2种你应该有想法了。其中一个哈希partitioning 叫做[b]consistent hashing(一致性哈希算法)[/b]，并且它被一些redis 的clients和proxies所实现。
[b]partitioning不同的实现[/b]
Partitioning由一个软件栈的不同部分所负责
· [b]Client side partitioning[/b] 这种方法意味着客户端在在读写key的时候，直接选择一个正确的redis_node。许多redis client都实现了这种方法。
· [b]Proxy assisted partitioning[/b] 这种方法client发送请求到proxy而不是直接发送到redis_node，proxy能够解析redis协议。proxy能够根据预先配置好的 partitioning schema将请求发送到正确的redis_node，并且将redis_node的返回发送给client。Redis和Memcached proxy[url=https://github.com/twitter/twemproxy]Twemproxy[/url]实现了proxy assisted partitioning。
· [b]Query routing[/b] 这种方法你将你的请求发送到一个随机的node，这个node会将你的请求发送到正确的node。redis Cluster(redis集群服务)实现了一个混合query routing，实现依赖于client将请求从一个redis_node发送到另外一个，但是返回的时候是得到重定向的正确的node。
[b]partitioning的弊端[/b]
readis的一些特性在partitioning表现不是特别好
1.包含多个key的操作通常是不被支持的。例如：如果2个set它们保存的keys被映射到了不同的redis_node，你就不能再它们之间形成交叉。(事实上也有方法解决这个问题，只是不直接。)
2.包含多个keys的事务不被支持
3.由于分区的粒度是关键，所以不可能切分一个巨大的key，比如一个大型的排好序的set。
4.当partitioning被使用的时候，数据处理将更加复杂。比如，有些时候你需要处理多个RDB/AOF文件来恢复你的数据， 你需要从多个node或者多台机器上收集这些文件。
5.添加或者删除节点将变得复杂。例如，redis集群支持在运行时透明地添加和删除redis节点，但是其他像client side partitioning 和 proxies 都不支持这个特性。然而，一项叫做[b]Presharding[/b]技术 被考虑中。
[b]数据存储或者作为Cache？[/b]
对于Partitioning而言使用redis作为数据存储或者Cache是相同的概念，然而这里也有一个巨大的不同。当我们使用redis作为一个存储时你必须确保同一个key每次都映射到相同的redis_node, 但是如果你使用redis作为一个Cache，如果node不可用这不是什么大的问题，系统将使用一个不同的node，并且修改key-node之间的映射关系，这样将提高系统的可用性。这样系统就可以响应我们的请求。Consistent hashing经常用于解决node不可用的问题。同样地，如果你添加了一个新的节点，新keys将被存储在new node。主要的概念如下：
·如果redis被当做cache来用，使用一致性哈希算法来[b]scaling up and down[/b]是容易的。
·但是如果把redis作为存储数据的服务器，[b]就需要在key和节点之间实现一个map，节点的数量也必须固定。[/b]否则的话我们需要一个系统来维护key_nods之间的平衡，当我们添加或者删除nodes的时候。目前只有redis集群服务能做这个，但是目前集群服务还是beta版，还不足以在产品中使用它。
[b]Presharding技术[/b]
对于redis partitioning 上的一些问题，我们知道除非我们使用redis作为一个cahe这样add和remove nodes都是比较容易管理的，并且更加的简单的方法是使用归哪个的key-node映射。然而我们数据存储通常变化是很大的，今天我需要10个redis_nodes，明天我就可能需要50个。
因为redis node是非常轻量的(一个空闲的node仅仅使用1M内存)，所以一个简单的方案是可以在一开始就启动大量的node。你甚至可以在一台服务器上启动多个redis实例来达到partition的效果。
你可以一开始就选择一个大的数字作为redis的实例数量，比如，32或者64个nodes能解决大多数人的需求，并且对于空间的增长提供足够的需求。
这样当需要存储的数据增加，你需要更多的redis服务器，通过这种方式你可以简单的将这些nodes从一台服务器迁移到另一台。一旦你添加了新的服务器，你需要将redis node的一半数据迁移到新的服务器…等等。
使用redis的[b]replication（复制）[/b]功能，你可以使停机时间最小化甚至为零。
·在新的服务器上启动空的node
·配置这些新的nodes作为你原来node的从服务器（slaves）
·stop所有的clients
·更新那些被移动节点的配置，使用新的IP地址.
·发送命令 SLAVEOF NO ONE 到新的服务器上
·重启clients 使用新的配置
·关闭老服务器上那些很久没有使用的nodes
[b]Redis partitioning 的实现[/b]
到目前为止我们涵盖了Redis partitioning 的理论知识，但是实际中呢？你应该使用什么系统？
[b]redis 集群[/b]
Redis集群是推荐的方法，可以实现自动sharding和高可用性。现在处于beta阶段还没有发布，建议你可以开始尝试一下。你可以在[url=http://www.redis.io/topics/cluster-tutorial]Cluster tutorial[/url]得到更多的信息。（有中文版）
一旦redis的集群功能可用了，而且支持集群的客户端（相应语言的）也有了，实际上redis集群将成为Redis partitioning的事实标准。
redis集群是一个query routing 和 client side partitioning的混合实现。
[b]Twemproxy[/b]
[url=https://github.com/twitter/twemproxy]Twemproxy[/url]是Twitter开发的一个proxy，用于Redis 协议和Memcached ASCII 。它是c的单线程程序但是非常快。它支持自动的partitioning ，并且如果一个node不可用了可以剔除掉。(这会改变key-node的映射，因此你应该使用它，当把 redis作为一个Cach时)
[b]客户端支持consistent hashing[/b]
相对于Twemproxy，一种可供选择的方法是使用实现 client side partitioning的客户端(通过一致性哈希或者别的算法)。
比如著名的有[url=https://github.com/redis/redis-rb]Redis-rb[/url]（ruby） 和 [url=https://github.com/nrk/predis]Predis[/url]（php）
请检查[url=http://redis.io/clients]完整的客户端列表[/url]，看一下你需要的语言的客户端是否实现了一致性哈希算法。
扫一扫
1257
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
