深入剖析Redis - Redis集群模式搭建与原理详解

电玩女神 2022-01-16 08:01 264阅读 0赞

# 转载：[https://www.jianshu.com/p/84dbb25cc8dc][https_www.jianshu.com_p_84dbb25cc8dc] #

0.9 2018.09.09 19:49 字数 5371 阅读 5040评论 1喜欢 21

1. Redis集群方案

Redis Cluster 集群模式通常具有 **高可用**、**可扩展性**、**分布式**、**容错** 等特性。Redis 分布式方案一般有两种：

1.1 客户端分区方案

**客户端** 就已经决定数据会被 **存储** 到哪个 redis 节点或者从哪个 redis 节点 **读取数据**。其主要思想是采用 **哈希算法** 将 Redis 数据的 key 进行散列，通过 hash 函数，特定的 key会 **映射** 到特定的 Redis 节点上。

![495][]

**客户端分区方案** 的代表为 Redis Sharding，Redis Sharding 是 Redis Cluster 出来之前，业界普遍使用的 Redis **多实例集群** 方法。Java 的 Redis 客户端驱动库 Jedis，支持 Redis Sharding 功能，即 ShardedJedis 以及 **结合缓存池** 的 ShardedJedisPool。

**优点**

不使用 **第三方中间件**，**分区逻辑** 可控，**配置** 简单，节点之间无关联，容易 **线性扩展**，灵活性强。

**缺点**

**客户端** 无法 **动态增删** 服务节点，客户端需要自行维护 **分发逻辑**，客户端之间 **无连接共享**，会造成 **连接浪费**。

1.2. 代理分区方案

**客户端** 发送请求到一个 **代理组件**，**代理** 解析 **客户端** 的数据，并将请求转发至正确的节点，最后将结果回复给客户端。

**优点**：简化 **客户端** 的分布式逻辑，**客户端** 透明接入，切换成本低，代理的 **转发** 和 **存储** 分离。

**缺点**：多了一层 **代理层**，加重了 **架构部署复杂度** 和 **性能损耗**。

![640][]

**代理分区** 主流实现的有方案有 Twemproxy 和 Codis。

1.2.1. Twemproxy

Twemproxy 也叫 nutcraker，是 twitter 开源的一个 redis 和 memcache 的 **中间代理服务器** 程序。Twemproxy 作为 **代理**，可接受来自多个程序的访问，按照 **路由规则**，转发给后台的各个 Redis 服务器，再原路返回。Twemproxy 存在 **单点故障** 问题，需要结合 Lvs 和 Keepalived 做 **高可用方案**。

![640 1][]

**优点**：应用范围广，稳定性较高，中间代理层 **高可用**。

**缺点**：无法平滑地 **水平扩容/缩容**，无 **可视化管理界面**，运维不友好，出现故障，不能 **自动转移**。

1.2.2. Codis

Codis 是一个 **分布式** Redis 解决方案，对于上层应用来说，连接 Codis-Proxy 和直接连接 **原生的** Redis-Server 没有的区别。Codis 底层会 **处理请求的转发**，不停机的进行 **数据迁移** 等工作。Codis 采用了无状态的 **代理层**，对于 **客户端** 来说，一切都是透明的。

![640 2][]

**优点**

实现了上层 Proxy 和底层 Redis 的 **高可用**，**数据分片** 和 **自动平衡**，提供 **命令行接口** 和 RESTful API，提供 **监控** 和 **管理** 界面，可以动态 **添加** 和 **删除** Redis 节点。

**缺点**

**部署架构** 和 **配置** 复杂，不支持 **跨机房** 和 **多租户**，不支持 **鉴权管理**。

1.3. 查询路由方案

**客户端随机地** 请求任意一个 Redis 实例，然后由 Redis 将请求 **转发** 给 **正确** 的 Redis 节点。Redis Cluster 实现了一种 **混合形式** 的 **查询路由**，但并不是 **直接** 将请求从一个 Redis 节点 **转发** 到另一个 Redis 节点，而是在 **客户端** 的帮助下直接 **重定向**（ redirected）到正确的 Redis 节点。

