当前位置：首页 > news >正文

Redis主从+哨兵+集群分片

news 来源：原创 2025/5/24 15:36:31

redis主从：

什么是主从复制：

Redis主从复制是一种数据同步机制，允许一个Redis服务器（主节点）将其数据复制到一个或多个Redis服务器（从节点）。主节点负责处理写操作，而从节点则复制主节点的数据，并可以处理读操作。这种机制提高了系统的可用性和读取性能。

为什么出现redis主从：

Redis主从复制的出现主要是为了解决单点故障和性能瓶颈问题。在单节点Redis系统中，如果主节点发生故障，整个系统将无法提供服务。通过引入从节点，可以在主节点故障时快速切换到从节点，保证系统的高可用性。此外，主从复制还可以分担主节点的读取压力，提升系统的整体性能。

redis主从的功能：

读写分离，容灾备份，数据备份，水品和扩容（支持高并发）

数据冗余与备份：从节点复制主节点的数据，提供了数据冗余，可以在主节点数据丢失时进行恢复。

读写分离：主节点处理写操作，从节点处理读操作，有效分担主节点的负载，提升系统性能。

高可用性：在主节点发生故障时，可以快速切换到从节点，保证系统的持续可用性。

负载均衡：通过配置多个从节点，可以将读请求分散到不同的从节点上，实现负载均衡。

数据同步：主从复制机制确保主节点和从节点之间的数据一致性，从节点会实时或定期同步主节点的数据。

redis主从基础命令：

小注意点：redis-cli -a 111111 -p 6666 (不写-p 默认是6379)

命令：info replication:

可以查看复制节点的主从关系和配置信息

命令：replicaof <masterip> <masterport>:

写在配置文件中，体现从库连接的是哪个主库，他的ip地址和端口号，如主库配置密码，在配置文件中，还要配置masterauth <主机密码>

命令：slaveof <masterip> <masterport>:

从节点与master断开连接时，如果没有在配置文件中写明我们的连接主机信息，需要使用命令重新连接
如果在运行时间，该换主机，可以使用命令直接动态的换成新的主节点，他会停止与原主节点的同步关系，转而和新的主节点同步。

# 配置Redis主从复制的示例
# 在从节点的配置文件中添加以下配置
slaveof <masterip> <masterport>

命令：slaveof no one :

是当前数据库停止和其他数据库的数据听不，装成主数据库（master），自立为王。

配置文件修改：

将bind:属性注释
关闭保护模式
指定端口
指定当前工作目录dir(默认是在bin目录下)
修改进行id文件：pidfile (使用默认可以，但是需要知道这个配置)
日志文件：logfile
访问密码：requirepass:
dump.rdb 文件名字
是否开启aof
如果是从机：配置replicaof <masterip> <masterport>
为10展示一个案例：replicaof 168.192.0.1 6379
从机还要配置：找到主机之后需要知道主机的密码才可以配置：masterauth <String:主机密码>

redis主仆的细节：

将配置文件固定时：

从机是否可以执行写命令：从机只可以读操作不可以写操作，展示了读写分离
从机是从切入点开始复制，还是从头开始复制：他是从头开始复制。
主机shutdown后，从机是否会成为主机：从机还是从机，可以读取数据，但是需要等待主机归来。
主机shutdown之后，重启的话，主从关系时候存在：继续存在。从机继续顺利复制
某台从机down之后，master继续写入，从机重起之后还是可以将所有的消息成功复制，不会出现消息的空白。

使用命令的形式的主从关系：

我们当前的三台主机的方式是一主二仆，在配置文件中没有添加我们的replicaof <masterip> <masterport>，每天redis都是master.

使用命令的形式执行主机，这是的细节上是如何的呢：

其实在问题上我们可以发现，我们的配置不是物理的写在配置文件中，我们在每个redis启动时通过执行命令slaveof <ip> <port> 来确定主从关系。

如果我们的从机重启之后，不再存在主从的关系，他就是一个主机。

redis的薪火相传

Salve也可以是下一个Slave的master,这是我们生成了一个链式的结构，减轻了主master的压力。

从机在已经有了主机之后，如果更换主机，原主机的复制数据将会被清除。将新的主机的数据写入。（即使是在我们的薪火相传，他也是先删除在重新复制）

