Redis集群的5种使用方式，各自优缺点分析

男娘i 2023-01-14 10:55 113阅读 0赞

参考文章：[Redis集群的5种使用方式，各自优缺点分析][Redis_5]

# 一、常见使用方式 #

**Redis 的几种常见使用方式包括：**

> 1.  Redis 单副本
> 2.  Redis 多副本(主从)
> 3.  Redis Sentinel(哨兵)
> 4.  Redis Cluster
> 5.  Redis 自研

# 二、各种使用方式的优缺点 #

## **1、Redis 单副本** ##

Redis 单副本，采用单个 Redis 节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。

![c20279ce045bf23d0f94405db51d402c.png][]

**优点：**

> 1.  架构简单，部署方便;
> 2.  高性价比：缓存使用时无需备用节点(单实例可用性可以用 supervisor 或 crontab 保证)，当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务;
> 3.  高性能。

**缺点：**

> 1.  不保证数据的可靠性;
> 2.  在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务;
> 3.  高性能受限于单核 CPU 的处理能力(Redis 是单线程机制)，CPU 为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用 Memcached 替代。

## **2、主从模式(Redis 多副本)** ##

为了避免单点故障 和 读写不分离，Redis 提供了复制（replication）功能实现master数据库中的数据更新后，会自动将更新的数据同步到其他slave数据库上。

Redis 多副本，采用主从(replication)部署结构，相较于单副本而言最大的特点就是主从实例间数据实时同步，并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上，根据公司的基础环境配置，可以实现同时对外提供服务和读写分离策略。

![db4459ff709c33513e0b0fb0ef42f21a.png][]

![20200725230640468.png][]

如上redis主从结构特点：一个master可以有多个salve节点；salve节点可以有slave节点，从节点是级联结构。

**优点：**

> 1.  高可靠性：提高效率、数据备份，多副本。一方面，采用双机主备架构，能够在主库出现故障时自动进行主备切换，从库提升为主库提供服务，保证服务平稳运行;另一方面，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和数据异常丢失的问题;
> 2.  读写分离：从节点可以扩展主库节点的读能力，有效应对大并发量的读操作。

**缺点：**

> 1.  故障恢复复杂，如果没有 RedisHA 系统(需要开发)，当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其它从库节点去复制新主库节点，整个过程需要人为干预，比较繁琐;
> 2.  主库的写能力受到单机的限制，可以考虑分片;
> 3.  主库的存储能力受到单机的限制，可以考虑 Pika;
> 4.  原生复制的弊端在早期的版本中也会比较突出，如：Redis 复制中断后，Slave 会发起 psync，此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于 COW 机制，导致极端情况下的主库内存溢出，程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘 IO 和 CPU(压缩)资源消耗;发送数 GB 大小的备份文件导致服务器出口带宽暴增，阻塞请求，建议升级到最新版本。
> 5.  最大的不足就是主从模式不具备自动容错和恢复功能，主节点故障，集群则无法进行工作，可用性比较低，从节点升主节点需要人工手动干预。

普通的主从模式，**当主数据库崩溃时，需要手动切换从数据库成为主数据库**:

> 1.  在从数据库中使用SLAVE NO ONE命令将从数据库提升成主数据继续服务。
> 2.  启动之前崩溃的主数据库，然后使用SLAVEOF命令将其设置成新的主数据库的从数据库，即可同步数据。

## **3、Redis Sentinel(哨兵)** ##

Redis Sentinel 是社区版本推出的原生高可用解决方案，其部署架构主要包括两部分：Redis Sentinel 集群和 Redis 数据集群。

其中 Redis Sentinel 集群是由若干 Sentinel 节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel 的节点数量要满足 2n+1(n>=1)的奇数个。

第一种主从同步/复制的模式，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用，这时候就需要哨兵模式登场了。哨兵模式是从Redis的2.6版本开始提供的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本以后，这个哨兵模式才稳定下来。

哨兵模式核心还是主从复制，只不过在相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制：从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。

![20200725234046536.png][]

如上图，哨兵本身也有单点故障的问题，所以在一个一主多从的Redis系统中，可以使用多个哨兵进行监控，哨兵不仅会监控主数据库和从数据库，哨兵之间也会相互监控。每一个哨兵都是一个独立的进程，作为进程，它会独立运行。

![20200725234147279.png][]

### (1)哨兵模式的作用： ###

> 1.  监控所有服务器是否正常运行：通过发送命令返回监控服务器的运行状态，处理监控主服务器、从服务器外，哨兵之间也相互监控。
> 2.  故障切换：当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换master。同时那台有问题的旧主也会变为新主的从，也就是说当旧的主即使恢复时，并不会恢复原来的主身份，而是作为新主的一个从。

