Kafka

标签：消费者队列分区 Kafka 消息 leader

Kafka的简介

Kafka是一种消息队列，主要用来处理大量数据状态下的消息队列，一般用来做日志的处理。既然是消息队列，那么Kafka也拥有消息队列的相应的特性。

什么是消息队列

从本质上说消息队列就是一个队列结构的中间件，也就是说消息放入这个中间件之后就可以直接返回，并不需要系统立即处理，而另外会有一个程序读取这些数据，并按顺序进行逐次处理。

也就是说当你遇到一个并发特别大并且耗时特别长同时还不需要立即返回处理结果，使用消息队列可以解决这类问题。

消息队列主要解决了应用耦合、异步处理、流量削锋等问题。

数据冗余：比如订单系统，后续需要严格的进行数据转换和记录，消息队列可以把这些数据持久化的存储在队列中，然后有订单后，后续处理程序进行订单获取，后续处理完之后在把这条记录进行删除来保证每一条记录都能够处理完成。
系统解耦：使用消息系统之后，入队系统和出队系统是分开的，也就说只要一天崩溃了，不会影响另外一台系统正常运转。
流量削峰：例如秒杀和抢购，我们可以配合缓存来使用消息队列，能够有效的顶住瞬间访问量，防止服务器承受不住导致崩溃。
异步通信：消息本身使用入队之后可以直接返回。
扩展性：例如订单队列，不仅可以处理订单，还可以给其他业务使用。
排序保证：有些场景需要按照产品的顺序进行处理比如单进单出从而保证数据按照一定的顺序处理，使用消息队列是可以的。
消息通讯：消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用作消息通讯。比如实现点对点消息队列，或者聊天室等。

消息队列的两种消息模式，点对点模式，和发布订阅模式

队列模型

最初的消息队列，就是一个严格意义上的队列。在计算机领域，“队列（Queue）”是一种数据结构，有完整而严格的定义。在维基百科中，队列的定义是这样的：队列是先进先出（FIFO, First-In-First-Out）的线性表（Linear List）。在具体应用中通常用链表或者数组来实现。队列只允许在后端（称为 rear）进行插入操作，在前端（称为 front）进行删除操作。

先进先出，这里面隐含着的一个要求是，在消息入队出队过程中，需要保证这些消息严格有序，按照什么顺序写进队列，必须按照同样的顺序从队列中读出来。不过，队列是没有“读”这个操作的，“读”就是出队，也就是从队列中“删除”这条消息。

早期的消息队列，就是按照“队列”的数据结构来设计的。我们一起看下这个图，生产者（Producer）发消息就是入队操作，消费者（Consumer）收消息就是出队也就是删除操作，服务端存放消息的容器自然就称为“队列”。这就是最初的一种消息模型：队列模型。

如果有多个生产者往同一个队列里面发送消息，这个队列中可以消费到的消息，就是这些生产者生产的所有消息的合集。消息的顺序就是这些生产者发送消息的自然顺序。如果有多个消费者接收同一个队列的消息，这些消费者之间实际上是竞争的关系，每个消费者只能收到队列中的一部分消息，也就是说任何一条消息只能被其中的一个消费者收到。

如果需要将一份消息数据分发给多个消费者，要求每个消费者都能收到全量的消息，例如，对于一份订单数据，风控系统、分析系统、支付系统等都需要接收消息。这个时候，单个队列就满足不了需求，一个可行的解决方式是，为每个消费者创建一个单独的队列，让生产者发送多份。（同样的一份消息数据被复制到多个队列中会浪费资源，更重要的是，生产者必须知道有多少个消费者。为每个消费者单独发送一份消息，耦合性高）

发布订阅模型

在发布 - 订阅模型中，消息的发送方称为发布者（Publisher），消息的接收方称为订阅者（Subscriber），服务端存放消息的容器称为主题（Topic）。发布者将消息发送到主题中，订阅者在接收消息之前需要先“订阅主题”。“订阅”在这里既是一个动作，同时还可以认为是主题在消费时的一个逻辑副本，每份订阅中，订阅者都可以接收到主题的所有消息。

和队列模型最大的区别其实就是，一份消息数据能不能被消费多次。如果只有一个订阅者，那它和队列模型就基本是一样的了