![640 3][]

**优点**

**无中心节点**，数据按照 **槽** 存储分布在多个 Redis 实例上，可以平滑的进行节点 **扩容/缩容**，支持 **高可用** 和 **自动故障转移**，运维成本低。

**缺点**

严重依赖 Redis-trib 工具，缺乏 **监控管理**，需要依赖 Smart Client (**维护连接**，**缓存路由表**，MultiOp 和 Pipeline 支持)。Failover 节点的 **检测过慢**，不如 **中心节点** ZooKeeper 及时。Gossip 消息具有一定开销。无法根据统计区分 **冷热数据**。

2. 数据分布

2.1. 数据分布理论

**分布式数据库** 首先要解决把 **整个数据集** 按照 **分区规则** 映射到 **多个节点** 的问题，即把 **数据集** 划分到 **多个节点** 上，每个节点负责 **整体数据** 的一个 **子集**。

![640 4][]

数据分布通常有 **哈希分区** 和 **顺序分区** 两种方式，对比如下：

分区方式 特点 相关产品 哈希分区 离散程度好，数据分布与业务无关，无法顺序访问 Redis Cluster，Cassandra，Dynamo 顺序分区 离散程度易倾斜，数据分布与业务相关，可以顺序访问 BigTable，HBase，Hypertable 由于 Redis Cluster 采用 **哈希分区规则**，这里重点讨论 **哈希分区**。常见的 **哈希分区** 规则有几种，下面分别介绍：

2.1.1. 节点取余分区

使用特定的数据，如 Redis 的 **键** 或 **用户** ID，再根据 **节点数量** N 使用公式：hash（key）% N 计算出 **哈希值**，用来决定数据 **映射** 到哪一个节点上。

![640 5][]

**优点**

这种方式的突出优点是 **简单性**，常用于 **数据库** 的 **分库分表规则**。一般采用 **预分区** 的方式，提前根据 **数据量** 规划好 **分区数**，比如划分为 512 或 1024 张表，保证可支撑未来一段时间的 **数据容量**，再根据 **负载情况** 将 **表** 迁移到其他 **数据库** 中。扩容时通常采用 **翻倍扩容**，避免 **数据映射** 全部被 **打乱**，导致 **全量迁移** 的情况。

**缺点**

当 **节点数量** 变化时，如 **扩容** 或 **收缩** 节点，数据节点 **映射关系** 需要重新计算，会导致数据的 **重新迁移**。

2.1.2. 一致性哈希分区

**一致性哈希** 可以很好的解决 **稳定性问题**，可以将所有的 **存储节点** 排列在 **收尾相接** 的 Hash 环上，每个 key 在计算 Hash 后会 **顺时针** 找到 **临接** 的 **存储节点** 存放。而当有节点 **加入** 或 **退出** 时，仅影响该节点在 Hash 环上 **顺时针相邻** 的 **后续节点**。

![640 6][]

**优点**

**加入** 和 **删除** 节点只影响 **哈希环** 中 **顺时针方向** 的 **相邻的节点**，对其他节点无影响。

**缺点**

**加减节点** 会造成 **哈希环** 中部分数据 **无法命中**。当使用 **少量节点** 时，**节点变化** 将大范围影响 **哈希环** 中 **数据映射**，不适合 **少量数据节点** 的分布式方案。**普通** 的 **一致性哈希分区** 在增减节点时需要 **增加一倍** 或 **减去一半** 节点才能保证 **数据** 和 **负载的均衡**。

**注意**：因为 **一致性哈希分区** 的这些缺点，一些分布式系统采用 **虚拟槽** 对 **一致性哈希** 进行改进，比如 Dynamo 系统。

2.1.3. 虚拟槽分区

