Redis 架构模式详解（单机、主从、哨兵、集群模式），已经Redis规范详解

深碍√TFBOYSˉ_ 2022-12-04 08:51 377阅读 0赞

# 前言 #

话说有一名意大利程序员，在 2004 年到 2006 年间主要做嵌入式工作，之后接触了 Web，2007 年和朋友共同创建了一个网站，并为了解决这个网站的负载问题（为了避免 MySQL 的低性能），于是亲自定做一个数据库，并于 2009 年开发完成，这个就是 Redis。这个意大利程序员就是 Salvatore Sanfilippo 江湖人称 Redis 之父，大家更习惯称呼他 Antirez。

![format_png][]

Redis 技术越来越火爆，其超高的性能，简洁轻量的设计，易上手，分布式架构的支持，在缓存等领域出色的表现造就了它现在的地位。

官方的 Benchmark 数据：测试完成了 50 个并发执行 10W 个请求。设置和获取的值是一个 256 字节字符串。

结果：读的速度是 110000次/s，写的速度是 81000次/s。

为了满足开发市场需求，Redis 支持**单机**、**主从**、**哨兵**、**集群**多种架构模式，本文带大家详细讲解这几种架构模式的区别。

# 模式详解 #

## 单机模式 ##

![format_png 1][]

单机模式顾名思义就是安装一个 Redis，启动起来，业务调用即可。例如一些简单的应用，并非必须保证高可用的情况下可以使用该模式。

### 优点 ###

*  部署简单；
 *  成本低，无备用节点；
 *  高性能，单机不需要同步数据，数据天然一致性。

### 缺点 ###

*  **可靠性保证不是很好，单节点有宕机的风险。**
 *  单机高性能受限于 CPU 的处理能力，Redis 是单线程的。

单机 Redis 能够承载的 QPS（每秒查询速率）大概在几万左右。取决于业务操作的复杂性，Lua 脚本复杂性就极高。假如是简单的 key value 查询那性能就会很高。

假设上千万、上亿用户同时访问 Redis，QPS 达到 10 万+。这些请求过来，单机 Redis 直接就挂了。系统的瓶颈就出现在 Redis 单机问题上，此时我们可以通过**主从复制**解决该问题，实现系统的高并发。

## 主从复制 ##

![format_png 2][]

Redis 的复制（Replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（Master），而通过复制创建出来的复制品则为从服务器（Slave）。 只要主从服务器之间的网络连接正常，主服务器就会将写入自己的数据同步更新给从服务器，从而保证主从服务器的数据相同。

数据的复制是单向的，只能由主节点到从节点，简单理解就是从节点只支持读操作，不允许写操作。主要是读高并发的场景下用主从架构。主从模式需要考虑的问题是：当 Master 节点宕机，需要选举产生一个新的 Master 节点，从而保证服务的高可用性。

### 优点 ###

*  Master/Slave 角色方便水平扩展，QPS 增加，增加 Slave 即可；
 *  降低 Master 读压力，转交给 Slave 节点；
 *  主节点宕机，从节点作为主节点的备份可以随时顶上继续提供服务；

### 缺点 ###

*  可靠性保证不是很好，主节点故障便无法提供写入服务；
 *  没有解决主节点写的压力；
 *  数据冗余（为了高并发、高可用和高性能，一般是允许有冗余存在的）；
 *  **一旦主节点宕机，从节点晋升成主节点，需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预；**
 *  主节点的写能力受到单机的限制；
 *  主节点的存储能力受到单机的限制。

## 哨兵模式 ##

![format_png 3][]

主从模式中，当主节点宕机之后，从节点是可以作为主节点顶上来继续提供服务，但是需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。

于是，在 Redis 2.8 版本开始，引入了哨兵（Sentinel）这个概念，在**主从复制的基础**上，哨兵实现了**自动化故障恢复**。如上图所示，哨兵模式由两部分组成，哨兵节点和数据节点：

*  哨兵节点：哨兵节点是特殊的 Redis 节点，不存储数据；
 *  数据节点：主节点和从节点都是数据节点。