### (2)哨兵实现原理 ###

哨兵在启动进程时，会读取配置文件的内容，通过如下的配置找出需要监控的主数据库：

sentinel monitor master-name ip port quorum
    #master-name是主数据库的名字
    #ip和port 是当前主数据库地址和端口号
    #quorum表示在执行故障切换操作前，需要多少哨兵节点同意。

这里之所以只需要连接主节点，是因为通过主节点的info命令，获取从节点信息，从而和从节点也建立连接，同时也能通过主节点的info信息知道新增从节点的信息。  
一个哨兵节点可以监控多个主节点，但是并不提倡这么做，因为当哨兵节点崩溃时，同时有多个集群切换会发生故障。 哨兵启动后，会与主数据库建立两条连接。

> 1.  订阅主数据库\_sentinel\_:hello频道以获取同样监控该数据库的哨兵节点信息
> 2.  定期向主数据库发送info命令，获取主数据库本身的信息。

**跟主数据库建立连接后会定时执行以下三个操作：**

> 1.  每隔10s向master和 slave发送info命令。作用是获取当前数据库信息，比如发现新增从节点时，会建立连接，并加入到监控列表中，当主从数据库的角色发生变化进行信息更新。
> 2.  每隔2s向主数据里和从数据库的\_sentinel\_:hello频道发送自己的信息。作用是将自己的监控数据和哨兵分享。每个哨兵会订阅数据库的\_sentinel:hello频道，当其他哨兵收到消息后，会判断该哨兵是不是新的哨兵，如果是则将其加入哨兵列表，并建立连接。
> 3.  每隔1s向所有主从节点和所有哨兵节点发送ping命令，作用是监控节点是否存活。

### (3)主观下线和客观下线 ###

哨兵节点发送ping命令时，当超过一定时间(down-after-millisecond)后，如果节点未回复，则哨兵认为主观下线。主观下线表示当前哨兵认为该节点已经下面，如果该节点为主数据库，哨兵会进一步判断是够需要对其进行故障切换，这时候就要发送命令(SENTINEL is-master-down-by-addr)询问其他哨兵节点是否认为该主节点是主观下线，当达到指定数量(quorum)时，哨兵就会认为是客观下线。

当主节点客观下线时就需要进行主从切换，主从切换的步骤为：

> 1.  选出领头哨兵。
> 2.  领头哨兵所有的slave选出优先级最高的从数据库。优先级可以通过slave-priority选项设置。
> 3.  如果优先级相同，则从复制的命令偏移量越大（即复制同步数据越多，数据越新），越优先。
> 4.  如果以上条件都一样，则选择run ID较小的从数据库。

选出一个从数据库后，哨兵发送slave no one命令升级为主数据库，并发送slaveof命令将其他从节点的主数据库设置为新的主数据库。

**优点：**

> 1.  哨兵模式是基于主从模式的，解决可主从模式中master故障不可以自动切换故障的问题。
> 2.  Redis Sentinel 集群部署简单;
> 3.  能够解决 Redis 主从模式下的高可用切换问题;
> 4.  很方便实现 Redis 数据节点的线形扩展，轻松突破 Redis 自身单线程瓶颈，可极大满足 Redis 大容量或高性能的业务需求;
> 5.  可以实现一套 Sentinel 监控一组 Redis 数据节点或多组数据节点。

**缺点：**

> 1.  部署相对 Redis 主从模式要复杂一些，原理理解更繁琐;
> 2.  资源浪费，Redis 数据节点中 slave 节点作为备份节点不提供服务;
> 3.  Redis Sentinel 主要是针对 Redis 数据节点中的主节点的高可用切换，对 Redis 的数据节点做失败判定分为主观下线和客观下线两种，对于 Redis 的从节点有对节点做主观下线操作，并不执行故障转移。
> 4.  不能解决读写分离问题，实现起来相对复杂。
> 5.  是一种中心化的集群实现方案：始终只有一个Redis主机来接收和处理写请求，写操作受单机瓶颈影响。
> 6.  集群里所有节点保存的都是全量数据，浪费内存空间，没有真正实现分布式存储。数据量过大时，主从同步严重影响master的性能。
> 7.  Redis主机宕机后，哨兵模式正在投票选举的情况之外，因为投票选举结束之前，谁也不知道主机和从机是谁，此时Redis也会开启保护机制，禁止写操作，直到选举出了新的Redis主机。

主从模式或哨兵模式每个节点存储的数据都是全量的数据，数据量过大时，就需要对存储的数据进行分片后存储到多个redis实例上。此时就要用到Redis Sharding技术。