**虚拟槽分区** 巧妙地使用了 **哈希空间**，使用 **分散度良好** 的 **哈希函数** 把所有数据 **映射** 到一个 **固定范围** 的 **整数集合** 中，整数定义为 **槽**（slot）。这个范围一般 **远远大于** 节点数，比如 Redis Cluster 槽范围是 0 ~ 16383。**槽** 是集群内 **数据管理** 和 **迁移** 的 **基本单位**。采用 **大范围槽** 的主要目的是为了方便 **数据拆分** 和 **集群扩展**。每个节点会负责 **一定数量的槽**，如图所示：

当前集群有 5 个节点，每个节点平均大约负责 3276 个 **槽**。由于采用 **高质量** 的 **哈希算法**，每个槽所映射的数据通常比较 **均匀**，将数据平均划分到 5 个节点进行 **数据分区**。Redis Cluster 就是采用 **虚拟槽分区**。

**节点1**： 包含 0 到 3276 号哈希槽。

**节点2**：包含 3277 到 6553 号哈希槽。

**节点3**：包含 6554 到 9830 号哈希槽。

**节点4**：包含 9831 到 13107 号哈希槽。

**节点5**：包含 13108 到 16383 号哈希槽。

这种结构很容易 **添加** 或者 **删除** 节点。如果 **增加** 一个节点 6，就需要从节点 1 ~ 5 获得部分 **槽** 分配到节点 6 上。如果想 **移除** 节点 1，需要将节点 1 中的 **槽** 移到节点 2 ~ 5 上，然后将 **没有任何槽** 的节点 1 从集群中 **移除** 即可。

由于从一个节点将 **哈希槽** 移动到另一个节点并不会 **停止服务**，所以无论 **添加删除**或者 **改变** 某个节点的 **哈希槽的数量** 都不会造成 **集群不可用** 的状态.

2.2. Redis的数据分区

Redis Cluster 采用 **虚拟槽分区**，所有的 **键** 根据 **哈希函数** 映射到 0~16383 整数槽内，计算公式：slot = CRC16（key）& 16383。每个节点负责维护一部分槽以及槽所映射的 **键值数据**，如图所示：

2.2.1. Redis虚拟槽分区的特点

解耦 **数据** 和 **节点** 之间的关系，简化了节点 **扩容** 和 **收缩** 难度。

**节点自身** 维护槽的 **映射关系**，不需要 **客户端** 或者 **代理服务** 维护 **槽分区元数据**。

支持 **节点**、**槽**、**键** 之间的 **映射查询**，用于 **数据路由**、**在线伸缩** 等场景。

2.3. Redis集群的功能限制

Redis 集群相对 **单机** 在功能上存在一些限制，需要 **开发人员** 提前了解，在使用时做好规避。

key **批量操作** 支持有限。

类似 mset、mget 操作，目前只支持对具有相同 slot 值的 key 执行 **批量操作**。对于 **映射为不同** slot 值的 key 由于执行 mget、mget 等操作可能存在于多个节点上，因此不被支持。

key **事务操作** 支持有限。

只支持 **多** key 在 **同一节点上** 的 **事务操作**，当多个 key 分布在 **不同** 的节点上时 **无法** 使用事务功能。

key 作为 **数据分区** 的最小粒度

不能将一个 **大的键值** 对象如 hash、list 等映射到 **不同的节点**。

不支持 **多数据库空间**

**单机** 下的 Redis 可以支持 16 个数据库（db0 ~ db15），**集群模式** 下只能使用 **一个** 数据库空间，即 db0。

**复制结构** 只支持一层

**从节点** 只能复制 **主节点**，不支持 **嵌套树状复制** 结构。

3. Redis集群搭建

Redis-Cluster 是 Redis 官方的一个 **高可用** 解决方案，Cluster 中的 Redis 共有 2^14（16384） 个 slot **槽**。创建 Cluster 后，**槽** 会 **平均分配** 到每个 Redis 节点上。

下面介绍一下本机启动 6 个 Redis 的 **集群服务**，并使用 redis-trib.rb 创建 **3主3从** 的 **集群**。搭建集群工作需要以下三个步骤：

