Redis进阶-分布式存储 Sequential partitioning & Hash partitioning

简介: Redis进阶-分布式存储 Sequential partitioning & Hash partitioning


分布式存储

了解Redis集群原理之前我们先来梳理一下分布式存储的相关知识

拆分在算法中是一个非常重要的思想,当你的数据集巨大时,你可以按照特定的规则将大数据拆分成小数据集,降低因数据量增长过大带来的问题。

基本方案有两种:顺序分布 & 哈希分布 。 需要根据具体业务选择分片方式

数据分区虽好 ,但是有没有哪些棘手的问题要处理呢? 当然有了,比如

  • 自动负载均衡
    分布式存储系统需要自动识别负载高的节点,当某台机器的负载高时,自动将其上的部分数据迁移到其他机器。
  • 一致性
    分片后数据可能分布在不同存储服务器上,无法使用数据库自带的单机事务,需通过分布式应用事务一致性模型来解决

顺序分区 Sequential partitioning

从名字上也很好理解顺序分布的含义, 就是将大表按一定顺序划分为连续的子表,然后将子表按一定策略分配到存储节点上。

举个简单的例子

优点呢?

  1. 可顺序读

缺点呢?

  1. 数据可能分布不均匀
  2. 数据量大的时候,为了性能 ,需要使用索引来记录子表信息

哈希分区 Hash partitioning

方案总览

节点取余分区 Hashing

通过数据的某个特征计算哈希值,并将哈希值与集群中的服务器建立映射关系,从而将不同数据分布到不同服务器上。

hash(object) % N

举个例子:

假设这个时候我要添加一个节点 ,我们拿 1-10 来说,来计算下从3个节点到4个节点的迁移率

先 1 % 3 , 2 % 3 … 10 % 3 , 算出来 在哪个分区,如下图左侧 (0 ,1 ,2 三个分区)

重新对4进行 1 %4 , 2 % 4 … 10 % 4, 计算后 ,如右侧

比对一下, 只有 1 (分区0) 和 2 (分区1) 这两个值 还在原来的分区里 ,其余8个数字 都迁移到了其他的分区中。

解释下迁移率 是指: 你的这个缓存区域中已经没有数据了,需要DB查询,回写到缓存,80%的数据都要这样重新构建…


咋解决呢?

稍微挫一点的方案 翻倍扩容 ,迁移率可以降低到 50%

我们还是那1-10 这10个数字,3个分区变6个分区来计算下迁移率

原来1 % 3 , 2 % 3 … 10 % 3 , 算出来 在哪个分区

翻倍扩容 重新对6进行 1 %6 , 2 % 6 … 10 % 6, 计算

建议: 看场景,如果你的业务对缓存依赖没这没强,查不到从DB查就是,并发也不高,也不是不可以,毕竟这个最简单。

当然了,最好不用,太古老


一致性哈希分区 Consistent hashing

刚才根据节点数量来分区的方式,缺点也看到了,迁移率太高。 刚才的翻倍扩容的方案也差强人意,有没有更好的呢? 那就是 Consistent hashing

我们使用 哈希环来解决 slot 数发生变化时,尽量减少数据的移动。

一致性哈希算法在1997年由麻省理工学院的Karger等人在解决分布式Cache中提出的.

初始化

  • 首先求出节点 的哈希值 (比如可以选择服务器的ip或主机名作为关键字进行哈希),并将其配置到0~2^32的环上
  • 然后采用同样的方法求出存储数据的键的哈希值,并映射到相同的环上
  • 紧接着从数据映射到的位置开始顺时针查找,将数据保存到找到的第一个服务器上。
  • 如果超过2^32仍然找不到服务器,就会保存到第一个节点上

节点的扩容与缩容

节点取余的算法当节点动态的调整大大的影响缓存的命中率,但Consistent Hashing中,只有在环上增加服务器的地点逆时针方向的第一个节点上的键会受到影响

举个例子: 假设我们要在node1 和 node2 之间 增加一个 node5节点,看看哪些数据会受到影响?

增加node5 后

是不是 右上方的 两条数据 你下次再查找的时候 ,你会去node5找 (因为这两条数据的下一个节点是node5 ,已经不是node2了),找不到,失效了,会重新从数据源获取,重新构建。

仍然存在小规模的失效,但比第一种hash算法,如果节点很多,这种影响的数据范围降低了很多。

总结下 :

  1. 客户端分片: hash + 顺时针(优化取余)
  2. 节点伸缩:只影响邻近节点,但是还有数据迁移
  3. 翻倍伸缩: 保证最小迁移数据和负债均衡 , 这个其实还是有可能数据分部不均匀,比如你4个节点,大部分的key做hash以后,有可能集中在node1 和 nod2上,node3 和 node4 只有少量的数据,所以还是建议翻倍扩容。 这个就是我们常说的: 服务节点少时数据倾斜的问题

综上所述,一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。

另外,一致性哈希算法在服务节点太少时,容易因为节点分部不均匀而造成数据倾斜问题