小注意点：作为slave的点，即使是作为了master节点，只要是它还有自己的master，就不可以写入

redis的反客为主：

使用命令 slave no one ,这是我们以前复制的数据会清除。

常见面试题和原理讲解：

你在使用redis主从时使用过哪些命令：

在配置文件中配置了：replication <ip> <port> 指明了主机的ip和端口
使用slave <ip> <port> 建立临时的主从关系或者是改换master
使用slave no one 将当前从机设置为主机

主从复制的工作流程：

slave启动，连接master后发送一个sync命令。如果是首次链接，一次完成同步，这是slave的数据先删除之后复制master的数据。（也可以说是被覆盖）
master收到sync的命令时，开始在后台生成快照，同时收集所有的接收到的用于修改数据集命令的缓存起来（在生成快照的同时，master节点会继续处理客户端的写操作（如SET、DEL等命令），并将这些修改数据集的命令缓存起来。这些缓存的命令被称为“复制缓冲区”（replication buffer），用于记录在生成快照期间发生的所有写操作。），master节点执行持久化之后，master将rdb文件和所有的缓存的命令发送到我们的slave,完成同步。
发送心跳，保持连接，默认是10秒： repl-ping-replica-period 10(配置文件)
Master将新的操作继续增量复制
从机下线之后，我们会在他文件的缺失的部分开始同步，因为master会检查backlog中的offset.master和slave都会保存一个复制的offset和一个masterId.Master会把已经复制的offset后面的数据继续复制。

主从复制的缺点：

复制延时，信号衰减：

对于所有的写操作都是在master上的，之后同步到slave上，这就会出现延迟，当系统繁忙时，延迟会更加严重，如果我们的slave的节点数增加，层次结构增加也会加重这个问题。

master如果挂了怎么办？

在master挂掉之后我们的slave不会选举出一个作为新的主机，这是从节点只是可以读，但是不可以写。

这是我们的解决方式就是哨兵。

redis哨兵(sentinel)：

什么是redis哨兵：

Redis哨兵（Sentinel）是Redis的高可用性解决方案，用于监控和管理Redis主从复制集群。哨兵系统可以自动检测主节点的故障，并在主节点不可用时，自动将一个从节点提升为新的主节点，确保系统的持续可用性。

对上面的定义进行解析：他就是监控主节时候发生故障，如果发生故障，从节点通过投票选举的方式将一个从库变为主库，继续服务于系统

redis哨兵的作用：

Redis哨兵的主要作用包括监控、通知、自动故障转移和配置提供。

监控：监控redis的运行状态：哨兵会持续监控Redis主节点和从节点的健康状态，确保它们正常运行。如果某个节点出现故障，哨兵会立即检测到。

通知：在master宕机时：当哨兵检测到Redis节点出现故障时，可以通过配置的方式通知系统管理员或其他应用程序，以便及时处理。

自动故障转移：如果主节点发生故障，哨兵会自动将一个从节点提升为新的主节点，并重新配置其他从节点以复制新的主节点。这个过程是自动的，无需人工干预。

配置提供：哨兵可以作为客户端查询当前Redis主节点的地址。客户端可以通过哨兵获取最新的主节点信息，从而确保连接到正确的节点。

哨兵的实战案例：

架构展示:

为我们的主从复制的系统上加上几台哨兵机制。哨兵不能是一台（官方建议集群部署，奇数部署便于投票选举），必须也是集群部署，哨兵中不放置数据只是完成他本身的任务。

我们可以采用的方式是一主二从+三台哨兵。这是架构图。

哨兵配置：

配置哨兵节点：

配置哨兵配置文件sentinel.conf (这个配置文件是哨兵的，不是redis的，因为他不放置数据，只是完成监控，通知，故障转移和配置服务等作用)。

我们的烧饼配置文件默认在安装包的路径下:

在实际使用时我们通常会把配置文件拷贝一份放置到工作的目录下进行修改，在安装路径中保留一份原始的文件便于后续的使用和出现错误时重新开始配置。

修改配置文件：

将bind:属性注释
关闭保护模式 protected-mode : no
指定端口
指定当前工作目录dir(默认是在bin目录下)
修改进行id文件：pidfile (使用默认可以，但是需要知道这个配置)
日志文件：logfile
dir：配置工作目录
配置：sentinel monitor <master-name> <ip> <redis-port> <quorum>
配置：sentinel auth-pass <master-name> <password>