3.1. 准备节点

Redis 集群一般由 **多个节点** 组成，节点数量至少为 6 个，才能保证组成 **完整高可用** 的集群。每个节点需要 **开启配置** cluster-enabled yes，让 Redis 运行在 **集群模式** 下。

Redis 集群的节点规划如下：

节点名称 端口号 是主是从 所属主节点 redis-6379 6379 主节点 --- redis-6389 6389 从节点 redis-6379 redis-6380 6380 主节点 --- redis-6390 6390 从节点 redis-6380 redis-6381 6381 主节点 --- redis-6391 6391 从节点 redis-6381 **注意**：建议为集群内 **所有节点** 统一目录，一般划分三个目录：conf、data、log，分别存放 **配置**、**数据**和 **日志** 相关文件。把 6 个节点配置统一放在 conf 目录下。

3.1.1. 创建redis各实例目录

$sudo mkdir -p /usr/local/redis-cluster$cd/usr/local/redis-cluster$sudo mkdir conf datalog$ sudo mkdir -p data/redis-6379 data/redis-6389 data/redis-6380 data/redis-6390 data/redis-6381 data/redis-6391复制代码

3.1.2. redis配置文件管理

根据以下 **模板** 配置各个实例的 redis.conf，以下只是搭建集群需要的 **基本配置**，可能需要根据实际情况做修改。

\# redis后台运行daemonizeyes\# 绑定的主机端口bind 127.0.0.1\# 数据存放目录dir /usr/local/redis-cluster/data/redis-6379\# 进程文件pidfile /var/run/redis-cluster/$\{自定义\}.pid\# 日志文件logfile /usr/local/redis-cluster/log/$\{自定义\}.log\# 端口号port 6379\# 开启集群模式，把注释\#去掉cluster-enabledyes\# 集群的配置，配置文件首次启动自动生成cluster-config-file /usr/local/redis-cluster/conf/$\{自定义\}.conf\# 请求超时，设置10秒cluster-node-timeout 10000\# aof日志开启，有需要就开启，它会每次写操作都记录一条日志appendonlyyes复制代码

**redis-6379.conf**

daemonize yesbind 127.0.0.1dir/usr/local/redis-cluster/data/redis-6379pidfile /var/run/redis-cluster/redis-6379.pidlogfile /usr/local/redis-cluster/log/redis-6379.logport 6379cluster-enabled yescluster-config-file/usr/local/redis-cluster/conf/node-6379.confcluster-node-timeout 10000appendonly yes复制代码

**redis-6389.conf**

daemonize yesbind 127.0.0.1dir/usr/local/redis-cluster/data/redis-6389pidfile /var/run/redis-cluster/redis-6389.pidlogfile /usr/local/redis-cluster/log/redis-6389.logport 6389cluster-enabled yescluster-config-file/usr/local/redis-cluster/conf/node-6389.confcluster-node-timeout 10000appendonly yes复制代码

**redis-6380.conf**

daemonize yesbind 127.0.0.1dir/usr/local/redis-cluster/data/redis-6380pidfile /var/run/redis-cluster/redis-6380.pidlogfile /usr/local/redis-cluster/log/redis-6380.logport 6380cluster-enabled yescluster-config-file/usr/local/redis-cluster/conf/node-6380.confcluster-node-timeout 10000appendonly yes复制代码

**redis-6390.conf**

daemonize yesbind 127.0.0.1dir/usr/local/redis-cluster/data/redis-6390pidfile /var/run/redis-cluster/redis-6390.pidlogfile /usr/local/redis-cluster/log/redis-6390.logport 6390cluster-enabled yescluster-config-file/usr/local/redis-cluster/conf/node-6390.confcluster-node-timeout 10000appendonly yes复制代码

**redis-6381.conf**

