切片集群
我曾遇到过这么一个需求:要用 Redis 保存 5000 万个键值对,每个键值对大约是 512B,为了能快速部署并对外提供服务,我们采用云主机来运行 Redis 实例,那么,该如何选择云主机的内存容量呢?
在使用的过程中,我发现,Redis 的响应有时会非常慢。后来,我们使用 INFO 命令查看 Redis 的 latest_fork_usec 指标值(表示最近一次 fork 的耗时),结果显示这个指标值特别高,快到秒级别了。这跟 Redis 的持久化机制有关系。在使用 RDB 进行持久化时,Redis 会 fork 子进程来完成,fork 操作的用时和 Redis 的数据量是正相关的,而 fork 在执行时会阻塞主线程。数据量越大,fork 操作造成的主线程阻塞的时间越长。所以,在使用 RDB 对 25GB 的数据进行持久化时,数据量较大,后台运行的子进程在 fork 创建时阻塞了主线程,于是就导致 Redis 响应变慢了。
这个时候,我们注意到了 Redis 的切片集群。虽然组建切片集群比较麻烦,但是它可以保存大量数据,而且对 Redis 主线程的阻塞影响较小。
切片集群,也叫分片集群,就是指启动多个 Redis 实例组成一个集群,然后按照一定的规则,把收到的数据划分成多份,每一份用一个实例来保存;
在切片集群中,实例在为 5GB 数据生成 RDB 时,数据量就小了很多,fork 子进程一般不会给主线程带来较长时间的阻塞。采用多个实例保存数据切片后,我们既能保存 25GB 数据,又避免了 fork 子进程阻塞主线程而导致的响应突然变慢。在实际应用 Redis 时,随着用户或业务规模的扩展,保存大量数据的情况通常是无法避免的。而切片集群,就是一个非常好的解决方案。这节课,我们就来学习一下
Redis 数据量增多处理
Redis 应对数据量增多的两种方案:纵向扩展(scale up)和横向扩展(scale out)
纵向扩展:升级单个 Redis 实例的资源配置,包括增加内存容量、增加磁盘容量、使用更高配置的 CPU。就像下图中,原来的实例内存是 8GB,硬盘是 50GB,纵向扩展后,内存增加到 24GB,磁盘增加到 150GB。
横向扩展:横向增加当前 Redis 实例的个数,就像下图中,原来使用 1 个 8GB 内存、50GB 磁盘的实例,现在使用三个相同配置的实例。
-
纵向扩展好处和缺点
首先,纵向扩展的好处是,实施起来简单、直接。不过,这个方案也面临两个潜在的问题。第一个问题是,当使用 RDB 对数据进行持久化时,如果数据量增加,需要的内存也会增加,主线程 fork 子进程时就可能会阻塞(比如刚刚的例子中的情况)。不过,如果你不要求持久化保存 Redis 数据,那么,纵向扩展会是一个不错的选择。 -
纵向扩展好处和缺点
这时,你还要面对第二个问题:纵向扩展会受到硬件和成本的限制。这很容易理解,毕竟,把内存从 32GB 扩展到 64GB 还算容易,但是,要想扩充到 1TB,就会面临硬件容量和成本上的限制了。在面向百万、千万级别的用户规模时,横向扩展的 Redis 切片集群会是一个非常好的选择
数据切片后,在多个实例之间如何分布
客户端怎么确定想要访问的数据在哪个实例上?接下来,我们就一个个地解决
Redis Cluster 集群 哈希槽
从 3.0 开始,官方提供了一个名为 Redis Cluster 的方案,用于实现切片集群。Redis Cluster 方案中就规定了数据和实例的对应规则。
具体来说,Redis Cluster 方案采用哈希槽(Hash Slot,接下来我会直接称之为 Slot),来处理数据和实例之间的映射关系。在 Redis Cluster 方案中,一个切片集群共有 16384 个哈希槽,这些哈希槽类似于数据分区,每个键值对都会根据它的 key,被映射到一个哈希槽中。
首先根据键值对的 key,按照CRC16 算法计算一个 16 bit 的值;然后,再用这个 16bit 值对 16384 取模,得到 0~16383 范围内的模数,每个模数代表一个相应编号的哈希槽。
我们在部署 Redis Cluster 方案时,可以使用 cluster create 命令创建集群,此时,Redis 会自动把这些槽平均分布在集群实例上。例如,如果集群中有 N 个实例,那么,每个实例上的槽个数为 16384/N 个。
当然, 我们也可以使用 cluster meet 命令手动建立实例间的连接,形成集群,再使用 cluster addslots 命令,指定每个实例上的哈希槽个数。
在手动分配哈希槽时,需要把 16384 个槽都分配完,否则 Redis 集群无法正常工作
假设集群中不同 Redis 实例的内存大小配置不一,如果把哈希槽均分在各个实例上,在保存相同数量的键值对时,和内存大的实例相比,内存小的实例就会有更大的容量压力。遇到这种情况时,你可以根据不同实例的资源配置情况,使用 cluster addslots 命令手动分配哈希槽。
示意图中的切片集群一共有 3 个实例,同时假设有 5 个哈希槽,我们首先可以通过下面的命令手动分配哈希槽:实例 1 保存哈希槽 0 和 1,实例 2 保存哈希槽 2 和 3,实例 3 保存哈希槽 4。
redis-cli -h 172.16.19.3 –p 6379 cluster addslots 0,1
redis-cli -h 172.16.19.4 –p 6379 cluster addslots 2,3
redis-cli -h 172.16.19.5 –p 6379 cluster addslots 4
在集群运行的过程中,key1 和 key2 计算完 CRC16 值后,对哈希槽总个数 5 取模,再根据各自的模数结果,就可以被映射到对应的实例 1 和实例 3 上了
客户端如何定位数据
在定位键值对数据时,它所处的哈希槽是可以通过计算得到的,这个计算可以在客户端发送请求时来执行。但是,要进一步定位到实例,还需要知道哈希槽分布在哪个实例上。
一般来说,客户端和集群实例建立连接后,实例就会把哈希槽的分配信息发给客户端。但是,在集群刚刚创建的时候,每个实例只知道自己被分配了哪些哈希槽,是不知道其他实例拥有的哈希槽信息的。
那么,客户端为什么可以在访问任何一个实例时,都能获得所有的哈希槽信息呢?这是因为,Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例,来完成哈希槽分配信息的扩散。当实例之间相互连接后,每个实例就有所有哈希槽的映射关系了;
客户端收到哈希槽信息后,会把哈希槽信息缓存在本地。当客户端请求键值对时,会先计算键所对应的哈希槽,然后就可以给相应的实例发送请求了。
Redis 集群hash在分配
实例和哈希槽的对应关系并不是一成不变的,实例和哈希槽的对应关系并不是一成不变的,最常见的变化有两个(由于负载均衡)
集群中,实例有新增或删除,Redis 需要重新分配哈希槽;为了负载均衡,Redis 需要把哈希槽在所有实例上重新分布一遍。
实例之间还可以通过相互传递消息,获得最新的哈希槽分配信息,但是,客户端是无法主动感知这些变化的。这就会导致,它缓存的分配信息和最新的分配信息就不一致了,那该怎么办呢?
Redis Cluster 方案提供了一种重定向机制,所谓的“重定向”,就是指,客户端给一个实例发送数据读写操作时,这个实例上并没有相应的数据,客户端要再给一个新实例发送操作命令。
那客户端又是怎么知道重定向时的新实例的访问地址呢?当客户端把一个键值对的操作请求发给一个实例时,如果这个实例上并没有这个键值对映射的哈希槽,那么,这个实例就会给客户端返回下面的 MOVED 命令响应结果,这个结果中就包含了新实例的访问地址
GET hello:key
(error) MOVED 13320 172.16.19.5:6379
其中,MOVED 命令表示,客户端请求的键值对所在的哈希槽 13320,实际是在 172.16.19.5 这个实例上。通过返回的 MOVED 命令,就相当于把哈希槽所在的新实例的信息告诉给客户端了。这样一来,客户端就可以直接和 172.16.19.5 连接,并发送操作请求了。
在 Redis 3.0 之前,Redis 官方并没有提供切片集群方案,但是,其实当时业界已经有了一些切片集群的方案,例如基于客户端分区的 ShardedJedis,基于代理的 Codis、Twemproxy 等。这些方案的应用早于 Redis Cluster 方案,在支撑的集群实例规模、集群稳定性、客户端友好性方面也都有着各自的优势,我会在后面的课程中,专门和你聊聊这些方案的实现机制,以及实践经验。这样一来,当你再碰到业务发展带来的数据量巨大的难题时,就可以根据这些方案的特点,选择合适的方案实现切片集群,以应对业务需求了。
hash链
原理简介:
每个数据存储进来的时候,要根据hash算法,进行算值取余,存入到对应的机器中。取数据的时候,用同样的hash算法对key进行计算,即可取出数据。
应用场景:
Redis集群扩容或宕机缩减,那么就需要进行全库数据的重洗,hash取模的值调整。这样,就比较耗费时间。所以,该方案,要预先估计一下自己公司业务的数据量多大,服务器的存储能力多大,然后,考虑在扩容时,所需的时间多久,只要在允许的时间范围内,能够完成重洗数据,那就可以采取该方案。该方案的一个好处就是,简单。存数据简单,取数据简单,理解容易。
hash环
原理简介
上面说的Hash链,只经过了1次hash,即把key hash到对应的机器编号。
而Hash环有2次Hash:
(1)把所有机器编号hash到这个环上
(2)把key也hash到这个环上。然后在这个环上进行匹配,看这个key和哪台机器匹配。这样,每个机器负责对应段上的数据。
应用场景
当hash链性能满足不了公司业务数据量的时候,就要采取该方案进行性能提升。
当服务器缩减时,对应段数据向下游转移即可,这样,就不会影响到其他段服务器的数据。
当服务器扩容时,对应服务器下游的服务器数据要进行重洗,把部分数据转移到新扩容的服务器上即可。这样,在查找时,按照最新的hash算法取余,即可取出对应的数据。
这相较于hash链,进行全库冲洗,还是节省了很多
也就是说,hash链和hash环,在新增服务器的时候,都是要冲洗数据的,只是,hash链是全库冲洗(算法复杂度是N),hash环是下游节点冲洗(算法复杂度是1)
那么会有道友问,我直接上第二种方案不就得了。这显然是不行的。
原因:
hash环是有大小的,它的特点是把hash链首尾相连,那么,假设你公司业务只有百万级数据量,你设置成一个hash环。假设,hash环周长是100,小厂有4台服务器,第一次可以人为均匀分布到环上,但是,如果业务量数据增加,导致需要扩容。这时候,如果你对hash环进行扩周长,如果不重新分配服务器在环上的位置,那就会出现数据倾斜问题,如果,重新均匀分布服务器在环上的位置,那么,就要全库重洗数据。所以,这样就和hash链没什么区别。还多出一个数据倾斜问题。
那么有道友就说了,那我把hash环周长设置的超大。这样,不就可以减轻扩容时,数据倾斜问题的严重性了吗?并不是这样,当你保持环周长不变的前提下扩容的时候,数据倾斜和环的周长并没有关系。只是和你扩容的服务器策略有关,就是,假设第一次设置4台服务器,那么,你扩容的服务器必须是2的N次方台,这样才能人为的避免数据倾斜。那么,你小厂有这个实力吗?显然没有,不划算。
另外,你的环周长越大,也就意味着取余的除数越大,那么,计算取余的时间就越久,比如,你对2取余,口算即可。你对2的32次方取余,那就要多用很多时间,这样,随着积累,你浪费的时间就很多了。相对于公司业务,数据量不大,但是,损耗的计算时间却很多,那就很不划算了。所以,环的周长也是要考虑的点。
所以,使用hash环算法,要考虑两点
1、公司自身实力,每次扩容需要的服务器数据量是:a*2^n。其中,a是第一次均匀分布的服务器数据量,n>=0的整数。这个扩容方法,解决数据倾斜问题。
2、hash环周长大小选择。周长越大,计算越耗费时间。所以,要根据公司业务量大小,选择合理的周长大小,不能太小,否则经常扩容,不能太大,浪漫每次的取余时间。
3、数据倾斜问题的本质,就在于服务器节点在环上的分布是否均匀还是密集。分布密集了,那就会出现数据倾斜问题。