Redis Sentinel 是分布式系统中监控 Redis 主从服务器，并提供主服务器下线时自动故障转移功能的模式。其中三个特性为：

*  监控(Monitoring)：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常；
 *  提醒(Notification)：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知；
 *  自动故障迁移(Automatic failover)：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。

接下来我们了解一些 Sentinel 中的关键名词，然后系统讲解下哨兵模式的工作原理。

### 定时任务 ###

Sentinel 内部有 3 个定时任务，分别是：

*  每 1 秒每个 Sentinel 对其他 Sentinel 和 Redis 节点执行 `PING` 操作（监控），这是一个**心跳检测**，是失败判定的依据。
 *  每 2 秒每个 Sentinel 通过 Master 节点的 channel 交换信息（Publish/Subscribe）；
 *  每 10 秒每个 Sentinel 会对 Master 和 Slave 执行 `INFO` 命令，这个任务主要达到两个目的：
    
     *  发现 Slave 节点；
     *  确认主从关系。

### 主观下线 ###

所谓主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断，即单个 Sentinel 认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。

主观下线就是说如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 会将这个服务器标记为主观下线（SDOWN）。

### 客观下线 ###

客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过命令互相交流之后，得出的服务器下线判断，然后开启 failover。

只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（ODOWN）。只有当 Master 被认定为客观下线时，才会发生故障迁移。

### 仲裁 ###

仲裁指的是配置文件中的 `quorum` 选项。某个 Sentinel 先将 Master 节点标记为主观下线，然后会将这个判定通过 `sentinel is-master-down-by-addr` 命令询问其他 Sentinel 节点是否也同样认为该 addr 的 Master 节点要做主观下线。最后当达成这一共识的 Sentinel 个数达到前面说的 `quorum` 设置的值时，该 Master 节点会被认定为客观下线并进行故障转移。

`quorum` 的值一般设置为 Sentinel 个数的**二分之一加 1**，例如 3 个 Sentinel 就设置为 2。

### 哨兵模式工作原理 ###

1.  每个 Sentinel 以每秒一次的频率向它所知的 Master，Slave 以及其他 Sentinel 节点发送一个 `PING` 命令；
2.  如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过配置文件 `own-after-milliseconds` 选项所指定的值，则这个实例会被 Sentinel 标记为**主观下线**；
3.  如果一个 Master 被标记为主观下线，那么正在监视这个 Master 的所有 Sentinel 要以每秒一次的频率确认 Master 是否真的进入主观下线状态；
4.  当有**足够数量的 Sentinel**（大于等于配置文件指定的值）在**指定的时间范围内确认** Master 的确进入了主观下线状态，则 Master 会被标记为**客观下线**；
5.  如果 Master 处于 **ODOWN 状态**，则投票自动选出新的主节点。将剩余的从节点指向新的主节点继续进行数据复制；
6.  在正常情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有 Master，Slave 发送 `INFO` 命令；当 Master 被 Sentinel 标记为客观下线时，Sentinel 向已下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次；
7.  若没有足够数量的 Sentinel 同意 Master 已经下线，Master 的客观下线状态就会被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效回复，Master 的主观下线状态就会被移除。

### 优点　 ###

*  哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都有；
 *  主从可以自动切换，系统更健壮，可用性更高；
 *  Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

### 缺点 ###

*  主从切换需要时间，会丢失数据；
 *  还是没有解决主节点写的压力；
 *  主节点的写能力，存储能力受到单机的限制；
 *  动态扩容困难复杂，对于集群，容量达到上限时在线扩容会变得很复杂。

## 集群模式 ##

主从模式中，当主节点宕机之后，从节点是可以作为主节点顶上来继续提供服务，但是需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。于是，在 Redis 2.8 版本开始，引入了**哨兵（Sentinel）**这个概念，在**主从复制的基础**上，哨兵实现了**自动化故障恢复**。