daemonize yesbind 127.0.0.1dir/usr/local/redis-cluster/data/redis-6381pidfile /var/run/redis-cluster/redis-6381.pidlogfile /usr/local/redis-cluster/log/redis-6381.logport 6381cluster-enabled yescluster-config-file/usr/local/redis-cluster/conf/node-6381.confcluster-node-timeout 10000appendonly yes复制代码

**redis-6391.conf**

daemonize yesbind 127.0.0.1dir/usr/local/redis-cluster/data/redis-6391pidfile /var/run/redis-cluster/redis-6391.pidlogfile /usr/local/redis-cluster/log/redis-6391.logport 6391cluster-enabled yescluster-config-file/usr/local/redis-cluster/conf/node-6391.confcluster-node-timeout 10000appendonly yes复制代码

3.2. 环境准备

3.2.1. 安装Ruby环境

$ sudobrew install ruby复制代码

3.2.2. 准备rubygem redis依赖

$ sudo geminstallredisPassword:Fetching: redis-4.0.2.gem (100%)Successfully installed redis-4.0.2Parsing documentationforredis-4.0.2Installing ri documentationforredis-4.0.2Done installing documentationforredisafter1seconds1gem installed复制代码

3.2.3. 拷贝redis-trib.rb到集群根目录

redis-trib.rb 是 redis 官方推出的管理 redis **集群** 的工具，集成在 redis 的源码 src 目录下，将基于 redis 提供的 **集群命令** 封装成 **简单**、**便捷**、**实用** 的 **操作工具**。

$ sudo cp/usr/local/redis-4.0.11/src/redis-trib.rb /usr/local/redis-cluster复制代码

查看 redis-trib.rb 命令环境是否正确，输出如下：

$ ./redis-trib.rb Usage:redis-trib create host1:port1 ...hostN:portN--replicascheck host:portinfo host:portfix host:port--timeoutreshard host:port--from--to--slots--yes--timeout--pipelinerebalance host:port--weight--auto-weights--use-empty-masters--timeout--simulate--pipeline--thresholdadd-node new\_host:new\_port existing\_host:existing\_port--slave--master-iddel-node host:port node\_idset-timeouthost:port millisecondscall host:port command arg arg ..argimport host:port--from--copy--replacehelp (show this help)For check,fix,reshard,del-node,set-timeoutyou can specify the host and port of any working node in the cluster.复制代码

redis-trib.rb 是 redis 作者用 ruby 完成的。redis-trib.rb **命令行工具** 的具体功能如下：

命令 作用 create 创建集群 check 检查集群 info 查看集群信息 fix 修复集群 reshard 在线迁移slot rebalance 平衡集群节点slot数量 add-node 将新节点加入集群 del-node 从集群中删除节点 set-timeout 设置集群节点间心跳连接的超时时间 call 在集群全部节点上执行命令 import 将外部redis数据导入集群 3.3. 安装集群

3.3.1. 启动redis服务节点

运行如下命令启动 6 台 redis 节点：

sudo redis-serverconf/redis-6379.confsudo redis-serverconf/redis-6389.confsudo redis-serverconf/redis-6380.confsudo redis-serverconf/redis-6390.confsudo redis-serverconf/redis-6381.confsudo redis-serverconf/redis-6391.conf复制代码

启动完成后，redis 以集群模式启动，查看各个 redis 节点的进程状态：

$ ps -ef | grep redis-server 0 1908 1 0 4:59下午 ?? 0:00.01 redis-server \*:6379 \[cluster\] 0 1911 1 0 4:59下午 ?? 0:00.01 redis-server \*:6389 \[cluster\] 0 1914 1 0 4:59下午 ?? 0:00.01 redis-server \*:6380 \[cluster\] 0 1917 1 0 4:59下午 ?? 0:00.01 redis-server \*:6390 \[cluster\] 0 1920 1 0 4:59下午 ?? 0:00.01 redis-server \*:6381 \[cluster\] 0 1923 1 0 4:59下午 ?? 0:00.01 redis-server \*:6391 \[cluster\] 复制代码