这些配置时基础的配置：

下面的配置是我们的哨兵新添加的配置：

命令：sentinel monitor <master-name> <ip> <redis-port> <quorum>：

在上面的截图中搭建可以看见它使用的方式的案例，他是 Redis Sentinel 配置中的一个关键命令，用于监控 Redis 主节点。

<master-name>：指定要监控的 Redis 主节点的名称。这个名称是用户定义的，用于标识主节点。

<ip>：Redis 主节点的 IP 地址。

<redis-port>：Redis 主节点的端口号。

<quorum>：法定人数，表示需要多少个 Sentinel 实例同意才能触发故障转移。必须小于或等于配置的 Sentinel 实例总数。

<quorum>：法定人数：网络是不可靠的，因为我们的sentinel会因为网络的拥塞造成他误认为一个master已经宕机了，这是我们需要多个sentinel互相沟通来确认是否是真的死掉了，他的意思是只用我们的sentinel集群中的最少quorum个哨兵认为master出现了故障，他才会进行master的下线和故障转移。多个哨兵的方式保证了系统的公平性和高可用。减少了因为网络问题造成的误判。

命令： sentinel auth-pass <master-name> <password>

用于为 Sentinel 监控的主节点（master）设置认证密码。

<master-name>：Sentinel 监控的主节点名称，即在 Sentinel 配置文件中定义的 mymaster 或其他名称。

<password>：用于认证的密码，必须与主节点的 requirepass 配置一致。

下面的配置使用默认配置就可以.........，但是还是要了解一下。

主管下线

指定的多少毫秒之后，主节点没有应答哨兵，这是哨兵主观认为主节点下线。（默认是30分钟）

sentinel parallel-syncs mymaster 1：

在发生故障转移时，我们再选出新的master之后，设置的主节点和从节点直接数据同步的并发数量。解释：默认设置为 1 表示主节点一次只能与一个从节点进行同步，这样可以避免过多的同步操作对主节点造成过大的负载。

sentinel failover-timeout <master-name> <milliseconds>：

故障转移的超时时间，如果超过设置时间，证明故障转移失败。

sentinel client-reconfig-script <master-name> <script-path>

sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

客户端重新配置主节点参数脚本

sentinel notification-script <master-name> <script-path>

配置当某一事件发生时执行的脚本。

哨兵配置文件编写：

对于配置文件大家可以在配置文件中修改，，也可以自己写，这个无关紧要。

上面的图片是小编在学习时使用的配置文件，大家按着自己的主机和端口号自行配置。

我们的bind 0.0.0.0 :0.0.0.0 是一个特殊的 IP 地址，表示“所有可用的网络接口”。当服务器绑定到 0.0.0.0 时，它将接受来自任何 IP 地址的请求

主从配置文件小修改：

当我们采用这种方式时，我们第一次的主机也最好讲master_auth 配置一下。因为他可能在后续时变为从机，如果没有配置密码的话，他访问新的主机时，会出现错误：master_link_status:down

启动哨兵的命令：

启动redis的主从复制:

//按着自己的配置文件位置，自行修改位置

redis-server ../conf/redis.conf

//开启客户端时也是按着自己的密码和端口号自行修改

redis-cli -a 111111 -p 6379

启动哨兵：

redis-sentinel /path/to/sentinel.conf
redis-server /path/to/sentinel.conf --sentinel
//对于启动的命令搭建可以去看官网.....

High availability with Redis Sentinel | Docs

配置重写

我们在配置成功启动之后发现我们的sentinel.conf文件发生变化:

实战演示：

环境模拟：主机master挂了：

两台从机的数据不会丢失，会在两天主机中选举出一个从机变为主机。这个关系我们可以通过命令info replication 查看

通过查看sentinel的日志文件我们可以看见在知道主机宕机之后重新进行选举，选出新的主机master.

这是我们有了一个新的疑问，这是如果我们现在已经选出了新的master，这是如果老的master回来了，会出现双master冲突吗？谁会是新的master?

即使是我们的老的主机回来之后，他就是变为了slave,不会出现冲突。

老master配置文件

但是我们老的主机的配置文件会添加一些配置：

在新添加的配置中指明了他的主机地址和端口号，指明了RDB的自动触发条件