Kafka的基础架构

Producer：消息生产者，向Kafka中发布消息的角色。
Consumer：消息消费者，即从Kafka中拉取消息消费的客户端。
Consumer Group：消费者组，消费者组则是一组中存在多个消费者，消费者消费Broker中当前Topic的不同分区中的消息，消费者组之间互不影响，所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。某一个分区中的消息只能够一个消费者组中的一个消费者所消费
Broker：经纪人，一台Kafka服务器就是一个Broker，一个集群由多个Broker组成，一个Broker可以容纳多个Topic。
Topic：主题，可以理解为一个队列，生产者和消费者都是面向一个Topic
Partition：分区，为了实现扩展性，一个非常大的Topic可以分布到多个Broker上，一个Topic可以分为多个Partition，每个Partition是一个有序的队列(分区有序，不能保证全局有序)
Replica：副本Replication，为保证集群中某个节点发生故障，节点上的Partition数据不丢失，Kafka可以正常的工作，Kafka提供了副本机制，一个Topic的每个分区有若干个副本，一个Leader和多个Follower
Leader：每个分区多个副本的主角色，生产者发送数据的对象，以及消费者消费数据的对象都是Leader。
Follower：每个分区多个副本的从角色，实时的从Leader中同步数据，保持和Leader数据的同步，Leader发生故障的时候，某个Follower会成为新的Leader。

简单可以理解为：在 Kafka 中，特定的一组数据被组织成 Topic。每个 Topic 可以划分为多个 Partition，Partition 是数据的基本存储单元。每个 Partition 可以在多个 Kafka 的 Broker 中创建 Replica。其中，一个 Replica 被指定为 Leader，其余的副本则是 Follower。 Leader 负责处理来自生产者和消费者的读写请求，所有的写入和读取操作都通过 Leader 进行。Follower 则会复制 Leader 的数据，并保持与 Leader 数据的同步。

Kafka的安装

Kafka的一些基本概念

Broker

一个Kafka集群通常有多个Broker组成，这样才能实现负载均衡，以及容错

Broker是无状态的，他们是通过ZooKeeper来维护集群状态

一个Kafka的Broker每秒可以除了数十万次的读写，每个Broker都可以处理消息而不影响性能

ZooKeeper

ZK用来管理和协调Broker，并且存储了Kafka的元数据（例如：有多少topic、partition、consumer）

ZK服务主要用于通知生产者和消费者Kafka集群中有新的Broker加入、或者Kafka集群中出现故障的Broker。

主题（Topic）

主题是一个逻辑概念，用于生产者发布数据，消费者拉取数据

一个Kafka集群中，可以包含多个topic。一个topic可以包含多个分区

Kafka中的主题必须要有标识符，而且是唯一的，Kafka中可以有任意数量的主题，没有数量上的限制

在主题中的消息是有结构的，一般一个主题包含某一类消息

一旦生产者发送消息到主题中，这些消息就不能被更新（更改）

分区（Partitions）

在Kafka集群中，主题被分为多个分区

Kafka集群的分布式就是由分区来实现的。一个topic中的消息可以分布在同一个topic里的不同partition上

副本（Replicas）

实现Kafkaf集群的容错，实现partition的容错。一个topic至少应该包含大于1个的副本

副本可以确保某个服务器出现故障时，确保数据依然可用

在Kafka中，一般都会设计副本的个数＞1

偏移量（offset）

offset记录着下一条将要发送给consumer的消息的序号

默认kafka将offset储存在ZooKeeper中

在一个分区中，消息是有顺序的方式储存着的，每个在分区的消费都是由一个递增的id，这个就是偏移量offset

偏移量在分区中才是有意义的。在分区之间，offset是没有任何意义的

消费者组

一个消费者组中可以包含多个消费者，共同来消费topic中的数据

一个topic中如果只有一个分区，那么这个分区只能被某个组中的一个消费者消费

有多少个分区，那么就可以被同一个组内的多少个消费者消费

Kafka的幂等性

幂等性：幂等性是一个在计算机科学和数学中广泛应用的概念，用于描述一个操作或函数的多次执行对结果产生的影响只有一次执行的效果，即多次执行不会改变最终的状态。