在每个 redis 节点的 redis.conf 文件中，我们都配置了 cluster-config-file 的文件路径，集群启动时，conf 目录会新生成 **集群** 节点配置文件。查看文件列表如下：

$ tree -L3..├── appendonly.aof├── conf│ ├── node-6379.conf│ ├── node-6380.conf│ ├── node-6381.conf│ ├── node-6389.conf│ ├── node-6390.conf│ ├── node-6391.conf│ ├── redis-6379.conf│ ├── redis-6380.conf│ ├── redis-6381.conf│ ├── redis-6389.conf│ ├── redis-6390.conf│ └── redis-6391.conf├── data│ ├── redis-6379│ ├── redis-6380│ ├── redis-6381│ ├── redis-6389│ ├── redis-6390│ └── redis-6391├── log│ ├── redis-6379.log│ ├── redis-6380.log│ ├── redis-6381.log│ ├── redis-6389.log│ ├── redis-6390.log│ └── redis-6391.log└── redis-trib.rb9directories,20files复制代码

3.3.2. redis-trib关联集群节点

按照 **从主到从** 的方式 **从左到右** 依次排列 6 个 redis 节点。

$ sudo ./redis-trib.rb create --replicas1127.0.0.1:6379127.0.0.1:6380127.0.0.1:6381127.0.0.1:6389127.0.0.1:6390127.0.0.1:6391复制代码

集群创建后，redis-trib 会先将 16384 个 **哈希槽** 分配到 3 个 **主节点**，即 redis-6379，redis-6380 和 redis-6381。然后将各个 **从节点** 指向 **主节点**，进行 **数据同步**。

>>>Creatingcluster>>>Performinghashslotsallocationon6nodes...Using3masters:127.0.0.1:6379127.0.0.1:6380127.0.0.1:6381Addingreplica127.0.0.1:6390to127.0.0.1:6379Addingreplica127.0.0.1:6391to127.0.0.1:6380Addingreplica127.0.0.1:6389to127.0.0.1:6381>>>Tryingtooptimizeslavesallocationforanti-affinity\[WARNING\]SomeslavesareinthesamehostastheirmasterM:ad4b9ffceba062492ed67ab336657426f55874b7127.0.0.1:6379slots:0-5460(5461slots)masterM:df23c6cad0654ba83f0422e352a81ecee822702e127.0.0.1:6380slots:5461-10922(5462slots)masterM:ab9da92d37125f24fe60f1f33688b4f8644612ee127.0.0.1:6381slots:10923-16383(5461slots)masterS: 25cfa11a2b4666021da5380ff332b80dbda97208127.0.0.1:6389replicatesad4b9ffceba062492ed67ab336657426f55874b7S: 48e0a4b539867e01c66172415d94d748933be173127.0.0.1:6390replicatesdf23c6cad0654ba83f0422e352a81ecee822702eS:d881142a8307f89ba51835734b27cb309a0fe855127.0.0.1:6391replicatesab9da92d37125f24fe60f1f33688b4f8644612ee复制代码

然后输入 yes，redis-trib.rb 开始执行 **节点握手** 和 **槽分配** 操作，输出如下：

CanIsettheaboveconfiguration? (type'yes'to accept):yes>>>Nodesconfigurationupdated>>>Assignadifferentconfigepochtoeachnode>>>SendingCLUSTERMEETmessagestojointheclusterWaitingfortheclustertojoin....>>>PerformingClusterCheck(using node127.0.0.1:6379)M:ad4b9ffceba062492ed67ab336657426f55874b7127.0.0.1:6379slots:0-5460(5461slots)master1additionalreplica(s)M:ab9da92d37125f24fe60f1f33688b4f8644612ee127.0.0.1:6381slots:10923-16383(5461slots)master1additionalreplica(s)S:48e0a4b539867e01c66172415d94d748933be173127.0.0.1:6390slots: (0slots)slavereplicatesdf23c6cad0654ba83f0422e352a81ecee822702eS:d881142a8307f89ba51835734b27cb309a0fe855127.0.0.1:6391slots: (0slots)slavereplicatesab9da92d37125f24fe60f1f33688b4f8644612eeM:df23c6cad0654ba83f0422e352a81ecee822702e127.0.0.1:6380slots:5461-10922(5462slots)master1additionalreplica(s)S:25cfa11a2b4666021da5380ff332b80dbda97208127.0.0.1:6389slots: (0slots)slavereplicatesad4b9ffceba062492ed67ab336657426f55874b7\[OK\]Allnodesagreeaboutslotsconfiguration.>>>Checkforopenslots...>>>Checkslotscoverage...\[OK\]All16384slotscovered.复制代码