哨兵模式中，单个节点的写能力，存储能力受到单机的限制，动态扩容困难复杂。于是，Redis 3.0 版本正式推出 **Redis Cluster 集群**模式，有效地解决了 Redis 分布式方面的需求。Redis Cluster 集群模式具有**高可用**、**可扩展性**、**分布式**、**容错**等特性。

![format_png 4][]

创建命令：

**ip=192.169.0.23**

**./bin/redis-cli --cluster create $ip:7001 $ip:7002 $ip:7003 $ip:7004 $ip:7005 $ip:7006 --cluster-replicas 1**

Redis Cluster 采用无中心结构，**每个节点都可以保存数据**和整个集群状态，每个节点都和其他所有节点连接。Cluster 一般由多个节点组成，节点数量至少为 6 个才能保证组成完整高可用的集群，其中三个为主节点，三个为从节点。三个主节点会分配槽，处理客户端的命令请求，而从节点可用在主节点故障后，顶替主节点。

如上图所示，该集群中包含 6 个 Redis 节点，3 主 3 从，分别为 M1，M2，M3，S1，S2，S3。除了主从 Redis 节点之间进行数据复制外，所有 Redis 节点之间采用 Gossip 协议进行通信，交换维护节点元数据信息。

总结下来就是：读请求分配给 Slave 节点，写请求分配给 Master，数据同步从 Master 到 Slave 节点。

### 分片 ###

单机、主从、哨兵的模式数据都是存储在一个节点上，其他节点进行数据的复制。而单个节点存储是存在上限的，集群模式就是把数据进行**分片**存储，当一个分片数据达到上限的时候，还可以分成多个分片。

Redis Cluster 采用**虚拟哈希槽分区**，所有的键根据哈希函数映射到 0 ~ 16383 整数槽内，计算公式：`HASH_SLOT = CRC16(key) % 16384`。每一个节点负责维护一部分槽以及槽所映射的键值数据。

![format_png 5][]

**Redis Cluster 提供了灵活的节点扩容和缩容方案。在不影响集群对外服务的情况下，可以为集群添加节点进行扩容也可以下线部分节点进行缩容**。可以说，槽是 Redis Cluster 管理数据的基本单位，集群伸缩就是槽和数据在节点之间的移动。

这种特性允许在集群中轻松地添加和删除节点。同样的如果我想删除节点 D，只需要将节点 D 的哈希槽移动到其他节点，当节点是空时，便可完全将它从集群中移除。

它**对节点的要求也是比较多的，一般是采用6个节点，三主三从。当节点超过10个，它的协调性就不那么灵活了，所以单集群的存储和性能上限也很快能到达。**

**集群模式的一些缺点很隐蔽。它的服务端节点倒是非常稳定了，但有些命令会严重影响性能。比如`mget`,`pipeline`等。它们需要把请求分散到多个节点执行、再聚合。节点越多，性能越低。**

简单的理解就是：扩容或缩容以后，槽需要重新分配，数据也需要重新迁移，但是服务不需要下线。

假如，这里有 3 个节点的集群环境如下：

*  节点 A 哈希槽范围为 0 ~ 5500；
 *  节点 B 哈希槽范围为 5501 ~ 11000；
 *  节点 C 哈希槽范围为 11001 ~ 16383。

此时，我们如果要存储数据，按照 Redis Cluster 哈希槽的算法，假设结果是： CRC16(key) % 16384 = 6782。 那么就会把这个 key 的存储分配到 B 节点。此时连接 A、B、C 任何一个节点获取 key，都会这样计算，最终通过 B 节点获取数据。

假如这时我们新增一个节点 D，Redis Cluster 会从各个节点中拿取一部分 Slot 到 D 上，比如会变成这样：

*  节点 A 哈希槽范围为 1266 ~ 5500；
 *  节点 B 哈希槽范围为 6827 ~ 11000；
 *  节点 C 哈希槽范围为 12288 ~ 16383；
 *  节点 D 哈希槽范围为 0 ~ 1265，5501 ~ 6826，11001 ~ 12287

### 主从模式 ###