如果，某个系统是不具备幂等性的，如果用户重复提交了某个表格，就可能会造成不良影响。例如：用户在浏览器上点击了多次提交订单按钮，会在后台生成多个一模一样的订单。

Kafka生产者的幂等性

在生产者生产消息时，如果出现retry时，有可能会一条消息被发送了多次，如果Kafka不具备幂等性的，就有可能会在partition中保存多条一模一样的消息。

生产者消息重复问题

Kafka生产者生产消息到partition，如果直接发送消息，kafka会将消息保存到分区中，但Kafka会返回一个ack给生产者，表示当前操作是否成功，是否已经保存了这条消息。

如果ack响应的过程失败了，此时生产者会重试，继续发送没有发送成功的消息，Kafka又会保存一条一模一样的消息

配置幂等性

enable.idempotence: true

原理

为了实现生产者的幂等性，Kafka引入了 Producer ID（PID）和 Sequence Number的概念。

PID：每个Producer在初始化时，都会分配一个唯一的PID，这个PID对用户来说，是透明的。
Sequence Number：针对每个生产者（对应PID）发送到指定主题分区的消息都对应一个从0开始递增的Sequence Number。
当Kafka的生产者生产消息时，会增加一个pid（生产者的唯一编号）和sequence number（针对消息的一个递增序列）
发送消息，会带着pid和sequence number一块发送
kafka接收到消息，会将消息和pid、sequence number一并保存下来
如果ack响应失败，生产者重试，再次发送消息时，Kafka会根据pid、sequence number是否需要再保存一条消息
判断条件：生产者发送过来的sequence number 是否小于等于 partition中消息对应的sequence

事务

kafka从0.11版本开始引入了事务支持，事务可以保证Kafka在Exactly Once语义的基础上，生产和消费可以跨分区的会话，要么全部成功，要么全部失败。

Producer事务

为了按跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID，并将Producer获得的PID(可以理解为Producer ID)和Transaction ID进行绑定，这样当Producer重启之后就可以通过正在进行的Transaction ID获得原来的PID。

为了管理Transaction，Kafka引入了一个新的组件Transaction Coordinator，Producer就是通过有和Transaction Coordinator交互获得Transaction ID对应的任务状态，Transaction Coordinator还负责将事务信息写入内部的一个Topic中，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以恢复，从而继续进行。

Consumer事务

对于Consumer而言，事务的保证相比Producer相对较弱，尤其是无法保证Commit的信息被精确消费，这是由于Consumer可以通过offset访问任意信息，而且不同的Segment File声明周期不同，同一事务的消息可能会出现重启后被删除的情况。

分区和副本机制

生产者分区写入策略

生产者写入消息到topic，Kafka将依据不同的策略将数据分配到不同的分区中

轮询分区策略
随机分区策略
按key分区分配策略
自定义分区策略

轮询策略

默认的策略，也是使用最多的策略，可以最大限度保证所有消息平均分配到一个分区

如果在生产消息时，key为null，则使用轮询算法均衡地分配分区

随机策略

随机策略，每次都随机地将消息分配到每个分区。在较早的版本，默认的分区策略就是随机策略，也是为了将消息均衡地写入到每个分区。但后续轮询策略表现更佳，所以基本上很少会使用随机策略。

按key分配策略

按key分配策略，有时候会出现数据倾斜，例如：某个key包含了大量的数据，因为key值一样，所有的数据将都分配到一个分区，造成该分区的消息数量远大于其他的分区

自定义分区策略

创建自定义分区器

public class KeyWithRandomPartitioner implements Partitioner {

	private Random r;

	@Override
	public void configure(Map<String, ?> configs) {
    	r = new Random();
	}

	@Override
	public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
    	// cluster.partitionCountForTopic 表示获取指定topic的分区数量
    	return r.nextInt(1000) % cluster.partitionCountForTopic(topic);
	}

	@Override
	public void close() {
	}
}

在Kafka生产者配置中，自定使用自定义分区器的类名
props.put(ProducerConfig.PARTITIONER_CLASS_CONFIG,KeyWithRandomPartitioner.class.getName());

乱序问题

轮询策略、随机策略都会导致一个问题，生产到Kafka中的数据是乱序存储的。而按key分区可以一定程度上实现数据有序存储——也就是局部有序，但这又可能会导致数据倾斜，所以在实际生产环境中要结合实际情况来做取舍。

