时间:2021-07-01 10:21:17 帮助过:2人阅读
最近在学习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分区方案, 感谢原作者分享。