**建议：**

> 如果监控同一业务，可以选择一套 Sentinel 集群监控多组 Redis 数据节点的方案，反之选择一套 Sentinel 监控一组 Redis 数据节点的方案。
> 
> sentinel monitor配置中的建议设置成 Sentinel 节点的一半加 1，当 Sentinel 部署在多个 IDC 的时候，单个 IDC 部署的 Sentinel 数量不建议超过(Sentinel 数量 – quorum)。

合理设置参数，防止误切，控制切换灵敏度控制：

> 1.  quorum
> 2.  down-after-milliseconds 30000
> 3.  failover-timeout 180000
> 4.  maxclient
> 5.  timeout

**注意要点： **

> 1.  部署的各个节点服务器时间尽量要同步，否则日志的时序性会混乱。
> 2.  Redis 建议使用 pipeline 和 multi-keys 操作，减少 RTT 次数，提高请求效率。
> 3.  自行搞定配置中心(zookeeper)，方便客户端对实例的链接访问。

## **4、Redis Cluster** ##

> Redis Cluster 是社区版推出的 Redis 分布式集群解决方案，主要解决 Redis 分布式方面的需求，比如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster 能起到很好的负载均衡的目的。  
> Redis Cluster 集群节点最小配置 6 个节点以上(3 主 3 从)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。  
> Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0～16383 个整数槽内，每个节点负责维护一部分槽以及槽所印映射的键值数据。

**Redis 的哨兵模式虽然已经可以实现高可用，读写分离 ，但是存在几个方面的不足：**

>  *  哨兵模式下每台 Redis 服务器都存储相同的数据，很浪费内存空间；数据量太大，主从同步时严重影响了master性能。
>  *  哨兵模式是中心化的集群实现方案，每个从机和主机的耦合度很高，master宕机到salve选举master恢复期间服务不可用。
>  *  哨兵模式始终只有一个Redis主机来接收和处理写请求，写操作还是受单机瓶颈影响，没有实现真正的分布式架构。

redis在3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的数据。cluster模式为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS不受限于单机，可受益于分布式集群高扩展性。Redis Cluster是一种服务器Sharding技术(分片和路由都是在服务端实现)，**采用多主多从，每一个分区都是由一个Redis主机和多个从机组成，片区和片区之间是相互平行的。**Redis Cluster集群采用了P2P的模式，完全去中心化。

![2020072714412735.png][]

如上图，官方推荐，集群部署至少要 3 台以上的master节点，最好使用 3 主 3 从六个节点的模式。**Redis Cluster集群具有如下几个特点**：

>  *  集群完全去中心化，采用多主多从；所有的redis节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽。
>  *  客户端与 Redis 节点直连，不需要中间代理层。客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。
>  *  每一个分区都是由一个Redis主机和多个从机组成，分片和分片之间是相互平行的。
>  *  每一个master节点负责维护一部分槽，以及槽所映射的键值数据；集群中每个节点都有全量的槽信息，通过槽每个node都知道具体数据存储到哪个node上。

**redis cluster主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster，数据量不是很大时，使用sentinel就够了。**redis cluster的性能和高可用性均优于哨兵模式**。**

Redis Cluster采用虚拟哈希槽分区而非一致性hash算法，预先分配一些卡槽，所有的键根据哈希函数映射到这些槽内，每一个分区内的master节点负责维护一部分槽以及槽所映射的键值数据。关于Redis Cluster的详细实现原理请参考：[Redis Cluster数据分片实现原理][Redis Cluster]。

**优点：**

> 1.  无中心架构;
> 2.  数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布;
> 3.  可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除;
> 4.  高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升;
> 5.  降低运维成本，提高系统的扩展性和可用性。

**缺点：**