kafka中的消息是全局乱序的，局部partition有序的，如果要实现消息总是有序的，可以将连续的消息放到一个partition，但是kafka就失去了分布式的意义

消费者组Rebalance机制

Kafka中的Rebalance称之为再均衡，是Kafka中确保Consumer group下所有的consumer如何达成一致，分配订阅的topic的每个分区的机制。

Rebalance触发的时机有：

消费者组中consumer的个数发生变化。例如：有新的consumer加入到消费者组，或者是某个consumer停止了。
订阅的topic个数发生变化
- 消费者可以订阅多个主题，假设当前的消费者组订阅了三个主题，但有一个主题突然被删除了，此时也需要发生再均衡。
订阅的topic分区数发生变化

Rebalance的不良影响

发生Rebalance时，consumer group下的所有consumer都会协调在一起共同参与，Kafka使用分配策略尽可能达到最公平的分配

Rebalance过程会对consumer group产生非常严重的影响，Rebalance的过程中所有的消费者都将停止工作，直到Rebalance完成

消费者分区分配策略

保障每个消费者尽量能够均衡地消费分区的数据，不能出现某个消费者消费分区的数量特别多，某个消费者消费的分区特别少

Range范围分配策略

Range范围分配策略是Kafka默认的分配策略，它可以确保每个消费者消费的分区数量是均衡的。

注意：Rangle范围分配策略是针对每个Topic的。

算法公式：

n = 分区数量 / 消费者数量
m = 分区数量 % 消费者数量
前m个消费者消费n+ 1个，剩余的消费n个

RoundRobin轮询策略

RoundRobinAssignor轮询策略是将消费组内所有消费者以及消费者所订阅的所有topic的partition按照字典序排序（topic和分区的hashcode进行排序），然后通过轮询方式逐个将分区以此分配给每个消费者。

Stricky粘性分配策略

目的：

分区分配尽可能均匀
在发生rebalance的时候，分区的分配尽可能与上一次保持相同
在没发生rebalance时，和轮询差不多

stricky粘性分配策略，保留rebalance之前的分配结果。只将原本consumer2负责的两个分区在均匀分配给consumer0，consumer1，这样可以明显减少系统资源的浪费

副本机制

副本的目的就是冗余备份，当某个Broker上的分区数据丢失时，依然可以保障数据可用。因为在其他的Broker上的副本是可用的。

producer的acks参数

对副本关系较大的就是，producer配置的acks参数了,acks参数表示当生产者生产消息的时候，写入到副本的要求严格程度。它决定了生产者如何在性能和可靠性之间做取舍。

注意：acks参数配置的是一个字符串类型，而不是整数类型，如果配置为整数类型会抛出异常

acks配置为0：

生产者只管写入，不管是否写入成功，可能会数据丢失。性能是最好的

生产者在成功写入消息之前不会等待任何来自服务器的相应。如果出现问题生产者是感知不到的，消息就丢失了。不过因为生产者不需要等待服务器响应，所以它可以以网络能够支持的最大速度发送消息，从而达到很高的吞吐量。

acks配置为1：

当生产者的ACK配置为1时，生产者会等待leader副本确认接收后，才会发送下一条数据，性能中等。
默认值为1，只要集群的首领节点收到消息，生产这就会收到一个来自服务器的成功响应。如果消息无法达到首领节点（比如首领节点崩溃，新的首领还没有被选举出来），生产者会收到一个错误响应，为了避免数据丢失，生产者会重发消息。但是，这样还有可能会导致数据丢失，如果收到写成功通知，此时首领节点还没来的及同步数据到follower节点，首领节点崩溃，就会导致数据丢失。

acks配置为-1或者all：

确保消息写入到leader分区、还确保消息写入到对应副本都成功后，接着发送下一条，性能是最差的

只有当所有参与复制的节点都收到消息时，生产这会收到一个来自服务器的成功响应，这种模式是最安全的，它可以保证不止一个服务器收到消息。

根据业务情况来选择ack机制，是要求性能最高，一部分数据丢失影响不大，可以选择0/1。如果要求数据一定不能丢失，就得配置为-1/all。

Kafka原理