Redis Cluster 为了保证数据的高可用性，加入了主从模式，**一个主节点对应一个或多个从节点**，主节点提供数据存取，从节点复制主节点数据备份，当这个主节点挂掉后，就会通过这个主节点的从节点选取一个来充当主节点，从而保证集群的高可用。

回到刚才的例子中，集群有 A、B、C 三个主节点，如果这 3 个节点都没有对应的从节点，如果 B 挂掉了，则集群将无法继续，因为我们不再有办法为 5501 ~ 11000 范围内的哈希槽提供服务。

所以我们在创建集群的时候，一定要为每个主节点都添加对应的从节点。比如，集群包含主节点 A、B、C，以及从节点 A1、B1、C1，那么即使 B 挂掉系统也可以继续正确工作。

因为 B1 节点属于 B 节点的子节点，所以 Redis 集群将会选择 B1 节点作为新的主节点，集群将会继续正确地提供服务。当 B 重新开启后，它就会变成 B1 的从节点。但是请注意，如果节点 B 和 B1 同时挂掉，Redis Cluster 就无法继续正确地提供服务了。

### 优点 ###

*  无中心架构；
 *  可扩展性，数据按照 Slot 存储分布在多个节点，节点间数据共享，节点可动态添加或删除，可动态调整数据分布；
 *  高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本。
 *  实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升。

### 缺点 ###

*  数据通过异步复制，无法保证**数据强一致性**；
 *  集群环境搭建复杂，不过基于 Docker 的搭建方案会相对简单。

## 其他方案 ##

可以看到redis的这些集群模式，都不是完美的。应对小型的服务可能没有问题，如果是大型的集群和服务，这些部署方式对运维上，使用上来说，都有非常大的挑战。

**使用客户端hash的方法**，是大型互联网中常用的方式。参考下面的文章，现实中的路由规则，可能会相当复杂，但请求总能够精确的落在某个小的群组上面。

[现实中的路由规则，可能比你想象中复杂的多][Link 1]

对于管理大型集群来说，我倒是倾向于主从模式，然后使用Java或者其他语言开发一个可以集中管控的哨兵系统，对上千个集群进行管理。

由于Redis是文本协议，协议非常简单，Netty甚至直接内置了它的解析器，所以开发这么一个哨兵系统是非常简单的。

一些中间层代理软件，也能分担一些路由工作，但由于是中间层，涉及到一层网络转发，对Redis这种以速度取胜的服务来说，就不是很实用。

变种有更多，比如下面这篇文章，使用的是Redis协议，但后端存储却是MySQL，所以你的命令会是被阉割的。

[架构秘笈：移花接木。使用mysql模拟redis][mysql_redis]

从上面的描述中我们就可以看出，Redis能用是一回事，用好是另一回事。

你可能花了一天时间搭建了一个单节点的Redis；我可能花了一周时间写了个Java版的哨兵，还有很多BUG。这两者在不懂技术的领导眼里，是没有区别的--它们都满足了业务的需求。但也不必过分计较，现实一般都比较残酷，计算机系统也没有想象中的那么稳定，墨菲定律总有一个时间会教会他们做人。

# Redis规范详解 #

redis功能强大，数据类型丰富，再快的系统，也经不住疯狂的滥用。通过禁用部分高风险功能，并挂上开发的枷锁，业务更能够以简洁、通用的思想去考虑问题，而不是绑定在某种实现上。

> Redis 根据不同的用途，会有不同的持久化策略和逐出策略，所以，在使用和申请 Redis 集群前，请明确是用来做缓存还是存储。redis 的集群有主从和 cluster 两种模式，各有优缺点。以下规范不区分集群模式，我们分别从使用场景和操作限制两方面说明。

## 使用规范 ##

### 冷热数据区分 ###

虽然 Redis支持持久化，但将所有数据存储在 Redis 中，成本非常昂贵。**建议将热数据 (如 QPS超过 5k) 的数据加载到 Redis 中。**低频数据可存储在 Mysql、 ElasticSearch中。

### **业务数据分离** ###

不要将不相关的数据业务都放到一个 Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。

### 消息大小限制 ###