> 1.  Client 实现复杂，驱动要求实现 Smart Client，缓存 slots mapping 信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅 JedisCluster 相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
> 2.  节点会因为某些原因发生阻塞(阻塞时间大于 clutser-node-timeout)，被判断下线，这种 failover 是没有必要的。
> 3.  数据通过异步复制，不保证数据的强一致性。
> 4.  多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。
> 5.  Slave 在集群中充当“冷备”，不能缓解读压力，当然可以通过 SDK 的合理设计来提高 Slave 资源的利用率。
> 6.  Key 批量操作限制，如使用 mset、mget 目前只支持具有相同 slot 值的 Key 执行批量操作。对于映射为不同 slot 值的 Key 由于 Keys 不支持跨 slot 查询，所以执行 mset、mget、sunion 等操作支持不友好。
> 7.  Key 事务操作支持有限，只支持多 key 在同一节点上的事务操作，当多个 Key 分布于不同的节点上时无法使用事务功能。
> 8.  Key 作为数据分区的最小粒度，不能将一个很大的键值对象如 hash、list 等映射到不同的节点。
> 9.  不支持多数据库空间，单机下的 redis 可以支持到 16 个数据库，集群模式下只能使用 1 个数据库空间，即 db 0。
> 10. 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。
> 11. 避免产生 hot-key，导致主库节点成为系统的短板。
> 12. 避免产生 big-key，导致网卡撑爆、慢查询等。
> 13. 重试时间应该大于 cluster-node-time 时间。
> 14. Redis Cluster 不建议使用 pipeline 和 multi-keys 操作，减少 max redirect 产生的场景。

## **5、Redis 自研** ##

Redis 自研的高可用解决方案，主要体现在配置中心、故障探测和 failover 的处理机制上，通常需要根据企业业务的实际线上环境来定制化。

![252cfb609ca68ace0c9dacb705f77c6f.png][]

![590c212256a5899b76e2e97971df8b0d.png][]

**优点：**

> 1.  高可靠性、高可用性;
> 2.  自主可控性高;
> 3.  贴切业务实际需求，可缩性好，兼容性好。

**缺点：**

> 1.  实现复杂，开发成本高;
> 2.  需要建立配套的周边设施，如监控，域名服务，存储元数据信息的数据库等;
> 3.  维护成本高。

## 补充：各大厂的Redis集群方案  ##

> Redis在3.0版本前只支持单实例模式，虽然Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业等不急了，在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例。

### (1)客户端分片 ###

> 客户端分片是把分片的逻辑放在Redis客户端实现，（比如：jedis已支持Redis Sharding功能，即ShardedJedis），通过Redis客户端预先定义好的路由规则(使用一致性哈希)，把对Key的访问转发到不同的Redis实例中，查询数据时把返回结果汇集。这种方案的模式如图所示。

![20200727141353539.png][]

客户端分片的优缺点：

*  **优点**：客户端sharding技术使用hash一致性算法分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。开发人员清楚怎么实现分片、路由的规则，不用担心踩坑。

