全是干货的技术号: 本文已收录在github,欢迎 star/fork: https://github.com/Wasabi1234/Java-Interview-Tutorial
分片,Redis 数据的分布方式,分片就是将数据拆分到多个 Redis 实例,这样每个实例将只是所有键的一个子集。
随着请求量和数据量的增加,一台机器已无法满足需求,就需要把数据和请求分散到多台机器,这就需要引入分布式存储。
分布式存储首先要解决把整个数据集按分区规则映射到多个节点的问题,即把数据集划分到多个节点,每个节点负责整体数据的一个子集:
假设:
有如下方案可映射键到指定 Redis 节点。
也叫顺序分区,最简单的分区方式。通过映射对象的范围到指定的 Redis 实例来完成分片。
传统分布式算法,适于任何键,不必是 object_name:<id>
形式:
20 个数据
数据分布
数据分布
蓝色表与4个节点时是相同的槽。
可见,redis0只有20命中、redis1只有1命中、redis2只有2命中、redis3只有3命中。最终命中率是: 4/20=20%
当添加一个节点时
客户端分片:哈希+取余。 节点伸缩:数据节点关系变化,导致数据迁移。迁移数量和添加节点数量有关:建议翻倍扩容。 优点:实现简单 缺点:当扩容或收缩节点时,需要迁移的数据量大(虽然翻倍扩容可以相对减少迁移量)
2^32
个桶的空间,即(0 ~ 2^32
- 1)的数字空间中。将这些数字头尾相连,想象成一个闭合环形:
基本思想就是将对象和cache都映射到同一个hash数值空间中, 并且使用相同的hash算法
hash(cache A) = key A;
hash(cache C) = key C;
在移除 or 添加一个 cache 时,能够尽可能小的改变已存在的 key 映射关系
现实却很拥挤-即倾斜性:
为解决该问题,引入虚拟节点
命中率计算公式:服务器台数n,新增服务器数m
(1 - n/(n + m) ) * 100%
客户端分片:哈希+顺时针(优化取余) 节点伸缩:只影响邻近节点,但还是有数据迁移 翻倍伸缩:保证最小迁移数据和负载均衡
哈希分片的一种高端形式称为一致性哈希(consistent hashing),被一些 Redis 客户端和代理实现。
可由软件栈中的不同部分来承担。
客户端直接选择正确节点来写入和读取指定键,许多 Redis 客户端实现了客户端分片。
客户端发送请求到一个可以理解 Redis 协议的代理上,而不是直接发送到 Redis 实例。代理会根据配置好的分片模式,来保证转发我们的请求到正确的 Redis 实例,并返回响应给客户端。 Redis 和 Memcached 的代理 Twemproxy 都实现了代理协助的分片。
可发送你的查询到一个随机实例,该实例会保证转发你的查询到正确节点。 Redis 集群在客户端的帮助下,实现了查询路由的一种混合形式,请求不是直接从 Redis 实例转发到另一个,而是客户端收到重定向到正确的节点。
Redis 的一些特性与分片在一起时玩的不是很好:
尽管无论是将 Redis 作为数据存储还是缓存,Redis 分片概念上都是一样的。
一致性哈希实现常常能够在指定键的首选节点不可用时切换到其它节点。类似的,如果你添加一个新节点,部分数据就会开始被存储到这个新节点上。
主要概念:
分片存在一个问题,除非我们使用 Redis 作为缓存,否则增加和删除节点都是件麻烦事,而使用固定的键和实例映射要简单得多。
然而,数据存储的需求可能一直在变化。今天可接受 10 个 Redis 节点,但明天可能就需 50 个节点。
因为 Redis 只有相当少的内存占用且轻量级(一个空闲的实例只使用 1MB 内存),一个简单的解决办法是一开始就开启很多实例。即使你一开始只有一台服务器,也可以在第一天就决定生活在分布式世界,使用分片来运行多个 Redis 实例在一台服务器上。 你一开始就可以选择很多数量的实例。例如,32 或者 64 个实例能满足大多数用户,并且为未来的增长提供足够的空间。 这样,当数据存储增长,需要更多 Redis 服务器,你要做的就是简单地将实例从一台服务器移动到另外一台。当你新添加了第一台服务器,你就需要把一半的 Redis 实例从第一台服务器搬到第二台,以此类推。
使用 Redis 复制,就可以在很小或者根本不需要停机的时间内完成移动数据:
Redis 集群是自动分片和高可用的首选方式。一旦 Redis 集群以及支持 Redis 集群的客户端可用,Redis 集群将会成为 Redis 分片的事实标准。
Redis 集群是查询路由和客户端分片的一种混合模式。
Twemproxy 是 Twitter 开发的一个支持 Memcached ASCII 和 Redis 协议的代理。它是单线程的,由 C 语言编写,运行非常快,基于 Apache 2.0 许可证。
Twemproxy 支持在多个 Redis 实例间自动分片,若节点不可用,还有可选的节点排除支持。 这会改变 <键,实例> 映射,所以应该只在将 Redis 作为缓存是才使用该特性。
这并非单点故障,因为你可启动多个代理,并且让你的客户端连接到第一个接受连接的代理。
从根本上说,Twemproxy 是介于客户端和 Redis 实例之间的中间层,这就可以在最下的额外复杂性下可靠地处理我们的分片。这是当前建议的处理 Redis 分片的方式。
Twemproxy 之外的可选方案,是使用实现了客户端分片的客户端,通过一致性哈希或者别的类似算法。有多个支持一致性哈希的 Redis 客户端,例如 Redis-rb 和 Predis。 查看完整的 Redis 客户端列表,看看是不是有支持你的编程语言的,并实现了一致性哈希的成熟客户端即可。
参考