由于 Redis 是单线程服务，消息过大会阻塞并拖慢其他操作。**保持消息内容在 1KB 以下是个好的习惯。严禁超过 50KB 的单条记录。**消息过大还会引起网络带宽的高占用，持久化到磁盘时的 IO 问题。

### 连接数限制 ###

连接的频繁创建和销毁，会浪费大量的系统资源，极限情况会造成宿主机当机。请确保使用了正确的 Redis 客户端连接池配置。

### 缓存 Key 设置失效时间 ###

作为缓存使用的 Key，必须要设置失效时间。失效时间并不是越长越好，请根据业务性质进行设置。注意，失效时间的单位有的是秒，有的是毫秒，这个很多同学不注意容易搞错。

### 缓存不能有中间态 ###

缓存应该仅作缓存用，去掉后业务逻辑不应发生改变，万不可切入到业务里。第一，缓存的高可用会影响业务；第二，产生深耦合会发生无法预料的效果；第三，会对维护行产生肤效果。

### **扩展方式首选客户端 hash** ###

**      如单 redis 集群并不能为你的数据服务，不要着急扩大你的 redis 集群（包括 M/S 和 Cluster)，集群越大，在状态同步和持久化方面的性能越差。 优先使用客户端 hash 进行集群拆分。如：根据用户 id 分 10 个集群，用户尾号为 0 的落在第一个集群**。

## 操作限制 ##

### 严禁使用 Keys ###

Keys 命令效率极低，属于 O(N)操作，会阻塞其他正常命令，在 cluster 上，会是灾难性的操作。严禁使用，DBA 应该 rename 此命令，从根源禁用。

### 严禁使用 Flush ###

flush 命令会清空所有数据，属于高危操作。严禁使用，DBA 应该 rename 此命令，从根源禁用，仅 DBA 可操作。

### 严禁作为消息队列使用 ###

如没有非常特殊的需求，严禁将 Redis 当作消息队列使用。Redis 当作消息队列使用，会有容量、网络、效率、功能方面的多种问题。如需要消息队列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ。

### 严禁不设置范围的批量操作 ###

redis 那么快，慢查询除了网络延迟，就属于这些批量操作函数。大多数线上问题都是由于这些函数引起。

1、\[zset\] 严禁对 zset 的不设范围操作

ZRANGE、 ZRANGEBYSCORE等多个操作 ZSET 的函数，严禁使用 ZRANGE myzset 0 -1 等这种不设置范围的操作。请指定范围，如 ZRANGE myzset 0 100。如不确定长度，可使用 ZCARD 判断长度

2、\[hash\] 严禁对大数据量 Key 使用 HGETALL

HGETALL会取出相关 HASH 的所有数据，如果数据条数过大，同样会引起阻塞，请确保业务可控。如不确定长度，可使用 HLEN 先判断长度

3、\[key\] Redis Cluster 集群的 mget 操作

Redis Cluster 的 MGET 操作，会到各分片取数据聚合，相比传统的 M/S架构，性能会下降很多，请提前压测和评估

4、\[其他\] 严禁使用 sunion, sinter, sdiff等一些聚合操作

### 禁用 select 函数 ###

select函数用来切换 database，对于使用方来说，这是很容易发生问题的地方，cluster 模式也不支持多个 database，且没有任何收益，禁用。

### 禁用事务 ###

redis 本身已经很快了，如无大的必要，建议捕获异常进行回滚，不要使用事务函数，很少有人这么干。

### 禁用 lua 脚本扩展 ###

lua 脚本虽然能做很多看起来很 cool 的事情，但它就像是 SQL 的存储过程，会引入性能和一些难以维护的问题，禁用。

### 禁止长时间 monitor ###

monitor函数可以快速看到当前 redis 正在执行的数据流，但是当心，高峰期长时间阻塞在 monitor 命令上，会严重影响 redis 的性能。此命令不禁止使用，但使用一定要特别特别注意。

## Key 规范 ##