虚拟哈希分区

为了解决一致性hash在节点数量比较少的情况下出现数据倾斜问题,一致性哈希算法引入了虚拟节点机制,即对每一个服务节点计算多个哈希,每个计算结果位置都放置一个此服务节点,称为虚拟节点。

如何搞这些虚拟节点呢? 可以在服务器ip或主机名的后面增加编号来实现。例如上面的情况,可以为每台服务器计算三个虚拟节点,于是可以分别计算 “Node A#1”、“Node A#2”、“Node A#3”、“Node B#1”、“Node B#2”、“Node B#3”的哈希值,于是形成六个虚拟节点:

同时数据定位算法不变,只是多了一步虚拟节点到实际节点的映射,例如定位到“Node A#1”、“Node A#2”、“Node A#3”三个虚拟节点的数据均定位到Node A上。

这样就解决了服务节点少时数据倾斜的问题。在实际应用中,通常将虚拟节点数设置为32甚至更大,因此即使很少的服务节点也能做到相对均匀的数据分布。

import java.util.Collection;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Set;
import java.util.SortedMap;
import java.util.SortedSet;
import java.util.TreeMap;
import java.util.TreeSet;
public class ConsistentHash<T> {
    private final int numberOfReplicas;// 节点的复制因子,实际节点个数 * numberOfReplicas =
    // 虚拟节点个数
    private final SortedMap<Integer, T> circle = new TreeMap<Integer, T>();// 存储虚拟节点的hash值到真实节点的映射
    public ConsistentHash( int numberOfReplicas,
                           Collection<T> nodes) {
        this.numberOfReplicas = numberOfReplicas;
        for (T node : nodes){
            add(node);
        }
    }
    public void add(T node) {
        for (int i = 0; i < numberOfReplicas; i++){
            // 对于一个实际机器节点 node, 对应 numberOfReplicas 个虚拟节点
            /*
             * 不同的虚拟节点(i不同)有不同的hash值,但都对应同一个实际机器node
             * 虚拟node一般是均衡分布在环上的,数据存储在顺时针方向的虚拟node上
             */
            String nodestr =node.toString() + i;
            int hashcode =nodestr.hashCode();
            System.out.println("hashcode:"+hashcode);
            circle.put(hashcode, node);
        }
    }
    public void remove(T node) {
        for (int i = 0; i < numberOfReplicas; i++)
            circle.remove((node.toString() + i).hashCode());
    }
    /*
     * 获得一个最近的顺时针节点,根据给定的key 取Hash
     * 然后再取得顺时针方向上最近的一个虚拟节点对应的实际节点
     * 再从实际节点中取得 数据
     */
    public T get(Object key) {
        if (circle.isEmpty())
            return null;
        int hash = key.hashCode();// node 用String来表示,获得node在哈希环中的hashCode
        System.out.println("hashcode----->:"+hash);
        if (!circle.containsKey(hash)) {//数据映射在两台虚拟机器所在环之间,就需要按顺时针方向寻找机器
            SortedMap<Integer, T> tailMap = circle.tailMap(hash);
            hash = tailMap.isEmpty() ? circle.firstKey() : tailMap.firstKey();
        }
        return circle.get(hash);
    }
    public long getSize() {
        return circle.size();
    }
    /*
     * 查看表示整个哈希环中各个虚拟节点位置
     */
    public void testBalance(){
        Set<Integer> sets = circle.keySet();//获得TreeMap中所有的Key
        SortedSet<Integer> sortedSets= new TreeSet<Integer>(sets);//将获得的Key集合排序
        for(Integer hashCode : sortedSets){
            System.out.println(hashCode);
        }
        System.out.println("----each location 's distance are follows: ----");
        /*
         * 查看相邻两个hashCode的差值
         */
        Iterator<Integer> it = sortedSets.iterator();
        Iterator<Integer> it2 = sortedSets.iterator();
        if(it2.hasNext())
            it2.next();
        long keyPre, keyAfter;
        while(it.hasNext() && it2.hasNext()){
            keyPre = it.next();
            keyAfter = it2.next();
            System.out.println(keyAfter - keyPre);
        }
    }
    public static void main(String[] args) {
        Set<String> nodes = new HashSet<String>();
        nodes.add("A");
        nodes.add("B");
        nodes.add("C");
        ConsistentHash<String> consistentHash = new ConsistentHash<String>(2, nodes);
        consistentHash.add("D");
        System.out.println("hash circle size: " + consistentHash.getSize());
        System.out.println("location of each node are follows: ");
        consistentHash.testBalance();
        String node =consistentHash.get("apple");
        System.out.println("node----------->:"+node);
    }
}

虚拟哈希分区 (Version2)

刚才虚节点这种靠数量取胜的策略增加了存储这些虚节点信息所需要的空间

在Redis Cluster中使用了一种比较特殊的方法来解决分布不均的问题,改进了这些数据分布的算法,将环上的空间均匀的映射到一个线性空间,这样,就保证分布的均匀性。


顺序分区 VS 哈希分区