新的master配置文件

配置文件中的replicaof <masterip> <masterport>:被删除。他作为从机是配置的主库信息被删除，她变为主机。

Redis哨兵故障转移运行流程：

首先是我们配置的主观下线：在redis的烧饼集群中，只要是有一个哨兵节点认为我们的master已经下线，当前redis集群可能已无master。
这时哨兵开始投票，如果我们的节点中的认为imaster挂了的节点投票数量<quorum,这是任务master没有故障。如果我们的哨兵中的>=quorum 个哨兵节点认为当前master已经挂了。开始执行故障转移。
我们在执行故障转移之前，现在多个哨兵节点之间选出一个哨兵作为leader节点，整个故障转移由leader发起和负责。选举leader的算法采用的是Raft算法。
之后由我们的leader节点开始故障转移，选举新的master节点，在slave中选举新的master时，他的比较方式是：第一权重是：比较权限（Priority权限高的是新的master,如果权限一样的话），比较数据拷贝的偏移量（replication offset（大））,最后比较的是Run ID（Run ID最小成为新的master）
选举出新的master之后，sentinel对新的master执行slave no one让他成为新的master节点，之后sentinel向其他的从节点发送命令，让剩余的从节点成为新master的slave（执行slaveof命令）。
如果老的master节点重新上线，配置为新的master的slave节点，sentinel修改他的配置。

哨兵使用的最佳实践

哨兵节点应是多个，集群部署，确保高可用
节点数是奇数，便于选举
各个哨兵节点的配置是一样的
哨兵配置在docker中，注意端口yingshe
哨兵+主从，不能保证数据的零丢失（leader选举，master的选举时写入的数据都会丢失。网络的延迟，数据写入的量过大（多考虑临界时间点思考问题））

Redis集群分片

我们的主从+哨兵机制当他的master挂机之后，不能保证数据不丢失，为了解决这个问题我们的redis推荐我们在生产环境中使用redis集群。一个redis集群中可以配置多个master节点。这就解决了我们master的单点故障。下面的文章中小编为大家介绍一下redis的集群分片。

什么是集群：

Redis 集群是 Redis 提供的分布式解决方案，用于解决单机 Redis 容量有限、吞吐量瓶颈以及高可用性问题。它通过将数据分散到多个节点（Node）上，实现数据分片（Sharding）、自动故障转移（Failover）和动态扩展，适用于大规模数据存储和高并发场景。

集群同时也为我们解决了主从复制+哨兵机制显得数据丢失问题等问题，所提出的更加优秀的架构。它通过多个主节点（master）协同工作，确保系统的高可用性和数据一致性。

槽位slot:

槽位是redis集群中的最小单位，他为了编辑我们每个数据是归于哪个redis管理。

槽位的作用：

数据路由：客户端通过计算键的哈希值确定其对应的槽位，再根据集群的槽位分配表（记录每个槽位所属的节点），将请求转发到目标节点。（我们的redis默认使用的算法是：CRC16,通过这个hash算法计算出我们的槽位信息，将数据放置到管理这个槽位的redis中。
Redis 集群将所有数据划分为 16384 个槽位（Slot，范围：0~16383），每个键通过特定的哈希算法映射到其中一个槽位上。如果我们现在是三台redis主机，每个注解就会管理三分之一的槽位。）
负载均衡：通过将槽位均匀分配到不同节点，实现数据和请求的负载均衡。
动态扩展 / 收缩：新增或移除节点时，只需迁移部分槽位及其对应的数据，无需整体重构集群。

集群分片中的分片：

定义

分片（Sharding）是将数据分散存储到多个节点的机制，每个节点负责存储集群中的部分数据。（一个master可以认为是一个分片）

在 Redis 集群中，每个分片对应一组槽位，由一个主节点（Primary）和若干从节点（Replica）组成，主节点负责读写操作，从节点用于故障转移和高可用。

分片的组成

主节点：每个分片必须有一个主节点，负责处理槽位对应的读写请求。
从节点：可选，作为主节点的备份，当主节点故障时自动切换为新的主节点（通过选举机制）。

槽位与分片的关系

一个分片包含 一个或多个连续的槽位（通常均匀分配）。例如：
- 节点 A 负责槽位 0~5460
- 节点 B 负责槽位 5461~10922
- 节点 C 负责槽位 10923~16383
每个槽位只能属于一个分片（主节点），确保数据不重复、不遗漏。