#1.一致性哈希算法:
        是分布式系统中常用的算法。比如，一个分布式的存储系统，要将数据存储到具体的节点上，如果采用普通的hash方法，将数据映射到具体的节点上，
    如mod(key,d)，key是数据的key，d是机器节点数，如果有一个机器加入或退出这个集群，则所有的数据映射都无效了。
        一致性哈希算法解决了普通余数Hash算法伸缩性差的问题，可以保证在上线、下线服务器的情况下尽量有多的请求命中原来路由到的服务器。
     
    #2.实现方式：一致性hash算法，比如MURMUR_HASH散列算法、ketamahash算法
        比如Jedis的Redis Sharding实现，采用一致性哈希算法(consistent hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。
    采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。

*  **不足**：

>  *  这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。
>  *  运维成本比较高，集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了跨部门沟通的成本。
>  *  在不同的客户端程序中，维护相同的路由分片逻辑成本巨大。比如：java项目、PHP项目里共用一套Redis集群，路由分片逻辑分别需要写两套一样的逻辑，以后维护也是两套。
>  *  客户端分片有一个最大的问题就是，服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。如果能把客户端分片模块单独拎出来，形成一个单独的模块(中间件)，作为客户端 和 服务端连接的桥梁就能解决这个问题了，此时代理分片就出现了。

### (2)代理分片 ###

> redis代理分片用得最多的就是Twemproxy，由Twitter开源的Redis代理，其基本原理是：通过中间件的形式，Redis客户端把请求发送到Twemproxy，Twemproxy根据路由规则发送到正确的Redis实例，最后Twemproxy把结果汇集返回给客户端。
> 
> Twemproxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Twemproxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群。

![20200727142348502.png][]

**Twemproxy的优点：**

>  *  客户端像连接Redis实例一样连接Twemproxy，不需要改任何的代码逻辑。
>  *  支持无效Redis实例的自动删除。
>  *  Twemproxy与Redis实例保持连接，减少了客户端与Redis实例的连接数。

**Twemproxy的不足：**

>  *  由于Redis客户端的每个请求都经过Twemproxy代理才能到达Redis服务器，这个过程中会产生性能损失。
>  *  没有友好的监控管理后台界面，不利于运维监控。
>  *  Twemproxy最大的痛点在于，无法平滑地扩容/缩容。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。

**Twemproxy作为最被广泛使用、最久经考验、稳定性最高的Redis代理，在业界被广泛使用。**

### (3)Codis ###

> Twemproxy不能平滑增加Redis实例的问题带来了很大的不便，于是豌豆荚自主研发了Codis，一个支持平滑增加Redis实例的Redis代理软件，其基于Go和C语言开发，并于2014年11月在GitHub上开源 [codis开源地址][codis] 。

![20200727142937557.png][]

在Codis的架构图中，Codis引入了Redis Server Group，其通过指定一个主CodisRedis和一个或多个从CodisRedis，实现了Redis集群的高可用。当一个主CodisRedis挂掉时，Codis不会自动把一个从CodisRedis提升为主CodisRedis，这涉及数据的一致性问题（Redis本身的数据同步是采用主从异步复制，当数据在主CodisRedis写入成功时，从CodisRedis是否已读入这个数据是没法保证的），需要管理员在管理界面上手动把从CodisRedis提升为主CodisRedis。

如果手动处理觉得麻烦，豌豆荚也提供了一个工具Codis-ha，这个工具会在检测到主CodisRedis挂掉的时候将其下线并提升一个从CodisRedis为主CodisRedis。

Codis中采用预分片的形式，启动的时候就创建了1024个slot，1个slot相当于1个箱子，每个箱子有固定的编号，范围是1~1024。slot这个箱子用作存放Key，至于Key存放到哪个箱子，可以通过算法“crc32(key)%1024”获得一个数字，这个数字的范围一定是1~1024之间，Key就放到这个数字对应的slot。例如，如果某个Key通过算法“crc32(key)%1024”得到的数字是5，就放到编码为5的slot（箱子）。1个slot只能放1个Redis Server Group，不能把1个slot放到多个Redis Server Group中。1个Redis Server Group最少可以存放1个slot，最大可以存放1024个slot。因此，Codis中最多可以指定1024个Redis Server Group。

Codis最大的优势在于支持平滑增加（减少）Redis Server Group（Redis实例），能安全、透明地迁移数据，这也是Codis 有别于Twemproxy等静态分布式 Redis 解决方案的地方。Codis增加了Redis Server Group后，就牵涉到slot的迁移问题。例如，系统有两个Redis Server Group，Redis Server Group和slot的对应关系如下。

<table> 
 <thead> 
  <tr> 
   <th>Redis Server Group</th> 
   <th>slot</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>1~500</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>501~1024</td> 
  </tr> 
 </tbody> 
</table>

当增加了一个Redis Server Group，slot就要重新分配了。Codis分配slot有两种方法：

*  第一种：通过Codis管理工具Codisconfig手动重新分配，指定每个Redis Server Group所对应的slot的范围，例如：可以指定Redis Server Group和slot的新的对应关系如下。

<table> 
 <thead> 
  <tr> 
   <th>Redis Server Group</th> 
   <th>slot</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>1~500</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>501~700</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>701~1024</td> 
  </tr> 
 </tbody> 
</table>

*  第二种：通过Codis管理工具Codisconfig的rebalance功能，会自动根据每个Redis Server Group的内存对slot进行迁移，以实现数据的均衡。

[Redis_5]: https://www.jianshu.com/p/220b8d2c41c3
[c20279ce045bf23d0f94405db51d402c.png]: /images/20221022/0af889de148342f4bc25765f73fba0ac.png
[db4459ff709c33513e0b0fb0ef42f21a.png]: /images/20221022/7210ae0cec164b5c926f76bfc3141858.png
[20200725230640468.png]: /images/20221022/42413923bb8d4a2eb24808fc82ffbe9e.png
[20200725234046536.png]: /images/20221022/1c59b7b123ee4f049fcb1414b621e21a.png
[20200725234147279.png]: /images/20221022/59ec099be4404213af93bee6baf58776.png
[2020072714412735.png]: /images/20221022/81fb75f307344fe182452befa254571e.png
[Redis Cluster]: https://blog.csdn.net/Seky_fei/article/details/107611850
[252cfb609ca68ace0c9dacb705f77c6f.png]: /images/20221022/9ea91adf62b1471b90d906bdb8cba0fb.png
[590c212256a5899b76e2e97971df8b0d.png]: /images/20221022/3531ffb0d3564fb4afca3d1c1277f23e.png
[20200727141353539.png]: /images/20221022/11ec15722995469ab17aab62e324c3c8.png
[20200727142348502.png]: /images/20221022/05b285f3eeba494e8494fbac34a5b15c.png
[codis]: https://github.com/CodisLabs/codis
[20200727142937557.png]: /images/20221022/12baa5534b734a2db0cae749a9b595e8.png