Kafka的leader和follower

在Kafka中，每个topic都可以配置多个分区以及多个副本。每个分区都有一个leader以及0个或者多个follower，在创建topic时，Kafka会将每个分区的leader均匀地分配在每个broker上。我们正常使用kafka是感觉不到leader、follower的存在的。但其实，所有的读写操作都是由leader处理，而所有的follower都复制leader的日志数据文件，如果leader出现故障时，follower就会被选举为leader。所以：

Kafka中的leader负责处理读写操作，而follower只负责副本数据的同步
如果leader出现故障，其他follower会被重新选举为leader
follower像一个consumer一样，拉取leader对应分区的数据，并保存到日志数据文件中
Kafka中的leader和follower是相对分区有意义，不是相对broker
Kafka在创建topic的时候，会尽量分配分区的leader在不同的broker中，其实就是负载均衡
leader职责：读写数据
follower职责：同步数据、参与选举（leader crash之后，会选举一个follower重新成为分区的leader

AR、ISR、OSR

AR（Assigned Replica）： AR是每个分区的副本集合，包括leader和follower
ISR(In-Sync Replica) ： ISR表示与领导者副本保持同步的副本集合。
OSR（Out-of-Sync Replica) ： OSR 表示与领导者副本不同步的副本集合。这些副本可能由于网络问题等原因，暂时无法与领导者保持同步。

AR = ISR + OSR

正常情况下，所有的follower副本都应该与leader副本保持同步，即AR = ISR，OSR集合为空。

leader的选举

Controller

控制器组件（Controller），是 Apache Kafka 的核心组件。它的主要作用是在 Apache ZooKeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一台 Broker 都能充当控制器的角色，但是，在运行过程中，只能有一个 Broker 成为控制器，行使其管理和协调的职责。

什么是Controller Broker

在分布式系统中，通常需要有一个协调者，该协调者会在分布式系统发生异常时发挥特殊的作用。在Kafka中该协调者称之为控制器(Controller),其实该控制器并没有什么特殊之处，它本身也是一个普通的Broker，只不过需要负责一些额外的工作(追踪集群中的其他Broker，并在合适的时候处理新加入的和失败的Broker节点、Rebalance分区、分配新的leader分区等)。值得注意的是：Kafka集群中始终只有一个Controller Broker。

Controller是怎么选举的

在Kafka集群启动的时候，每个broker都会尝试去ZooKeeper上注册成为Controller（ZK临时节点）
但只有一个竞争成功，其他的broker会注册该节点的监视器
一点该临时节点状态发生变化，就可以进行相应的处理
Controller也是高可用的，一旦某个broker崩溃，其他的broker会重新注册为Controller

Controller选举partition leader

所有Partition的leader选举都由controller决定
controller会将leader的改变直接通过RPC（远程过程调用协议）的方式通知需为此作出响应的Broker
controller读取到当前分区的ISR，只要有一个Replica还幸存，就选择其中一个作为leader否则，则任意选这个一个Replica作为leader
如果该partition的所有Replica都已经宕机，则新的leader为-1

Preferred Replica

Kafka中引入了一个叫做「preferred-replica」的概念，意思就是：优先的Replica

在ISR列表中，第一个replica就是preferred-replica

第一个分区存放的broker，肯定就是preferred-replica

Kafka生产、消费数据工作流程

Kafka生成数据工作流程

Kafka消费数据工作流程

两种消费模式

kafka采用拉取模型，由消费者自己记录消费状态，每个消费者互相独立地顺序拉取每个分区的消息

消费者可以按照任意的顺序消费消息。比如，消费者可以重置到旧的偏移量，重新处理之前已经消费过的消息；或者直接跳到最近的位置，从当前的时刻开始消费。

Kafka消费数据流程

Kafka的数据存储形式

一个topic由多个分区组成
一个分区（partition）由多个segment（段）组成
一个segment（段）由多个文件组成（log、index、timeindex）

存储日志

消息是保存在以：「主题名-分区ID」的文件夹中的

数据文件夹中包含以下内容：

文件名	说明
.index	索引文件，根据offset查找数据就是通过该索引文件来操作的
.log	日志数据文件
.timeindex	时间索引
leader-epoch-checkpoint	持久化每个partition leader对应的LEO（log end offset、日志文件中下一条待写入消息的offset）

