Redis核心技术及实战(九.解决大数据量问题)

九:cluster集群——解决大数据量问题

原文:《09丨切片集群:数据增多了,是该加内存还是加实例?》

Redis要保存大量数据怎么办?

  • 纵向扩展:升级单个Redis实例的资源配置,如增加内存容量、高配置CPU等。但是,当数据量特别大时,硬盘会很难支撑,而且,一个实例中的数据太多,在fork子进程保存快照时就会严重阻塞主线程。
  • 横向扩展:切片集群,使用多个Redis实例存储数据。这时,会有两个问题:数据切片后,怎么在多个实例间分布?客户端怎么确定想要访问的数据在哪个实例上?

1. 数据切片和实例的对应分布关系

在Redis 3.0之前,并没有官方的集群方法,可以使用一致性哈希方法(哈希环)部署集群。

在Redis 3.0之后,官方集群采用**哈希槽(Hash Slot)**方法来处理数据和实例之间的映射关系。

**哈希槽:**一个切片集群共有16384个槽,把这些槽分给所有实例,读写数据时,每一个键值都会根据它的key被映射到一个槽中(对key使用CRC16算法计算得到一个值,然后对16384取余,得到的结果就是槽号)。

那么槽是怎么分给实例呢?

  • 平均分配
  • 如果每个实例的配置不同,可以手动给各个实例分配槽的数量(注意一定要把所有槽都给分配完)

2. 客户端如何定位数据

在定位键值位置的时候,可以计算得到槽号,但是怎么知道这个槽号是在哪个实例呢? => 最开始创建集群的时候,每个实例只知道自己有哪些槽,然后各个实例之间会互相发送槽信息,这样所有实例都拥有全部的槽分布信息,然后客户端和Redis实例建立连接后,Redis实例会把哈希槽的分配信息发给客户端,客户端把哈希槽信息给缓存起来,之后就知道该去哪里读写数据了。

但是,在集群中,如果有实例的增删,Redis集群为了负载均衡就要重新分配哈希槽。集群实例之间互相传递消息获得最新的哈希槽信息,但是客户端是无法主动感知到这些变化的,这就导致客户端缓存的分配信息和最新的分配信息不一致了。 => 重定向机制

重定向机制:客户端在给实例发送数据读写操作请求的时候,这个实例并没有相应数据,会返回给客户端MOVED/ASK命令,客户端要再给新的实例发送数据。

  • MOVED命令,原本位于该实例的数据所在槽已经全部移到了新的实例,MOVED会包含该数据所在槽号以及新实例的ip地址,客户端收到MOVED命令后,就会给新实例发送请求,并把缓存中的分配信息给更新过来
  • ASK命令,原文位于该实例的数据所在的槽只有一部分转移到了新实例,另一部分还没有转移过去,ASK命令会包含该槽号和新实例的ip地址,客户端会给新实例发送请求,但是并不会更新缓存(因为还有部分数据仍再原来实例中)。
  • 1
    点赞
  • 0
    收藏
  • 打赏
    打赏
  • 0
    评论
©️2022 CSDN 皮肤主题:深蓝海洋 设计师:CSDN官方博客 返回首页
评论

打赏作者

ZYLer_

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值