Redis 的 Key 一定要规范，这样在遇到问题时，能够进行方便的定位。Redis 属于无 scheme 的 KV 数据库，所以，我们靠约定来建立其 scheme 语义。其好处：

1、能够根据某类 key 进行数据清理

2、能够根据某类 key 进行数据更新

3、能够方面了解到某类 key 的归属方和应用场景

4、为统一化、平台化做准备，减少技术变更

一般，一个 key 需要带以下维度：业务、key 用途、变量等，各个维度使用 : 进行分隔，以下是几个 key 的实例:

> user:sex 用户 10002232 的性别  
> msg:achi 201712 的用户发言数量排行榜

## 总结 ##

随着互联网的飞速发展，我们享受着技术带来的便利，同时也给从业者带来了如何保证项目高并发、低延时的技术挑战。Redis 以其超高的性能，简洁轻量的设计，易上手，分布式架构的支持，在缓存等领域出色的表现等，得到了业界广泛的关注和应用，在当今高性能架构中，也发挥着越来越重要的作用。甚至可以说，Redis 已经成为 IT 互联网大型系统的标配，熟练掌握 Redis 成为开发、运维人员的必备技能。

如果不深挖底层，仅仅只是从使用的角度出发，Redis 的学习成本将会非常低。如果作为一个很好的中间件去研究的话，还是有很多值得学习和借鉴的地方。以上几种模式，每种都有各自的优缺点，在实际场景中要根据业务特点去选择合适的模式使用。

# 参考： #

[https://juejin.im/post/6868426752789020685][https_juejin.im_post_6868426752789020685]

[https://mp.weixin.qq.com/s?\_\_biz=MzA4MTc4NTUxNQ==&mid=2650519808&idx=1&sn=78d404047311bdc83a3a9f650e045f06&chksm=8780bec4b0f737d29ac59abcb3aef6224ffd2769bd7fbd875ff8c1d01755bfe4ea6ca2df5461&scene=21\#wechat\_redirect][https_mp.weixin.qq.com_s_biz_MzA4MTc4NTUxNQ_mid_2650519808_idx_1_sn_78d404047311bdc83a3a9f650e045f06_chksm_8780bec4b0f737d29ac59abcb3aef6224ffd2769bd7fbd875ff8c1d01755bfe4ea6ca2df5461_scene_21_wechat_redirect]

[format_png]: /images/20221123/a04eb02cb1774f15ad401c71197743e5.png
[format_png 1]: /images/20221123/eb0760be90ff42678c52b536f278ccb0.png
[format_png 2]: /images/20221123/e73380fb62c44aefb00954bb0d68bcf3.png
[format_png 3]: /images/20221123/de01a59391a04452833a103e0059b1a2.png
[format_png 4]: /images/20221123/a2c7aacb6320421889fc7764cbb271cc.png
[format_png 5]: /images/20221123/4248c12784c346a2941cbf73ebeb8aa6.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ==&mid=2650519490&idx=1&sn=ce157a5d2da87b5956110ac2a4409bb6&scene=21#wechat_redirect
[mysql_redis]: http://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ==&mid=2650520298&idx=1&sn=7a34db9899c90713346e430d284be3a0&chksm=8780bd2eb0f73438f6a2ae40abba467f5683f0a225f0c1022d728e5c913b84c0dc7b6ceb95c3&scene=21#wechat_redirect
[https_juejin.im_post_6868426752789020685]: https://juejin.im/post/6868426752789020685
[https_mp.weixin.qq.com_s_biz_MzA4MTc4NTUxNQ_mid_2650519808_idx_1_sn_78d404047311bdc83a3a9f650e045f06_chksm_8780bec4b0f737d29ac59abcb3aef6224ffd2769bd7fbd875ff8c1d01755bfe4ea6ca2df5461_scene_21_wechat_redirect]: https://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ==&mid=2650519808&idx=1&sn=78d404047311bdc83a3a9f650e045f06&chksm=8780bec4b0f737d29ac59abcb3aef6224ffd2769bd7fbd875ff8c1d01755bfe4ea6ca2df5461&scene=21#wechat_redirect