Redis集群使用分片+槽位的优势：

便于数据的管理：

每个节点维护一张 槽位分配表，记录 16384 个槽位与节点的映射关系（例如：哪些槽位属于当前节点，哪些属于其他节点）。
节点通过 Gossip 协议同步槽位分配信息，确保集群中所有节点的槽位表一致。

便于动态的扩容和缩容

当需要扩展集群（添加新节点）时，通过 CLUSTER REBALANCE 命令将部分槽位从旧节点迁移到新节点，迁移过程中不影响集群服务。
迁移的最小单位是单个键，但通常以槽位为单位批量迁移，确保数据分布均匀。

槽位映射算法的选择：

哈希取余分区

计算key的hash值之后对于当前的master节点数直接取余数，例如当前是3台，就是hash(key)/N
优点：简单粗暴，直接有效，只是需要预估数据规划节点，就可以保证一段时间的数据支撑，通过对于数值的计算，保证每个主机处理一部分请求，起到负载均衡和分治的作用。
缺点是： 进行扩容和缩容时，所有数据的映射关系需要重新计算，不然数据会出现问题，利于如果hash(key)==4,这个数据在主机1上，但是现在如果是4个的话，就是在主机4上，这是如果数据的映射不改变的话，会出现问题。

一致性hash算法

一致性hash算法再出现是就是为了解决分布式缓存系统的数据变动和映射问题。某个机器宕机了，他的分母数量改变，自然数的余数就不OK了。
创建步骤：1.算法构建一致性hash环，2.将集群中各个节点的IP值映射到环上的某一个位置 3.计算key值，讲值落到hash环中，按着逆时针方向，遇到的第一个节点值，就是数据放置的主机。
如果我们的某一个节点出现问题时，我们的数据按着逆时针继续找就可以了，只影响相邻节点的数据，减少了数据迁移量。解决了哈希取余分区的问题。
他的优点是解决了节点扩容时的数据映射问题，具有容错性和扩张性
他的缺点是容易出现数据倾斜问题

哈希分槽算法

它解决了一致性hash算法的数据倾斜问题，哈希槽实际上就是一个数组，数组的大小是2的14次方。
它用于管理数据和节点直接的关系。节点之上放置的是槽，槽中放置的是数据。
一共有16384个槽，首先是对于Key计算hash值，之后按着hash值讲数据放置到他计算之后的槽中。因为槽的单位是固定的，处理比较容易，数据的移动较为方便。
他计算key值的方式时CRC16.

经典面试题：

为什么redis集群的最大槽位数是2的14次方：

如果我们使用的大小是65536(2^16),发送的心跳包的消息头大小就是8K,这是发送的心跳包过于庞大，如果是16384的话，他的大小是2K。
redis的主节点数量不会超过1000，对于1000个节点的redis集群，16384个槽位够用
槽位越少，节点少的情况下，压缩比高，便于压缩。（Redis主节点的配置中，她所负责的hash槽是通过一张bitmap的形式来保存的，在传输的过程中对于bitmap进行压缩，如果bitmap的填充率(slots/N(N是节点数))高的话，压缩率低

redis集群不保证强一致性，它采用的是异步复制。有可能将数据丢失。他是AP,不是CP。

实战搭建redis集群：

编写master配置文件：

bind 0.0.0.0    #标志任何ip地址都可以连接
daemonize yes  #设置redis后台启动（docker部署将这个设置为no）
protected-mode no   #关闭保护模式
port 6381                 #定义端口
logfile "/myredis/cluster/cluster6381.log"    #日志文件位置
pidfile /myredis/cluster6381.pid                #进程pid
dir /myredis/cluster    #工作目录，放置持久化文件...
dbfilename dump6381.rdb   #rdb持久化配置文件名
appendonly yes   #开启AOF
appendfilename "appendonly6381.aof"  #AOF持久化配置文件名
requirepass 111111         #请求密码
masterauth 111111         #放置成为slave结点之后，无法加入集群配置的密码cluster-enabled yes       #是否开启集群  
cluster-config-file nodes-6381.conf   #集群节点配置文件名
cluster-node-timeout 5000     #集群超时时间

编写slave配置文件：

