【征服redis14】认真理解一致性Hash与Redis的三种集群

前面我们介绍了主从复制的方式和sentinel方式，这里我们看第三种模式-Cluster方式。

1.前两种集群模式的特征与不足

2.Cluster模式

[2.1 Cluster模式原理](#2.1 Cluster模式原理)

[2.2 数据分片与槽位](#2.2 数据分片与槽位)

[2.3 Cluster模式配置和实现](#2.3 Cluster模式配置和实现)

3.一致性Hash

[3.1 哈希后取模](#3.1 哈希后取模)

[3.2 一致性Hash算法](#3.2 一致性Hash算法)

[4 Redis Cluster集群](#4 Redis Cluster集群)

1.前两种集群模式的特征与不足

主从复制是Redis的一种基本集群模式，它通过将一个Redis节点（主节点）的数据复制到一个或多个其他Redis节点（从节点）来实现数据的冗余和备份。主节点负责处理客户端的写操作，同时从节点会实时同步主节点的数据。客户端可以从从节点读取数据，实现读写分离，提高系统性能。

主从复制模式适用于以下场景：

数据备份和容灾恢复：通过从节点备份主节点的数据，实现数据冗余。
读写分离：将读操作分发到从节点，减轻主节点压力，提高系统性能。
在线升级和扩展：在不影响主节点的情况下，通过增加从节点来扩展系统的读取能力。

由此可见，主从复制模式适合数据备份、读写分离和在线升级等场景，但在主节点故障时需要手动切换，不能自动实现故障转移。如果对高可用性要求较高，可以考虑使用哨兵模式或Cluster模式。

哨兵模式是在主从复制基础上加入了哨兵节点，实现了自动故障转移。哨兵节点是一种特殊的Redis节点，它会监控主节点和从节点的运行状态。当主节点发生故障时，哨兵节点会自动从从节点中选举出一个新的主节点，并通知其他从节点和客户端，实现故障转移。

此时的系统结构如下所示，也就说哨兵模式可以增强主备模式的功能，：

哨兵模式适用于以下场景：

高可用性要求较高的场景：通过自动故障转移，确保服务的持续可用。
数据备份和容灾恢复：在主从复制的基础上，提供自动故障转移功能。

由此可见，哨兵模式在主从复制模式的基础上实现了自动故障转移，提高了系统的高可用性。然而，它仍然无法实现数据分片。如果需要实现数据分片和负载均衡，可以考虑使用Cluster模式。

2.Cluster模式

2.1 Cluster模式原理

Cluster模式是Redis的一种高级集群模式，它通过数据分片和分布式存储实现了负载均衡和高可用性。在Cluster模式下，Redis将所有的键值对数据分散在多个节点上。每个节点负责一部分数据，称为槽位。通过对数据的分片，Cluster模式可以突破单节点的内存限制，实现更大规模的数据存储。

这里，有个问题，如果我们来了多个请求怎么判断该发送到哪个机器呢？这就是数据分片与槽位的问题。

2.2 数据分片与槽位

这里我们先说结论，后面再解释。

Redis Cluster将数据分为16384个槽位，每个节点负责管理一部分槽位。当客户端向Redis Cluster发送请求时，Cluster会根据键的哈希值将请求路由到相应的节点。具体来说，Redis Cluster使用CRC16算法计算键的哈希值，然后对16384取模，得到槽位编号。

2.3 Cluster模式配置和实现

配置Redis节点：为每个节点创建一个redis.conf配置文件，并添加如下配置：

java 复制代码

# cluster节点端口号
port 7001

# 开启集群模式
cluster-enabled yes

# 节点超时时间
cluster-node-timeout 15000

像这样的配置，一共需要创建6个，我们做一个三主三从的集群。

启动Redis节点：使用如下命令启动6个节点：

java 复制代码

redis-server redis_7001.conf

创建Redis Cluster：使用Redis命令行工具执行如下命令创建Cluster：

java 复制代码

redis-cli --cluster create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 --cluster-replicas 1

cluster-replicas 表示从节点的数量，1代表每个主节点都有一个从节点。

验证Cluster模式：向Cluster发送请求，观察请求是否正确路由到相应的节点。

这样我们就搭建了一个基本的Cluster集群了。

通过上面的方式，可以看到，这种方式需要客户端自己来配置所有的机器，有些复杂，一些复杂的操作可能也会受到限制，但是这种方式配置明确，在中等类型的互联网公司这么做都是可以的。

以下内容摘自咕泡青山老师的课堂讲义。

3.一致性Hash

如果客户端去连接redis服务器的时候会有个问题，此时客户端该如何选择呢？也就是该如何进行分库分表的分片策略呢？另外就是这段逻辑该由谁来做呢？

如下图所示：

关于分片，我们可以有三种方案：

第一种，是在客户端实现相关的逻辑，如用取模或者一致性哈希对key进行分片，查询和修改都先判断key的路由。
第二章，是把做分片处理的逻辑抽取出来，运行在一个独立的代理服务器上，客户端连接到这个dialing服务，然后再转发。
第三种就是服务端只有一个统一的对外接口，服务器之间自己实现分片策略。

第二种就是花钱消灾的方式，我们重点讨论另外两种。

以下内容摘自青山老师的讲义，内容挺好，怀念一下青山老师。

我们前面介绍的客户端Jedis客户端中，支持分片功能，它是SpringBoot2版本之前默认的Redis客户端，RedisTempate就是对Jedis的封装。

Jedis有多种连接池，其中一种是支持分片的。代码示例如下：

java 复制代码

 public static void main(String[] args) {
        JedisPoolConfig poolConfig = new JedisPoolConfig();
        JedisShardInfo shardInfo1 = new JedisShardInfo("127.0.0.1", 6379);
        JedisShardInfo shardInfo2 = new JedisShardInfo("127.0.0.1", 6389);

        List<JedisShardInfo> infoList = Arrays.asList(shardInfo1, shardInfo2);
        ShardedJedisPool shardedJedisPool = new ShardedJedisPool(poolConfig, infoList);

        ShardedJedis jedis = null;
        try {
            jedis = shardedJedisPool.getResource();
            for (int i = 0; i < 100; i++) {
                jedis.set("shard" + i, i + "");

            }
            for (int i = 0; i < 100; i++) {
                System.out.println(jedis.get("shard" + i));
            }
        } catch (Exception exception) {
            System.out.println(exception);
            if (jedis != null) {
                jedis.close();
            }
        }

    }

通过dbsize命令发自按，一个机器有44个key，一台机器有56个，大致是一半一半。

3.1 哈希后取模

ShardJedis是怎么做到的呢？如果是希望数据分布相对均匀的话，我们首先可以考虑哈希后取模。之所以先Hash，是因为key不一定是整数，可能是字符串或者其他信息，同时为了使数据分布更均匀，所以先计算哈希比较好。

例如，hash(key)%N,根据余数，决定映射到哪个结点。这种方式比较简单，属于静态分片的方式，缺点也很明显，一旦节点发生数量变化，或者某个hash被换了，此时取模N就会发生变化，数据就要重新分布。为了解决这个问题，我们又有了一致性Hash算法。ShardedJedis实际上使用的就是一致性哈希算法。