相关文章
|
7月前
|
缓存 NoSQL 关系型数据库
Redis缓存和分布式锁
Redis 是一种高性能的键值存储系统,广泛用于缓存、消息队列和内存数据库。其典型应用包括缓解关系型数据库压力,通过缓存热点数据提高查询效率,支持高并发访问。此外,Redis 还可用于实现分布式锁,解决分布式系统中的资源竞争问题。文章还探讨了缓存的更新策略、缓存穿透与雪崩的解决方案,以及 Redlock 算法等关键技术。
|
7月前
|
NoSQL Java 调度
分布式锁与分布式锁使用 Redis 和 Spring Boot 进行调度锁(不带 ShedLock)
分布式锁是分布式系统中用于同步多节点访问共享资源的机制,防止并发操作带来的冲突。本文介绍了基于Spring Boot和Redis实现分布式锁的技术方案,涵盖锁的获取与释放、Redis配置、服务调度及多实例运行等内容,通过Docker Compose搭建环境,验证了锁的有效性与互斥特性。
606 0
分布式锁与分布式锁使用 Redis 和 Spring Boot 进行调度锁(不带 ShedLock)
|
8月前
|
存储 负载均衡 NoSQL
【赵渝强老师】Redis Cluster分布式集群
Redis Cluster是Redis的分布式存储解决方案,通过哈希槽(slot)实现数据分片,支持水平扩展,具备高可用性和负载均衡能力,适用于大规模数据场景。
536 2
|
8月前
|
存储 缓存 NoSQL
【📕分布式锁通关指南 12】源码剖析redisson如何利用Redis数据结构实现Semaphore和CountDownLatch
本文解析 Redisson 如何通过 Redis 实现分布式信号量(RSemaphore)与倒数闩(RCountDownLatch),利用 Lua 脚本与原子操作保障分布式环境下的同步控制,帮助开发者更好地理解其原理与应用。
502 6
|
9月前
|
存储 缓存 NoSQL
Redis核心数据结构与分布式锁实现详解
Redis 是高性能键值数据库,支持多种数据结构,如字符串、列表、集合、哈希、有序集合等,广泛用于缓存、消息队列和实时数据处理。本文详解其核心数据结构及分布式锁实现,帮助开发者提升系统性能与并发控制能力。
|
9月前
|
NoSQL Redis
Lua脚本协助Redis分布式锁实现命令的原子性
利用Lua脚本确保Redis操作的原子性是分布式锁安全性的关键所在,可以大幅减少由于网络分区、客户端故障等导致的锁无法正确释放的情况,从而在分布式系统中保证数据操作的安全性和一致性。在将这些概念应用于生产环境前,建议深入理解Redis事务与Lua脚本的工作原理以及分布式锁的可能问题和解决方案。
326 8
|
10月前
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
2724 7
|
11月前
|
NoSQL 算法 安全
redis分布式锁在高并发场景下的方案设计与性能提升
本文探讨了Redis分布式锁在主从架构下失效的问题及其解决方案。首先通过CAP理论分析,Redis遵循AP原则,导致锁可能失效。针对此问题,提出两种解决方案:Zookeeper分布式锁(追求CP一致性)和Redlock算法(基于多个Redis实例提升可靠性)。文章还讨论了可能遇到的“坑”,如加从节点引发超卖问题、建议Redis节点数为奇数以及持久化策略对锁的影响。最后,从性能优化角度出发,介绍了减少锁粒度和分段锁的策略,并结合实际场景(如下单重复提交、支付与取消订单冲突)展示了分布式锁的应用方法。
858 3
|
11月前
|
存储 NoSQL Java
从扣减库存场景来讲讲redis分布式锁中的那些“坑”
本文从一个简单的库存扣减场景出发,深入分析了高并发下的超卖问题,并逐步优化解决方案。首先通过本地锁解决单机并发问题,但集群环境下失效;接着引入Redis分布式锁,利用SETNX命令实现加锁,但仍存在死锁、锁过期等隐患。文章详细探讨了通过设置唯一标识、续命机制等方法完善锁的可靠性,并最终引出Redisson工具,其内置的锁续命和原子性操作极大简化了分布式锁的实现。最后,作者剖析了Redisson源码,揭示其实现原理,并预告后续关于主从架构下分布式锁的应用与性能优化内容。
491 0
|
11月前
|
缓存 监控 NoSQL
Redis设计与实现——分布式Redis
Redis Sentinel 和 Cluster 是 Redis 高可用与分布式架构的核心组件。Sentinel 提供主从故障检测与自动切换,通过主观/客观下线判断及 Raft 算法选举领导者完成故障转移,但存在数据一致性和复杂度问题。Cluster 支持数据分片和水平扩展,基于哈希槽分配数据,具备自动故障转移和节点发现机制,适合大规模高并发场景。复制机制包括全量同步和部分同步,通过复制积压缓冲区优化同步效率,但仍面临延迟和资源消耗挑战。两者各有优劣,需根据业务需求选择合适方案。
769 14