每个日志文件的文件名为起始偏移量，因为每个分区的起始偏移量是0，所以，分区的日志文件都以0000000000000000000.log开始
默认的每个日志文件最大为「log.segment.bytes =102410241024」1G
为了简化根据offset查找消息，Kafka日志文件名设计为开始的偏移量

写入消息

新的消息总是写入到最后的一个日志文件中

该文件如果到达指定的大小（默认为：1GB）时，将滚动到一个新的文件中

读取消息

根据「offset」首先需要找到存储数据的 segment 段（注意：offset指定分区的全局偏移量）
然后根据这个「全局分区offset」找到相对于文件的「segment段offset」
最后再根据「segment段offset」读取消息
为了提高查询效率，每个文件都会维护对应的范围内存，查找的时候就是使用简单的二分查找

删除消息

在Kafka中，消息是会被定期清理的。一次删除一个segment段的日志文件
Kafka的日志管理器，会根据Kafka的配置，来决定哪些文件可以被删除

数据不丢失

broker消息不丢失

生产者通过分区的leader写入数据后，所有在ISR中的follower都会从leader中复制数据，这样，可以确保即使leader崩溃了，其他的follower的数据仍然是可用的

生产者数据不丢失

生产者连接leader写入数据时，可以通过ACK机制来确保数据已经成功写入。ACK机制有三个可选配置

配置ACK响应要求为 -1 时 —— 表示所有的节点都收到数据(leader和follower都接收到数据）
配置ACK响应要求为 1 时 —— 表示leader收到数据
配置ACK影响要求为 0 时 —— 生产者只负责发送数据，不关心数据是否丢失（这种情况可能会产生数据丢失，但性能是最好的）

生产者可以采用同步和异步两种方式发送数据

同步：发送一批数据给kafka后，等待kafka返回结果
异步：发送一批数据给kafka，只是提供一个回调函数。

说明：如果broker迟迟不给ack，而buﬀer又满了，开发者可以设置是否直接清空buﬀer中的数据。

消费者数据不丢失

在消费者消费数据的时候，只要每个消费者记录好oﬀset值即可，就能保证数据不丢失。

下图是消费者消费消息丢失的情况：

可以使用Mysql等数据库对offset进行记录，保证offset在正确的位置

但是有可能会在写入数据库时出错，导致重复消费

可以使用事务进行解决

数据积压

Kafka消费者消费数据的速度是非常快的，但如果由于处理Kafka消息时，由于有一些外部IO、或者是产生网络拥堵，就会造成Kafka中的数据积压（或称为数据堆积）。如果数据一直积压，会导致数据出来的实时性受到较大影响。

消息的消费者的消费速度远赶不上生产者的生产消息的速度，导致kafka中有大量的数据没有被消费。随着没有被消费的数据堆积越多消费者寻址的性能会越来越差，最后导致整个kafka对外提供的服务的性能很差，从而造成其他服务也访问速度变慢，造成服务雪崩。

解决数据积压问题

在这个消费者中，使用多线程，充分利用机器的性能进行消费消息

通过业务的架构设计，提升业务层面消费的性能。

创建多个消费组，多个消费者，部署到其他机器上，一起消费，提高消费者的消费速度

创建一个消费者，该消费者在kafka另建一个主题，配上多个分区，多个分区再配上多个消费者。该消费者将pol下来的消息，不进行消费，直接转发到新建的主题上。此时，新的主题的多个分区的多个消费者就开始一起消费了。一一不常用

Kafka中数据清理（Log Deletion）

Kafka的消息存储在磁盘中，为了控制磁盘占用空间，Kafka需要不断地对过去的一些消息进行清理工作。Kafka的每个分区都有很多的日志文件，这样也是为了方便进行日志的清理。在Kafka中，提供两种日志清理方式：

日志删除（Log Deletion）：按照指定的策略直接删除不符合条件的日志。（以段为单位进行删除）
日志压缩（Log Compaction）：按照消息的key进行整合，有相同key的但有不同value值，只保留最后一个版本。

标签：消费者,队列,分区,Kafka,消息,leader
From： https://www.cnblogs.com/NorthnightX/p/17638340.html