执行 **集群检查**，检查各个 redis 节点占用的 **哈希槽**（slot）的个数以及 slot **覆盖率**。16384 个槽位中，**主节点** redis-6379、redis-6380 和 redis-6381 分别占用了 5461、5461 和 5462 个槽位。

3.3.3. redis主节点的日志

可以发现，通过 BGSAVE 命令，**从节点** redis-6389 在 **后台** 异步地从 **主节点** redis-6379 同步数据。

$ catlog/redis-6379.log1907:C05Sep16:59:52.960\# oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo1907:C05Sep16:59:52.961\# Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=1907, just started1907:C05Sep16:59:52.961\# Configuration loaded1908:M05Sep16:59:52.964\* Increased maximumnumberofopen filesto10032(itwas originallysetto256).1908:M05Sep16:59:52.965\* No cluster configuration found, I'm ad4b9ffceba062492ed67ab336657426f55874b71908:M05Sep16:59:52.967\* Running mode=cluster, port=6379.1908:M05Sep16:59:52.967\# Server initialized1908:M05Sep16:59:52.967\* Readytoaccept connections1908:M05Sep17:01:17.782\# configEpoch set to 1 via CLUSTER SET-CONFIG-EPOCH1908:M05Sep17:01:17.812\# IP address for this node updated to 127.0.0.11908:M05Sep17:01:22.740\# Cluster state changed: ok1908:M05Sep17:01:23.681\* Slave127.0.0.1:6389asksforsynchronization1908:M05Sep17:01:23.681\* Partial resynchronizationnotaccepted: Replication ID mismatch (Slave askedfor'4c5afe96cac51cde56039f96383ea7217ef2af41',myreplication IDs are '037b661bf48c80c577d1fa937ba55367a3692921'and'0000000000000000000000000000000000000000')1908:M05Sep17:01:23.681\* Starting BGSAVEforSYNCwithtarget: disk1908:M05Sep17:01:23.682\* Background saving startedbypid19521952:C05Sep17:01:23.683\* DB savedondisk1908:M05Sep17:01:23.749\* Background saving terminatedwithsuccess1908:M05Sep17:01:23.752\* Synchronizationwithslave127.0.0.1:6389succeeded复制代码

参考

《Redis 开发与运维》

**Java高架构师、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频免费学习加群：835638062 点击链接加入群聊【Java高级架构】：https://jq.qq.com/?\_wv=1027&k=5S3kL3v**

[https_www.jianshu.com_p_84dbb25cc8dc]: https://www.jianshu.com/p/84dbb25cc8dc
[495]: /images/20220114/0d2b625c2897435ca6873e1c5b872339.png
[640]: /images/20220114/b6028a2abda3434b9389d9178096cf06.png
[640 1]: /images/20220114/cea26b722c7a40cab43810a400cf1a15.png
[640 2]: /images/20220114/d4eac1c892d94fe886ef3d6b065a3780.png
[640 3]: /images/20220114/4aa217b963844737a568d8fa6c805248.png
[640 4]: /images/20220114/7729f6409ddd4b6c88f47f6e92356a1c.png
[640 5]: /images/20220114/b31c53e8c44d46adbcd7c4fe8a740504.png
[640 6]: /images/20220114/e2c4235b9fe147f1a8853e66a7b66490.png