bind 0.0.0.0
daemonize yes
protected-mode no
port 6382
logfile "/myredis/cluster/cluster6382.log"
pidfile /myredis/cluster6382.pid
dir /myredis/cluster
dbfilename dump6382.rdb
appendonly yes
appendfilename "appendonly6382.aof"
requirepass 111111
masterauth 111111cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000

其他的节点的配置文件大家按着这个模板直接修改就可以了。

使用redis-cli构建主从关系：

执行的命令是：（展示创建一个三主三从的集群）

redis-cli -a 111111 --cluster create --cluster-replicas 1 192.168.111.175:6381 192.168.111.175:6382 192.168.111.172:6383 192.168.111.172:6384 192.168.111.174:6385 192.168.111.174:6386

--cluster-replicas 1 表示为每个master创建一个slave节点 ,这就指定了每个master的从机

执行命令之后的截图如下：显示创建集群成功

在上面的截图中我们可以发现，将所有的节点关系列举清晰。

之后集群会创建集群的配置：

着我的例子中他的名字是：

这是在我们的节点使用命令：replication info 会显示出来节点的信息。注意这个显示的信息只是这个节点的信息。

也可以使用命令：cluster nodes 会显示当前集群的节点关系

命令：cluster info :查看集群的信息，多少个槽位，几个节点

槽位范围引发的路由问题：

解决方式：路由到位

配置到现在，如果直接进行读写操作的话，会出现问题，问题的信息是，再插入是，。显示需要到主机6385才可以插入成功，出现这个问题的原因是没有路由到位。

解决的方式就是在连接客户端时，命令添加一个 -c，表示路由： redis-cli -a 111111 -p 6381 -c

之后在写时，就会自动的路由了。

总结：使用集群时，连接的命令带有-c

查看槽位的命令：

cluster keyslot k1 :显示key1的槽位号

主从分片的容错切换：

假设当前我的一个主机出现了问题，在主机出现问题之后，这个主机的从机是不是会成为主机呢？

上面的信息有开始相比，可以发现主机在挂掉之后他的从机成公的成为了主机。

原来的主机回来之后，他还会成为主机吗？

他回来之后，就变为了slave节点。

集群不保证数据一致性100%正确，一定会有数据丢失的情况。但比主从复制+哨兵要好得多。

手动故障转移+节点从属调整：

根据上述的情况，我们的集群中有一组主从关系与我们开始时不同了，为了他还是和我们刚创建集群时的节点序列的一直，我们通过命令的形式调整节点从属关系

还是继续上面的案例来，将刚刚的主从关系倒置：

开始执行命令：cluster failover 这个命令执行的位置是在我们想调整的主机上，执行之后这个主机就变成了他的相反数...

发现节点从属关系调整成功。

集群扩容：

案例展示：

现在再添加一主一从：

还是像上述一样创建配置文件，见上文
将新的节点启动，注意现在的节点都是master节点（redis-server ../conf/***.conf）
将其中一个节点作为我们第四个master节点加入集群: redis-cli -a 密码 add-node <ip>:<port> <ip>:<port> 红色的位置是我们的集群中存在的节点的地址和端口，就像是我们如果像加入到一个组织，需要一个引路人
新的master节点加入之后，查看我们的节点信息：redis-cli -a 111111 --cluster check <ip>:<port> 发现现在没有分配槽位。
执行命令reshard:redis-cli -a 111111 --cluster reshard <ip>:<port> ,他的意思是在这个节点存在的集群中，重新分配节点，
询问移动多少节点，
输入新的master的地址和端口：
查看我们的节点信息：redis-cli -a 111111 --cluster check <ip>:<port>
新的槽号分配之后，可以发现我们的移动方式是在我们原有的三个大哥一个节点分给新的一点，不是真的重新分配，这样的话节点移动的数量小。

将节点加入到集群中，并作为新的master的从节点命令：

命令：redis-cli -a 密码 --cluster add-node ip:新slave端口 ip:新master端口 --cluster-slave --cluster-master-id 新主机节点ID

redis-cli -a 111111 --cluster add-node 192.168.111.174:6388 192.168.111.174:6387 --cluster-slave --cluster-master-id 4feb6a7ee0ed2b39ff86474cf4189ab2a554a40f------- 这个是6387的编号，按照自己实际情况