Kafka是一个分布式数据流平台，可以运行在单台服务器上，也可以在多台服务器上部署形成集群。它提供了发布和订阅功能，使用者可以发送数据到Kafka中，也可以从Kafka中读取数据（以便进行后续的处理）。Kafka具有高吞吐、低延迟、高容错、可水平扩展、支持流数据处理等特点。

Kafka架构概念

Kafka作为一个高度可扩展可容错的消息系统，一个典型的kafka集群中包含若干producer，若干broker，若干consumer，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。producer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息：

下面是kafka的一些专业术语：

• Broker：消息中间件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。
• Topic：一类消息，Kafka集群能够同时负责多个topic的分发。
• Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。
• Replication：每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
• Segment：partition物理上由多个segment组成。
• offset：每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset，用于partition唯一标识一条消息。
• Producer：负责发布消息到Kafka broker。
• Consumer：消息消费者，向Kafka broker读取消息的客户端。
• Consumer Group：每个Consumer属于一个特定的Consumer Group。
• Leader：每个分区多个副本的“主”副本，生产者发送数据的对象，以及消费者消费数据的对象，都是 Leader。
• Follower：每个分区多个副本的“从”副本，实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个 Follower 还会成为新的 Leader。
• ZooKeeper：Kafka 集群能够正常工作，需要依赖于 ZooKeeper，ZooKeeper 帮助 Kafka 存储和管理集群信息。

Kafka实现了零拷贝原理来快速移动数据，避免了内核之间的切换。Kafka可以将数据记录分批发送，从生产者到文件系统（Kafka主题日志）到消费者，可以端到端的查看这些批次的数据。批处理能够进行更有效的数据压缩并减少I/O延迟，Kafka采取顺序写入磁盘的方式，避免了随机磁盘寻址的浪费，总结一下其实就是四个要点：

• 顺序读写：因为硬盘是机械结构，每次读写都会寻址，写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最“讨厌”随机I/O，最喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。
• 零拷贝：在Linux Kernal 2.2之后出现了一种叫做“零拷贝(zero-copy)”系统调用机制，就是跳过“用户缓冲区”的拷贝，建立一个磁盘空间和内存空间的直接映射，数据不再复制到“用户态缓冲区”系统上下文切换减少2次，可以提升一倍性能。
• 消息压缩：消息都是经过压缩传递、存储的，降低网络与磁盘的负担。
• 分批发送：批量处理是一种非常有效的提升系统吞吐量的方法，在Kafka内部，消息都是以“批”为单位处理的。

kafka topic的基本组成

在kafka中，消息都是以 topic 进行分类的，生产者和消费者都是面向topic的，在 kafka 中，一个 topic 可以分为多个 partition，一个 partition可以分为多个segment, 每个 segment 对应两个文件：.index 和 .log 文件；topic 是逻辑上的概念，而 patition 是物理上的概念，每个 patition 对应一个 log 文件，而 log 文件中存储的就是 producer 生产的数据，patition 生产的数据会被不断的添加到 log 文件的末端，且每条数据都有自己的 offset。消费组中的每个消费者，都是实时记录自己消费到哪个 offset，以便出错恢复，从上次的位置继续消费。

消息存储机制

由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了分片和索引机制，将每个 partition 分为多个 segment。每个 segment 对应两个文件——.index文件和 .log文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号。

如下，我们创建一个只有一个分区一个副本的 topic：

1

bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic dawn

然后可以在 kafka-logs 目录（server.properties 默认配置）下看到会有个名为 dawn-0 的文件夹。如果，starfish 这个 topic 有三个分区，则其对应的文件夹为 dawn-0，dawn-1，dawn-2。

这些文件的含义如下：

index 和 log 文件以当前 segment 的第一条消息的 offset 命名。偏移量 offset 是一个 64 位的长整形数，固定是20 位数字，长度未达到，用 0 进行填补，索引文件和日志文件都由此作为文件名命名规则。

从上图可以看出，我们的偏移量是从 0 开始的，.index 和 .log 文件名称都为 00000000000000000000。

在server.properties 文件中会配置日志文件的最大值，当生产者生产数据量较多，一个 segment 存储不下触发分片时，在日志 topic 目录下会看到类似如下所示的文件：

1
2
3
4
5
6

00000000000000000000.index 
00000000000000000000.log 
00000000000000170410.index 
00000000000000170410.log 
00000000000000239430.index 
00000000000000239430.log

Topic 副本机制

在Kafka中，Topic的同一个 partition 可能会有多个 replication( 对应 server.properties 配置中的 default.replication.factor=N)。

没有 replication 的情况下，一旦 broker 宕机，其上所有 patition 的数据都不可被消费，同时 producer 也不能再将数据存于其上的 patition。比如一个有 3 台 Broker 的 Kafka 集群上的副本分布情况。主题 1 分区 0 的 3 个副本分散在 3 台 Broker 上，其他主题分区的副本也都散落在不同的 Broker 上，从而实现数据冗余。

​ 引入 replication 之后，同一个 partition 可能会有多个 replication，而这时需要在这些 replication 之间选出一 个 leader， producer 和 consumer 只与这个 leader 交互，其它 replication 作为 follower 从 leader 中复制数据。

kafka Producer写入流程

producer 写入消息流程如下：

1. producer连接ZK集群，从 zookeeper 中拿到对应 topic 的 partition 信息和partition的Leader的相关信息
2. producer 连接leader 对应的broker, 并将消息发送给该 leader
3. leader 将消息写入本地 log
4. followers 从 leader pull 消息，写入本地 log 后向 leader 发送 ACK
5. leader 收到所有 ISR 中的 replication 的 ACK 后，增加 HW(high watermark，最后 commit 的 offset)并向 producer 发送 ACK

producer 采用推(push) 模式将消息发布到 broker，每条消息都被追加(append) 到分区(patition) 中，属于顺序写磁盘(顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率)。

分区策略

​ Kafka 的消息组织方式实际上是三级结构：主题 - 分区 - 消息。因此topic下的每条消息只会保存在某一个分区中，而不会在多个分区中被保存多份。分区提供了系统的负载均衡能力，能够实现系统的高伸缩性，不同的分区能够被放置到不同节点的机器上，而数据的读写操作也都是针对分区这个粒度而进行的，这样每个节点的机器都能独立地执行各自分区的读写请求处理。这样，当性能不足的时候可以通过添加新的节点机器来增加整体系统的吞吐量。

​ producer将消息发送到哪个分区又分区策略决定，kafka为我们提供了默认的分区策略，同时支持用户自定义分区策略，常见的分区策略有：

​ 1. 轮询策略：Round-robin 策略，即顺序分配到每个分区。该策略总是能保证消息最大限度地被平均分配到所有分区上，故默认情况下它是最合理的分区策略，也是最常用的分区策略之一。

2. 随机策略-Randomness 策略：随机就是随意地将消息放置到任意一个分区上。

3. 按消息键保序策略- Key ordering 策略：为每条消息定义消息键Key，相同 Key 的所有消息都进入到相同的分区里面。

数据分区投递的基本原则：

1. 如果指定的partition，那么直接进入该partition。
2. 如果没有指定partition，但是指定了key，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值
3. 如果既没有指定partition，也没有指定key，使用轮询策略选择partition。

批量发送

当生产者发送多个消息到同一个topic时，为了减少网络带来的开销，kafka会对消息进行批量发送；主要涉及3个参数如下，满足其一即会批量发送：

• batch-size ：超过收集的消息数量的最大量，默认16KB
• buffer-memory ：超过收集的消息占用的最大内存 , 默认32M
• linger.ms ：超过收集的时间的最大等待时长，单位：毫秒，默认为0ms, 即有消息就发送

数据可靠性保证

为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic 的每个 partition 收到 producer 数据后，都需要向 producer 发送 ack ( acknowledgement 确认收到)，如果 producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。

数据同步策略

Leader将消息写入到本地后，需要确保有 Follower 与 Leader 同步完成后才能发送 ACK，这样才能保证 Leader 挂掉之后，能在 Follower 中选举出新的 Leader 而不丢数据，Follower数据同步发送ACK主要有两种策略：

Kafka 选择了第二种方案，原因如下：

• 同样为了容忍 n 台节点的故障，第一种方案需要的副本数相对较多，而 Kafka 的每个分区都有大量的数据，第一种方案会造成大量的数据冗余;
• 虽然第二种方案的网络延迟会比较高，但网络延迟对 Kafka 的影响较小。

LSR

采用第二种方案之后，会出现一个问题：leader 收到数据，所有 follower 都开始同步数据，但此时有一个 follower 故障导致不能与 leader 保持同步，此时leader 得一直等下去，直到它完成同步，才能发送 ack，这会造成消息无法确定。

为了解决此问题，leader 维护了一个动态的 in-sync replica set(ISR)，意为和 leader 保持同步的 follower 集合。当 ISR 中的follower 完成数据的同步之后，leader 就会给 follower 发送 ack。如果 follower 长时间未向 leader 同步数据，则该 follower 将会被踢出 ISR，该时间阈值由 replica.lag.time.max.ms 参数设定。leader 发生故障之后，就会从 ISR 中选举新的 leader。

ack应答机制

对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等 ISR 中的follower全部接收成功。所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡

0：producer 不等待 broker 的 ack，这一操作提供了一个最低的延迟，broker 一接收到还没有写入磁盘就已经返回，当 broker 故障时有可能丢失数据;

1：producer 等待 broker 的 ack，partition 的 leader 落盘成功后返回 ack，如果在 follower 同步成功之前 leader 故障，那么将会丢失数据;

-1(all)：producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盘成功后才返回 ack。但是 如果在 follower 同步完成后，broker 发送 ack 之前，leader 发生故障，那么就会造成数据重复。

故障处理

​ 由于我们并不能保证 Kafka 集群中每时每刻 follower 的长度都和 leader 一致(即数据同步是有时延的)，那么当leader 挂掉选举某个 follower 为新的 leader 的时候(原先挂掉的 leader 恢复了成为了 follower)，可能会出现leader 的数据比 follower 还少的情况。为了解决这种数据量不一致带来的混乱情况，Kafka 提出了以下概念：

• LEO(Log End Offset)：指的是每个副本最后一个offset;
• HW(High Wather)：指的是消费者能见到的最大的 offset，ISR 队列中最小的 LEO。

消费者和 leader 通信时，只能消费 HW 之前的数据，HW 之后的数据对消费者不可见，因此：

• 当follower发生故障时：follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。等该 follower 的 LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。
• 当leader发生故障时：leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的数据一致性，其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader 同步数据。

所以数据一致性并不能保证数据不丢失或者不重复，这是由 ack 控制的。HW 规则只能保证副本之间的数据一致性!

Exactly Once

将服务器的 ACK 级别设置为 -1，可以保证 Producer 到 Server 之间不会丢失数据，即 At Least Once 语义。相对的，将服务器 ACK 级别设置为 0，可以保证生产者每条消息只会被发送一次，即 At Most Once语义。

At Least Once 可以保证数据不丢失，但是不能保证数据不重复。相对的，At Most Once 可以保证数据不重复，但是不能保证数据不丢失。但是，对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据既不重复也不丢失，即 Exactly Once 语义。在 0.11 版本以前的 Kafka，对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局去重。对于多个下游应用的情况，每个都需要单独做全局去重，这就对性能造成了很大的影响。

0.11 版本的 Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指 Producer 不论向 Server 发送多少次重复数据。Server 端都会只持久化一条，幂等性结合 At Least Once 语义，就构成了 Kafka 的 Exactily Once 语义，即：At Least Once + 幂等性 = Exactly Once

要启用幂等性，只需要将 Producer 的参数中 enable.idompotence 设置为 true 即可。Kafka 的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的 Producer 在初始化的时候会被分配一个 PID，发往同一 Partition 的消息会附带 Sequence Number。而 Broker 端会对Sequence Number做校验，如果发现PID对应的Sequence Number重复，就会丢弃此消息

但是 PID 重启就会变化，同时不同的 Partition 也具有不同主键，所以幂等性无法保证跨分区会话的 Exactly Once。

Kafka Consumer消费过程

Consumer 采用 Pull（拉取）模式从 Broker 中读取数据。Pull 模式则可以根据 Consumer 的消费能力以适当的速率消费消息。Pull 模式不足之处是，如果 Kafka没有数据，消费者可能会陷入循环中，一直返回空数据。

因为消费者从 Broker 主动拉取数据，需要维护一个长轮询，针对这一点， Kafka 的消费者在消费数据时会传入一个时长参数 timeout。如果当前没有数据可供消费，Consumer 会等待一段时间之后再返回，这段时长即为 timeout。

消费者组

消费者是以 consumer group 消费者组的方式工作，由一个或者多个消费者组成一个组， 共同消费一个 topic。每个分区在同一时间只能由 group 中的一个消费者读取，但是多个 group 可以同时消费这个 partition。

通过消费者组的模式，消费者可以通过水平扩展的方式同时读取大量的消息。另外，如果一个消费者失败了，那么其他的 group 成员会自动负载均衡读取之前失败的消费者读取的分区。

消费者组最为重要的一个功能是实现广播与单播的功能。一个消费者组可以确保其所订阅的 Topic 的每个分区只能被从属于该消费者组中的唯一一个消费者所消费；如果不同的消费者组订阅了同一个 Topic，那么这些消费者组之间是彼此独立的，不会受到相互的干扰。

如果我们希望一条消息可以被多个消费者所消费，那么可以将这些消费者放到不同的消费者组中，这实际上就是广播的效果；如果希望一条消息只能被一个消费者所消费，那么可以将这些消费者放到同一个消费者组中，这实际上就是单播的效果。

分区策略

一个 consumer group 中有多个 consumer，一个 topic 有多个 partition，所以必然会涉及到 partition 的分配问题，即确定哪个 partition 由哪个 consumer 来消费。

Kafka 有两种分配策略，一是 RoundRobin，一是 Range。

1. RoundRobin：RoundRobin 即轮询的意思，比如现在有一个三个消费者 ConsumerA、ConsumerB 和 ConsumerC 组成的消费者组，同时消费 TopicA 主题消息，TopicA 分为 7 个分区，如果采用 RoundRobin 分配策略，过程如下所示：

2. Range： Range 顾名思义就是按范围划分的意思，Kafka 默认采用 Range 分配策略，

比如现在有一个三个消费者 ConsumerA、ConsumerB 和 ConsumerC 组成的消费者组，同时消费 TopicA 主题消息，TopicA分为7个分区，如果采用 Range 分配策略，过程如下所示：

offset的维护

由于 consumer 在消费过程中可能会出现断电宕机等故障，consumer 恢复后，需要从故障前的位置继续消费，所以 consumer 需要实时记录自己消费到了哪个 offset，以便故障恢复后继续消费。

Kafka 0.9 版本之前，consumer 默认将 offset 保存在 Zookeeper 中，从 0.9 版本开始，consumer 默认将 offset保存在 Kafka 一个内置的 topic 中，该 topic 为 _consumer_offsets。

kafka事务

Kafka 事务基于幂等性实现，通过事务机制，Kafka 可以实现对多个 Topic 、多个 Partition 的原子性的写入，即处于同一个事务内的所有消息，最终结果是要么全部写成功，要么全部写失败。

Kafka 事务分为生产者事务和消费者事务，但它们并不是强绑定的关系，消费者主要依赖自身对事务进行控制，因此这里我们主要讨论的是生产者事务。

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

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

参考文档

• 一文讲清 Kafka 工作流程和存储机制 — 推荐阅读
• 一文理解Kafka的设计原理 — 推荐阅读
• Kafka 介紹 + Golang程序实现 — 简单看看
• kafka序列文章 — 简单看看

Apache Flink 诞生于柏林工业大学的一个研究性项目，原名 StratoSphere 。2014 年，由 StratoSphere 项目孵化出 Flink，并于同年捐赠 Apache，之后成为 Apache 的顶级项目。

Flink 是一个分布式的流处理框架，它能够对有界和无界的数据流进行高效的处理。Flink 的核心是流处理，当然它也能支持批处理，Flink 将批处理看成是流处理的一种特殊情况，即数据流是有明确界限的。

有界数据集：数据是静止不动的，例如mysql中的数据。对数据的处理不需要考虑追加写入的数据。在某个时间内的结果进行计算，这种计算称之为批计算，批处理。Batch Processing

无界数据集：数据会持续变更，例如实时日志数据。对于此类持续变更、追加的数据的计算方式称之为流计算。Streaming Processing

Flink架构

Flink组件

Flink 核心架构的第二层是 Runtime 层， 该层采用标准的 Master - Slave 结构， 其中，Master 部分又包含了三个核心组件：Dispatcher、ResourceManager 和 JobManager，而 Slave 则主要是 TaskManager 进程。它们的功能分别如下：

• JobManagers (也称为 masters) ：JobManagers 接收由 Dispatcher 传递过来的执行程序，该执行程序包含了作业图 (JobGraph)，逻辑数据流图 (logical dataflow graph) 及其所有的 classes 文件以及第三方类库 (libraries) 等等 。紧接着 JobManagers 会将 JobGraph 转换为执行图 (ExecutionGraph)，然后向 ResourceManager 申请资源来执行该任务，一旦申请到资源，就将执行图分发给对应的 TaskManagers 。因此每个作业 (Job) 至少有一个 JobManager；高可用部署下可以有多个 JobManagers，其中一个作为 leader*，其余的则处于 *standby 状态。
• TaskManagers (也称为 workers) : TaskManagers 负责实际的子任务 (subtasks) 的执行，每个 TaskManagers 都拥有一定数量的 slots。Slot 是一组固定大小的资源的合集 (如计算能力，存储空间)。TaskManagers 启动后，会将其所拥有的 slots 注册到 ResourceManager 上，由 ResourceManager 进行统一管理。
• Dispatcher：负责接收客户端提交的执行程序，并传递给 JobManager 。除此之外，它还提供了一个 WEB UI 界面，用于监控作业的执行情况。
• ResourceManager ：负责管理 slots 并协调集群资源。ResourceManager 接收来自 JobManager 的资源请求，并将存在空闲 slots 的 TaskManagers 分配给 JobManager 执行任务。Flink 基于不同的部署平台，如 YARN , Mesos，K8s 等提供了不同的资源管理器，当 TaskManagers 没有足够的 slots 来执行任务时，它会向第三方平台发起会话来请求额外的资源。

task & sub task

上面我们提到：TaskManagers 实际执行的是 SubTask，而不是 Task，这里解释一下两者的区别：

在执行分布式计算时，Flink 将可以链接的操作 (operators) 链接到一起，这就是 Task。之所以这样做， 是为了减少线程间切换和缓冲而导致的开销，在降低延迟的同时可以提高整体的吞吐量。 但不是所有的 operator 都可以被链接，如下 keyBy 等操作会导致网络 shuffle 和重分区，因此其就不能被链接，只能被单独作为一个 Task。 简单来说，一个 Task 就是一个可以链接的最小的操作链 (Operator Chains) 。如下图，source 和 map 算子被链接到一块，因此整个作业就只有三个 Task：

解释完 Task ，我们在解释一下什么是 SubTask，其准确的翻译是： A subtask is one parallel slice of a task，即一个 Task 可以按照其并行度拆分为多个 SubTask。如上图，source & map 具有两个并行度，KeyBy 具有两个并行度，Sink 具有一个并行度，因此整个虽然只有 3 个 Task，但是却有 5 个 SubTask。Jobmanager 负责定义和拆分这些 SubTask，并将其交给 Taskmanagers 来执行，每个 SubTask 都是一个单独的线程。

资源管理

理解了 SubTasks ，我们再来看看其与 Slots 的对应情况。一种可能的分配情况如下：

这时每个 SubTask 线程运行在一个独立的 TaskSlot， 它们共享所属的 TaskManager 进程的TCP 连接（通过多路复用技术）和心跳信息 (heartbeat messages)，从而可以降低整体的性能开销。此时看似是最好的情况，但是每个操作需要的资源都是不尽相同的，这里假设该作业 keyBy 操作所需资源的数量比 Sink 多很多 ，那么此时 Sink 所在 Slot 的资源就没有得到有效的利用。

基于这个原因，Flink 允许多个 subtasks 共享 slots，即使它们是不同 tasks 的 subtasks，但只要它们来自同一个 Job 就可以。假设上面 souce & map 和 keyBy 的并行度调整为 6，而 Slot 的数量不变，此时情况如下：

可以看到一个 Task Slot 中运行了多个 SubTask 子任务，此时每个子任务仍然在一个独立的线程中执行，只不过共享一组 Sot 资源而已。那么 Flink 到底如何确定一个 Job 至少需要多少个 Slot 呢？Flink 对于这个问题的处理很简单，默认情况一个 Job 所需要的 Slot 的数量就等于其 Operation 操作的最高并行度。如下， A，B，D 操作的并行度为 4，而 C，E 操作的并行度为 2，那么此时整个 Job 就需要至少四个 Slots 来完成。通过这个机制，Flink 就可以不必去关心一个 Job 到底会被拆分为多少个 Tasks 和 SubTasks。

参考文档

• https://www.yijiyong.com/da/rtaflink/10-summary.html
• https://blog.csdn.net/a805814077/article/details/108095451
• https://blog.csdn.net/weixin_43114209/article/details/131675299

Elasticsearch是一个基于Apache Lucene的开源搜索引擎，其依靠Lucene完成索引创建和搜索功能，可以将ElstaicSearch理解为是一个Lucene的分布式封装的搜索引擎。

前置知识

倒排索引

搜索的核心需求是全文检索，全文检索简单来说就是要在大量文档中找到包含某个单词出现的位置，在传统关系型数据库中，数据检索只能通过 like 来实现，例如需要在手机数据中查询名称包含苹果的手机，需要通过如下 sql 实现：

1

select * from phone_table where phone_brand like '%苹果手机%';

这种实现方式实际会存在很多问题，例如需要全表扫描，性能差，无法得内容与搜索条件的相关性等，为了高效的实现全文检索，我们可以通过倒排索引来解决

倒排索引是区别于正排索引的概念

• 正排索引：是以文档对象的唯一 ID 作为索引，以文档内容作为记录的结构。
• 倒排索引：Inverted index，指的是将文档内容中的单词作为索引，将包含该词的文档 ID 作为记录的结构。

FST算法

FST全程Finite State Transducer 全称有穷状态转换器；FST是一种类似于字典的数据结构，但是它是k:v结构的，使用FST有两个优先

• 空间占用小：通过对字典中单词前缀和后缀的重复利用，压缩了存储空间
• 查询效率快：查询速度不会超过 O(len(str))

如果我们要对 cat、 deep、 do、 dog、dogs这五个单词进行插入构建FST（工具演示：http://examples.mikemccandless.com/fst.py?terms=&cmd=Build+it%21），执行过程如下：

1. 插入cat, 每个字母一条边，其中t边指向终点

   

2. 插入deep, 与前一个单词 cat 进行最大前缀匹配，发现没有匹配则直接插入，P边指向终点

   

3. 插入do, 与前一个单词deep进行最大前缀匹配，发现是 d，则在d边后增加新边o，o边指向终点

   

4. 插入dog, 与前一个单词 do 进行最大前缀匹配，发现是 do，则在o边后增加新边g，g边指向终点

   

5. 插入dogs, 与前一个单词 dog 进行最大前缀匹配，发现是dog，则在g后增加新边s，s边指向终点。

   

Lucene写入原理

基本概念

​ 在Lucene中，写入数据的基本单元称之为Document，一个Document是由Field构成，Field是Term的集合，Segment是最小的独立索引单元，由多个Documents构成；在每个Segment范畴内，每个Document都被分配到了一个唯一的数字ID, 称之为DocID, 同时根据每个Field的名字定一个唯一的FieldNaming，对于索引字段进到Postings之前也会被分配一个唯一的TermID。Field除了FieldNaming之外也有一个FieldNumber，与DocID和TermID一样都是一个自增的数值。

​ 倒排索引需要将 terms 映射到包含该单词 （term） 的文档列表，这样的映射列表我们称之为：倒排列表（postings list）。具体某一条映射数据称之为：倒排索引项（Posting）。

Lucene中倒排索引的结构

根据倒排索引的概念，最简单的我们可以用一个Map来描述这个结构， Map 的 Key 存储分词后的单词（也叫Term），Map的Value存储一些列的文档ID的集合，但是全文搜索引擎在海量数据的情况下需要存储大量的文本，如果是用Map存储Directory的话有这样几个明显的缺点:

1. Dictionary 是非常大的（比如我们搜索中的一个字段在Directory里可能有上千万个Term）因此存储所有的Term需要大量的内存
2. Postings 也可能会占据大量的存储空间（一个Term多的有几百万个doc）
3. Posting List 不仅仅需要包含文档的id，为了加快搜索的速度还需要包含更多信息，比如下面这些
   • 文档 id（DocId, Document Id），包含单词的所有文档唯一id，用于去正排索引中查询原始数据
   • 词频（TF，Term Frequency），记录 Term 在每篇文档中出现的次数，用于后续相关性算分
   • 位置（Position），记录 Term 在每篇文档中的分词位置（多个），用于做词语搜索（Phrase Query）
   • 偏移（Offset），记录 Term 在每篇文档的开始和结束位置，用于高亮显示等

因此上面说的基于 Map 的实现方式几乎是不可行的。在海量数据背景下，倒排索引的实现直接关系到存储成本以及搜索性能，为此，Lucene 引入了多种巧妙的数据结构和算法，同时也把倒排索引的结构组织成如下图所示:

1. Lucene把用于存储Term的索引文件叫Terms Index，它的后缀是.tip
2. 把Postings信息分别存储在.doc、.pay、.pox，分别记录Postings的DocId信息和Term的词频、Payload信息、pox是记录位置信息
3. Terms Dictionary的文件后缀称为.tim，它是Term与Postings的关系纽带，存储了Term和其对应的Postings文件指针。

通过Terms Index(.tip) 能够快速地在Terms Dictionary(.tim) 中找到你的想要的Term，以及它对应的Postings文件指针与Term在Segment作用域上的统计信息。

postings: 实际上Postings包含的东西并不仅仅是DocIDs（我们通常把这一个有序文档编号系列叫DocIDs），它还包括文档编号、以及词频、Term在文档中的位置信息、还有Payload数据。

什么是Term Index

Terms Index存储在.tip文件中，实际张是有一个或者多个FST组成的，Segment上每个字段都有自己的一个FST（FST Index）记录在.tip上，所以图中FST Index的个数即是Segment拥有字段的个数。

什么是Term Directory

Term Directory存储了Index field 经过去重、时态统一、大小写统一、近义词处理等操作后的词项数据，最后存储在.tim文件中（也就是Term Directory 存储所有的Term数据），同时它也是 Term 与 Postings 的关系纽带，存储了每个 Term 和其对应的 Postings 文件位置指针。通过Term Directory可以知道Term的统计信息，包括Term在Segment中出现的频率等。

Terms Dictionary 内部采用 NodeBlock 这种结构对 Term 进行压缩存储，处理过程会将相同前缀的 Term 压缩为一个 NodeBlock，然后将每个 Term 的后缀以及对应 Term 的 Posting 关联信息处理为一个 Entry 保存到 Block，如下图所示:

什么是PostingList

PostingList 包含文档 id、词频、位置等多个信息，这些数据之间本身是相对独立的，因此 Lucene 将 Postings List 拆成三个文件存储：

• .doc文件：记录 Postings 的 docId 信息和 Term 的词频
• .pay文件：记录 Payload 信息和偏移量信息
• .pos文件：记录位置信息

这个做法有没有点列式存储的味道？其好处也很明显：一来可以提高读取效率，因为基本所有的查询都会用 .doc 文件获取文档 id，但一般的查询仅需要用到 .doc 文件就足够了，只有对于近似查询等位置相关的查询才需要用位置相关数据， 二来这样存储数据很方便对数据进行压缩

三个文件整体实现差不太多，这里仅介绍.doc 文件，.doc 文件存储的是每个 Term 对应的文档 Id 和词频。每个 Term 都包含一对 TermFreqs 和 SkipData 结构，其中 TermFreqs 存放 docId 和词频信息，SkipData 为跳表结构，用于实现 TermFreqs 内部的快速跳转

Posting List 采用多个文件进行存储，最终我们可以得到每个 Term 的如下信息：

• SkipOffset：用来描述当前 term 信息在 .doc 文件中跳表信息的起始位置。
• DocStartFP：是当前 term 信息在 .doc 文件中的文档 ID 与词频信息的起始位置。
• PosStartFP：是当前 term 信息在 .pos 文件中的起始位置。
• PayStartFP：是当前 term 信息在 .pay 文件中的起始位置。

为了压缩Posting List的存储空间，需要对Posting List进行压缩，Lucene采用的压缩算法是: FOR + RBM

Lucene的搜索过程

lucene的搜索过程如下：

• 通过 Term Index 数据（.tip文件）中的 StartFP 获取指定字段的 FST
• 通过 FST 找到指定 Term 在 Term Dictionary（.tim 文件）可能存在的 Block
• 将对应 Block 加载内存，遍历 Block 中的 Entry，通过后缀（Suffix）判断是否存在指定 Term
• 存在则通过 Entry 的 TermStat 数据中各个文件的 FP 获取 Posting 数据
• 如果需要获取 Term 对应的所有 DocId 则直接遍历 TermFreqs，如果获取指定 DocId 数据则通过 SkipData快速跳转

参考文档

• 捋一捋ElasticSearch（三）| Lucene存储引擎 — 推荐阅读
• ES的FST原理 — 推荐阅读
• ElasticSearch倒排索引使用算法FST — 可以看看~
• lucene字典实现原理——FST – 也可以看看~
• ElasticSearch索引核心原理
• Lucene 3.0 原理与代码分析完整版

在项目开发中，正对项目的测试分为多个分类，比如单元测试、集成测试、端到端测试等，按照Mike Cohn提出的“测试金字塔”概念，测试分为4个层次：

最下面的是单元测试，单元测试针对的是代码进行测试，针对的是局部代码功能；再而之上是集成测试，它针对的是服务的接口进行测试；接着网上是端到端的测试，也就是我们所说的链路测试，它针对的是服务的功能进行测试，负责从一个链路的入口输入测试用例，验证输出的系统的结果；再上一层是我们最常用的UI测试，就是测试人员在UI界面上根据功能进行点击测试。

测试金字塔建议我们：

（1）尽可能地多做单元测试 和 集成测试，因为他们的执行速度相较于上层的几个测试类型来说快很多且相对稳定，可以一天多次执行。

（2）尽可能地少做 组件测试、端到端测试 和 探索性测试，因为他们的执行速度相较单元测试 和 集成测试 会慢很多，且不够稳定，无法做到一天多次执行，每次执行都要等很久才能获得反馈结果。

画外音：金字塔里，越往下速度越快且越稳定，那么就可以频繁执行，反正执行一次也花不了多久时间，开发人员还可以知道我的代码有没有影响到其他模块。越往上则速度越慢且越不稳定，跑一次要N久，开发人员往往会觉得还是先继续开发吧，到时候出了bug再说，我可不想加班等测试结果。

单元测试

什么是单元你测试

单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类、超类、抽象类等中的方法。单元测试就是软件开发中对最小单位进行正确性检验的测试工作。

不同地方对单元测试有的定义可能会有所不同，但有一些基本共识：

• 单元测试是比较底层的，关注代码的局部而不是整体。
• 单元测试是开发人员在写代码时候写的。
• 单元测试需要比其他测试运行得快。

单元测试的意义

• 提高代码质量: 代码测试都是为了帮助开发人员发现问题从而解决问题，提高代码质量。
• 尽早发现问题: 问题越早发现，解决的难度和成本就越低。
• 保证重构正确性: 随着功能的增加，重构（修改老代码）几乎是无法避免的。很多时候我们不敢重构的原因，就是担心其它模块因为依赖它而不工作。有了单元测试，只要在改完代码后运行一下单测就知道改动对整个系统的影响了，从而可以让我们放心的重构代码。
• 简化调试过程: 单元测试让我们可以轻松地知道是哪一部分代码出了问题。
• 简化集成过程: 由于各个单元已经被测试，在集成过程中进行的后续测试会更加容易。
• 优化代码设计: 编写测试用例会迫使开发人员仔细思考代码的设计和必须完成的工作，有利于开发人员加深对代码功能的理解，从而形成更合理的设计和结构。
• 单元测试是最好的文档: 单元测试覆盖了接口的所有使用方法，是最好的示例代码。而真正的文档包括注释很有可能和代码不同步，并且看不懂。

单元测试基本原则

1. 单元测试文件名以xxx_test.go命名，测试文件跟被测试文件处于同个包中;
2. 测试用例以Test开头, 测试函数为TestXxx, 整体风格保持一致;
3. 测试用例应该完备，应考虑到各个边界情况，推荐使用table-driven的方式实现;
4. 单元测试的结果是确定且一致的，跟环境无关的;
5. 测试用例是独立的，不同的测试用例之间不能有互相依赖;
6. 单元测试程序不应该有用户输入，测试结果应该能直接被电脑获取，不应该由人来判断;
7. 函数中通过调用testing.T的Error, Errorf, FailNow, Fatal, FatalIf等方法记录测试的信息;
8. 可以通过benchmark做并发测试，验证代码性能;

常见的测试框架

golang自带的testing包已经可以完美支持单元测试，我们在写一个文件，函数的时候，可以直接在需要单元测试的文件旁边增加一个_test.go的文件。而后直接使用 go test 直接跑测试用例就可以了。但是因为单元测试是与环境无关的，因此在编写测试用例时总是需要把一些第三发依赖给mock掉，因此需要借助其他的测试组件来完成，下面是一些常见的mock框架：

1. 基于接口的Mock框架-goMock
2. 全局变量、函数、过程打桩框架-goStub
3. 动态打桩框架(非并发安全)-goMonkey
4. 数据库和缓存等中间件mock框架(sqlMock, redisMock)
5. http请求mock框架-httpmock

goMonkey

go monkey 可以动态的执行打桩，目标是让用户在单元测试中低成本的完成打桩，从而将精力聚焦于业务功能的开发。gomonkey支持多种打桩方式，可以无入侵的实现打桩，但是需要注意的是：

1. 运行 monkey需要关闭 Go 语言的内联优化才能生效，也就是编译时需要添加 -gcflags=all=-l 参数才行

   注意：

   1. 如果是 M1 系统，编译需要指定 goarch 为 amd64
      @MAC-M1# GOARCH=amd64 go build -gcflags=all=-l -o xxx main.go
      @MAC-INTEL# go build -gcflags=all=-l -o xxx main.go
      解决的问题：monkey mac m1 execute syscall.Mprotect error：panic: permission denied [recovered]
      ref: https://github.com/agiledragon/gomonkey/issues/57
      ref: https://blog.csdn.net/qw790707988/article/details/119710144
   2. monkey不应该用于生产系统, 否则可能引发未知事故
   3. monkey 需要在运行的时候修改内存代码段，因而无法在一些对安全性要求比较高的系统上工作

集成测试与E2E测试

go开发者一般使用Ginkgo + Gomega 实现集成测试与E2E测试。Ginkgo /ˈɡɪŋkoʊ / 是Go语言的一个行为驱动开发（BDD， Behavior-Driven Development）风格的测试框架，通常和库Gomega一起使用。Ginkgo在一系列的“Specs”中描述期望的程序行为。

Ginkgo简介

inkgo是Go语言的一个行为驱动开发（BDD， Behavior-Driven Development）风格的测试框架，通常和库Gomega一起使用。Ginkgo在一系列的“Specs”中描述期望的程序行为。

安装使用

1
2
3

go get -u github.com/onsi/ginkgo/ginkgo

ginkgo bootstrap

测试模块

• It: 是测试例的基本单位，即It包含的代码就算一个测试用例
• Context和Describe: 是将一个或多个测试例归类
• BeforeEach: 是每个测试例执行前执行该段代码
• AfterEach: 是每个测试例执行后执行该段代码
• JustBeforeEach: 是在BeforeEach执行之后，测试例执行之前执行
• BeforeSuite: 是在该测试集执行前执行，即该文件夹内的测试例执行之前
• AfterSuite: 是在该测试集执行后执行，即该文件夹内的测试例执行完后
• By: 是打印信息，内容只能是字符串，只会在测试例失败后打印，一般用于调试和定位问题
• Fail: 是标志该测试例运行结果为失败，并打印里面的信息
• Specify: 和It功能完全一样，It属于其简写

测试方法列表

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103

# 断言
Expect(ACTUAL).Should(Equal(EXPECTED))
Expect(ACTUAL).To(Equal(EXPECTED))
Expect(ACTUAL).ShouldNot(Equal(EXPECTED))
Expect(ACTUAL).NotTo(Equal(EXPECTED))
Expect(ACTUAL).ToNot(Equal(EXPECTED))

// 断言没有发生错误
Expect(err).ShouldNot(HaveOccurred())
Expect(DoSomethingSimple()).Should(Succeed())

// 断言注解
Expect(ACTUAL).To(Equal(EXPECTED), "My annotation %d", foo)
Expect(ACTUAL).To(Equal(EXPECTED), func() string { return "My annotation" })

# 相等
// 如果ACTUAL和EXPECTED都为nil，断言会失败
Expect(ACTUAL).Should(Equal(EXPECTED))
 
Expect(ACTUAL).Should(BeEquivalentTo(EXPECTED))
 
// 使用 == 进行比较
BeIdenticalTo(expected interface{})

# 空值/零值
// 断言ACTUAL为Nil
Expect(ACTUAL).Should(BeNil())
 
// 断言ACTUAL为它的类型的零值，或者是Nil
Expect(ACTUAL).Should(BeZero())

# 布尔值
Expect(ACTUAL).Should(BeTrue())
Expect(ACTUAL).Should(BeFalse())

# 错误
Expect(ACTUAL).Should(HaveOccurred())
 
// 没有错误
err := SomethingThatMightFail()
Expect(err).ShouldNot(HaveOccurred())

// 如果ACTUAL为Nil则断言成功
Expect(ACTUAL).Should(Succeed())

# 字符串
// 子串判断
Expect(ACTUAL).Should(ContainSubstring(STRING, ARGS...))
 
// 前缀判断
Expect(ACTUAL).Should(HavePrefix(STRING, ARGS...))
 
// 后缀判断
Expect(ACTUAL).Should(HaveSuffix(STRING, ARGS...))
 
// 正则式匹配
Expect(ACTUAL).Should(MatchRegexp(STRING, ARGS...))

# JSON/XML/YML
Expect(ACTUAL).Should(MatchJSON(EXPECTED))
Expect(ACTUAL).Should(MatchXML(EXPECTED))
Expect(ACTUAL).Should(MatchYAML(EXPECTED))

# 集合（string, array, map, chan, slice）
// 断言为空
Expect(ACTUAL).Should(BeEmpty())
 
// 断言长度
Expect(ACTUAL).Should(HaveLen(INT))
 
// 断言容量
Expect(ACTUAL).Should(HaveCap(INT))
 
// 断言包含元素
Expect(ACTUAL).Should(ContainElement(ELEMENT))
 
// 断言等于 其中之一
Expect(ACTUAL).Should(BeElementOf(ELEMENT1, ELEMENT2, ELEMENT3, ...))
 
// 断言元素相同，不考虑顺序
Expect(ACTUAL).Should(ConsistOf(ELEMENT1, ELEMENT2, ELEMENT3, ...))
Expect(ACTUAL).Should(ConsistOf([]SOME_TYPE{ELEMENT1, ELEMENT2, ELEMENT3, ...}))
 
// 断言存在指定的键，仅用于map
Expect(ACTUAL).Should(HaveKey(KEY))

// 断言存在指定的键值对，仅用于map
Expect(ACTUAL).Should(HaveKeyWithValue(KEY, VALUE))

# 数字/时间
// 断言数字意义（类型不感知）上的相等
Expect(ACTUAL).Should(BeNumerically("==", EXPECTED))
 
// 断言相似，无差不超过THRESHOLD（默认1e-8）
Expect(ACTUAL).Should(BeNumerically("~", EXPECTED, <THRESHOLD>))
 
 
Expect(ACTUAL).Should(BeNumerically(">", EXPECTED))
Expect(ACTUAL).Should(BeNumerically(">=", EXPECTED))
Expect(ACTUAL).Should(BeNumerically("<", EXPECTED))
Expect(ACTUAL).Should(BeNumerically("<=", EXPECTED))
 
Expect(number).Should(BeBetween(0, 10))

参考文档

• golang项目的测试实践
• What Is 测试金字塔？
• gomonkey调研文档和学习
• ginkgo学习笔记

etcd是使用Go语言开发的一个开源的、高可用的分布式key-value存储系统，可以用于配置共享和服务的注册和发现。

类似项目有zookeeper和consul。

etcd具有以下特点：

• 完全复制：集群中的每个节点都可以使用完整的存档
• 高可用性：Etcd可用于避免硬件的单点故障或网络问题
• 一致性：每次读取都会返回跨多主机的最新写入
• 简单：包括一个定义良好、面向用户的API（gRPC）
• 安全：实现了带有可选的客户端证书身份验证的自动化TLS
• 快速：每秒10000次写入的基准速度
• 可靠：使用Raft算法实现了强一致、高可用的服务存储目录

etcd安装使用方法

etcd支持单机模式，以及使用集群模式部署，支持部署在各种操作系统中。

mac安装etcd单机模式

mac安装etcd整体上来说非常简单，只需要一个命令即可（linux其实也是一个命令即可）

1
2
3
4
5
6
7

brew install etcd
brew searvices start etcd
brew services list

# etcdctl endpoint health
➜  ~ etcdctl endpoint health
127.0.0.1:2379 is healthy: successfully committed proposal: took = 3.219075ms

etcdctl命令使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

NAME:
etcdctl - A simple command line client for etcd3.

COMMANDS:
alarm disarmDisarms all alarms
alarm listLists all alarms
auth disableDisables authentication
auth enableEnables authentication
auth statusReturns authentication status
check datascaleCheck the memory usage of holding data for different workloads on a given server endpoint.
check perfCheck the performance of the etcd cluster
compactionCompacts the event history in etcd
defragDefragments the storage of the etcd members with given endpoints
delRemoves the specified key or range of keys [key, range_end)
electObserves and participates in leader election
endpoint hashkvPrints the KV history hash for each endpoint in --endpoints
endpoint healthChecks the healthiness of endpoints specified in `--endpoints` flag
endpoint statusPrints out the status of endpoints specified in `--endpoints` flag
getGets the key or a range of keys
helpHelp about any command
lease grantCreates leases
lease keep-aliveKeeps leases alive (renew)
lease listList all active leases
lease revokeRevokes leases
lease timetoliveGet lease information
lockAcquires a named lock
make-mirrorMakes a mirror at the destination etcd cluster
member addAdds a member into the cluster
member listLists all members in the cluster
member promotePromotes a non-voting member in the cluster
member removeRemoves a member from the cluster
member updateUpdates a member in the cluster
move-leaderTransfers leadership to another etcd cluster member.
putPuts the given key into the store
role addAdds a new role
role deleteDeletes a role
role getGets detailed information of a role
role grant-permissionGrants a key to a role
role listLists all roles
role revoke-permissionRevokes a key from a role
snapshot restoreRestores an etcd member snapshot to an etcd directory
snapshot saveStores an etcd node backend snapshot to a given file
snapshot status[deprecated] Gets backend snapshot status of a given file
txnTxn processes all the requests in one transaction
user addAdds a new user
user deleteDeletes a user
user getGets detailed information of a user
user grant-roleGrants a role to a user
user listLists all users
user passwdChanges password of user
user revoke-roleRevokes a role from a user
versionPrints the version of etcdctl
watchWatches events stream on keys or prefixes

OPTIONS:
      --cacert=""verify certificates of TLS-enabled secure servers using this CA bundle
      --cert=""identify secure client using this TLS certificate file
      --command-timeout=5stimeout for short running command (excluding dial timeout)
      --debug[=false]enable client-side debug logging
      --dial-timeout=2sdial timeout for client connections
  -d, --discovery-srv=""domain name to query for SRV records describing cluster endpoints
      --discovery-srv-name=""service name to query when using DNS discovery
      --endpoints=[127.0.0.1:2379]gRPC endpoints
  -h, --help[=false]help for etcdctl
      --hex[=false]print byte strings as hex encoded strings
      --insecure-discovery[=true]accept insecure SRV records describing cluster endpoints
      --insecure-skip-tls-verify[=false]skip server certificate verification (CAUTION: this option should be enabled only for testing purposes)
      --insecure-transport[=true]disable transport security for client connections
      --keepalive-time=2skeepalive time for client connections
      --keepalive-timeout=6skeepalive timeout for client connections
      --key=""identify secure client using this TLS key file
      --password=""password for authentication (if this option is used, --user option shouldn't include password)
      --user=""username[:password] for authentication (prompt if password is not supplied)
  -w, --write-out="simple"set the output format (fields, json, protobuf, simple, table)

etcdctl 命令分为几大模块，分别是跟etcd集群现网的命令例如member, endpoint, 第二个是租约有关的lease（类似ttl）, 第三个是数据相关的，包括watch、put、get等，第四个是跟角色认证相关的信息，常见的命令如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# -w 参数用于输出执行的格式，只是fields, json, protobuf, sample, table 默认sample
# --endpoints 参数用于etcdctl跟ectd集群建联，默认是127.0.0.1:2379
# --cacert, --cert等参数用于指定ca证书信息
etcdctl -w table endpoint health
etcdctl -w table member list
etcdctl -w json endpoint status

# 增删改查
etcdctl put hello word
etcdctl get hello
etcdctl watch hello
etcdctl del hello

# 可以通过--prefix参数监听指定前缀的参数
etcdctl watch --prefix=true hello # 可以监听到hello1、hello2等参数数据
etcdctl get --prefix=true hello  # 可以获取到hello1、hello2等参数数据

golang操作使用etcd

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132

package main

import (
"context"
"fmt"
"log"
"time"

clientv3 "go.etcd.io/etcd/client/v3"
)

func main() {
cli, err := clientv3.New(clientv3.Config{
Endpoints:   []string{"127.0.0.1:2379"},
DialTimeout: 5 * time.Second,
})
if err != nil {
panic(err)
}
defer cli.Close()

etcdBase(cli)
etcdWatch(cli)
etcdLease(cli)
etcdKeepAlive(cli)
}

// etcdBase 基础的创建跟删除
func etcdBase(client *clientv3.Client) {
var key = "/hb/etcd/base"
if _, err := client.Put(context.Background(), key, "123456"); err != nil {
fmt.Printf("error is: %#v \n", err)
}

resp, err := client.Get(context.Background(), key)
if err != nil {
fmt.Printf("error is: %#v \n", err)
}

for _, kvs := range resp.Kvs {
fmt.Printf("Get key=%v, value=%v \n", string(kvs.Key), string(kvs.Value))
}

if _, err := client.Delete(context.Background(), key); err != nil {
fmt.Printf("error is: %#v \n", err)
}
}

// etcd watch机器
func etcdWatch(client *clientv3.Client) {
var watchKey = "/hb/etcd/watch"

go func() {
for i := 0; i < 10; i++ {
_, _ = client.Put(context.Background(), fmt.Sprintf("%s/key_%d", watchKey, i), "world")
}

for i := 0; i < 10; i++ {
_, _ = client.Delete(context.Background(), fmt.Sprintf("%s/key_%d", watchKey, i))
}
}()

go func() {
watchCh := client.Watch(context.Background(), watchKey, clientv3.WithPrefix())
for resp := range watchCh {
for _, ev := range resp.Events {
fmt.Printf("Watch Type: %s; Key: %s; Value: %s\n", ev.Type, ev.Kv.Key, ev.Kv.Value)
}
}
}()
}

// etcdLease etcd租约
func etcdLease(client *clientv3.Client) {
var key = "/hb/etcd/lease"
// 创建一个5秒的租约
grantResp, err := client.Grant(context.Background(), 5)
if err != nil {
fmt.Printf("hello")
log.Fatal(err)
}

// 5秒钟之后, key就会被移除
_, err = client.Put(context.Background(), key, "lease", clientv3.WithLease(grantResp.ID))
if err != nil {
log.Fatal(err)
}

resp, err := client.Get(context.Background(), key)
if err != nil {
log.Fatal(err)
}

for _, kvs := range resp.Kvs {
fmt.Printf("Lease key=%v, value=%v \n", string(kvs.Key), string(kvs.Value))
}

time.Sleep(6 * time.Second)

resp, err = client.Get(context.Background(), key)
if err != nil {
log.Fatal(err)
}

for _, kvs := range resp.Kvs {
fmt.Printf("Lease Expired key=%v, value=%v \n", string(kvs.Key), string(kvs.Value))
}
}

// etcdKeepAlive etcd keepAlive
func etcdKeepAlive(client *clientv3.Client) {
var key = "/hb/etcd/keepalive"
resp, err := client.Grant(context.TODO(), 5)
if err != nil {
log.Fatal(err)
}

_, err = client.Put(context.TODO(), key, "keepalive", clientv3.WithLease(resp.ID))
if err != nil {
log.Fatal(err)
}

// the key 'foo' will be kept forever
ch, err := client.KeepAlive(context.TODO(), resp.ID)
if err != nil {
log.Fatal(err)
}
for {
ka := <-ch
fmt.Println("KeepAlive TTL: ", ka.TTL)
}
}

etcd工作原理

etcd 是一个基于 Raft 共识算法实现的分布式键值存储服务，在项目结构上采用了模块化设计，其中最主要的三个部分是实现分布式共识的 Raft 模块、实现数据持久化的 WAL 模块和实现状态机存储的 MVCC 模块。

Leader 选举

Raft 是一种用来管理日志复制过程的算法，Raft 通过『领导选举机制』选举出一个 Leader，由它全权管理日志复制来实现一致性。一个 Raft 集群包含若干个服务器节点，每一个节点都有一个唯一标识 ID。Raft 算法论文规定了三种节点身份：Leader、Follower 和 Candidate，etcd 的实现中又添加了 PreCandidate 和 Learner 这两种身份。

leader选择过程

1. 集群启动时所有节点初始状态均为 Follower，同时启动选举定时器（时间随机，降低冲突概率），随后会有一个节点选举成功成为 Leader，在绝大多数时间里集群内的节点会处于这两种身份之一。
2. 当某个节点当选成为Leader后，需要定期的向Follower发送心跳包，Follower收到心跳包后会重置选举定时器。
3. 当一个 Follower 节点的选举计时器超时后（节点在指定的时间之内没有收到leader或者candidate的有效消息时会发起选举），会先进入preVote状态（切换为 PreCandidate 身份），在它准备发起一次选举之前，需要尝试连接集群中的其他节点，并询问它们是否愿意参与选举
4. 如果集群中的其它节点能够正常收到 Leader 的心跳消息，那么会拒绝参与选举。
5. 如果有超过法定人数的节点响应并表示参与新一轮选举，该节点会从 PreCandidate 身份切换到 Candidate，发起新一轮的选举。

参考文档

• go操作etcd
• 分布式键值存储 etcd 原理与实现 · Analyze
• 高可用分布式存储 etcd 的实现原理
• Etcd Raft库的日志存储
• https://pkg.go.dev/go.etcd.io/etcd/client/v3

近期，有同学反馈，所有调用的微博图床图片都无法加载并提示“403 Forbidden”了。百度上说新浪开启了防盗链，查遍了网上一堆复制/粘贴出来的文章，不是开启反向代理就是更改请求头，但是这些方案都不行。最终方案只能自己自建图床（其实自建图床的成本并不高，只是自己懒得搞，注册了个七牛云的对象存储，但是需要绑定域名，所以上次只能作罢，这次就使用腾讯COS作为图床吧~），为了批量把文档中的新浪图片替换成腾讯cos，也是花了丢时间写了个脚本用于批量替换。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180

package main

import (
"context"
"fmt"
"io"
"io/fs"
"net/http"
"net/url"
"os"
"path"
"path/filepath"
"regexp"
"strings"

"github.com/tencentyun/cos-go-sdk-v5"
)

const (
sinaImageCacheDir = "/tmp"
mdFileDir         = "xxx"
CosSecretId       = "xxx"
CosSecretKey      = "xxx"
CosBucketUrl      = "xxx"
)

type mdFile struct {
fileName       string
filePath       string
fileContent    string
sinaImages     map[string]string
downloadImages map[string]string
cosImages      map[string]string
}

func main() {
if err := createSinaImageCacheDir(); err != nil {
panic(err)
}

mdFiles, err := listFileContent(mdFileDir)
if err != nil {
panic(err)
}

for _, file := range mdFiles {
downloadSinaImage(file)
}

for _, file := range mdFiles {
uploadTencentCos(file)
}

for _, file := range mdFiles {
replaceSinaImageUrl(file)
}
}

func createSinaImageCacheDir() error {
_, err := os.Stat(sinaImageCacheDir)
if err != nil {
if os.IsNotExist(err) {
return os.Mkdir(sinaImageCacheDir, fs.ModePerm)
}

return err
}

return nil
}

func listFileContent(dir string) ([]*mdFile, error) {
fileName, err := filepath.Glob(fmt.Sprintf("%s/*.md", dir))
if err != nil {
return nil, err
}

mdFiles := make([]*mdFile, 0, len(fileName))
for _, name := range fileName {
// 获取文件列表
_, file := path.Split(name)
fileContent, err := os.ReadFile(name)
if err != nil {
continue
}

// 获取新浪图片
simaImages := map[string]string{}
sinaImages := regexp.MustCompile(`https://tva1.sinaimg.cn/large/(\w+).jpg|.jpeg|.png`).FindAllString(string(fileContent), -1)
fmt.Printf("sinaimages")
for _, imageUrl := range sinaImages {
_, imageName := path.Split(imageUrl)
simaImages[imageUrl] = imageName
}

mdFiles = append(mdFiles, &mdFile{
fileName:    file,
filePath:    name,
fileContent: string(fileContent),
sinaImages:  simaImages,
})
}

return mdFiles, nil
}

func downloadSinaImage(file *mdFile) {
downloadImagePaths := map[string]string{}
for sinaImageUrl, sinaFileName := range file.sinaImages {
resp, err := http.Get(sinaImageUrl)
if err != nil || resp.StatusCode != http.StatusOK {
fmt.Printf("failed get sina image, error=%v, statusCode=%v", err, resp.StatusCode)
continue
}

fileName := fmt.Sprintf("%s/%s", sinaImageCacheDir, sinaFileName)
out, err := os.Create(fileName)
if err != nil {
fmt.Printf("failed create file, err=%v, fileName=%v", err, fileName)
_ = resp.Body.Close()
continue
}

// 然后将响应流和文件流对接起来
_, err = io.Copy(out, resp.Body)
if err != nil {
fmt.Printf("failed io.Copy, err=%v", err)
_ = resp.Body.Close()
continue
}

downloadImagePaths[sinaImageUrl] = fileName
_ = resp.Body.Close()
}

file.downloadImages = downloadImagePaths
}

// 上传到腾讯cos
func uploadTencentCos(file *mdFile) {
u, _ := url.Parse(CosBucketUrl)
b := &cos.BaseURL{BucketURL: u}
c := cos.NewClient(b, &http.Client{
Transport: &cos.AuthorizationTransport{
SecretID:  CosSecretId,
SecretKey: CosSecretKey,
},
})

cosImageUrls := map[string]string{}
for sinaImageUrl, localFileName := range file.downloadImages {
fd, err := os.Open(localFileName)
if err != nil {
continue
}

fileName, ok := file.sinaImages[sinaImageUrl]
if !ok {
continue
}
_, err = c.Object.Put(context.Background(), fileName, fd, nil)
if err != nil {
fmt.Printf("put image to cos failed, err=%v", err)
continue
}
cosImageUrls[sinaImageUrl] = fmt.Sprintf("%s/%s", CosBucketUrl, fileName)
}

file.cosImages = cosImageUrls
}

func replaceSinaImageUrl(file *mdFile) {
for sinaImageUrl, cosImageUrl := range file.cosImages {
file.fileContent = strings.ReplaceAll(file.fileContent, sinaImageUrl, cosImageUrl)
}

if err := os.WriteFile(file.filePath, []byte(file.fileContent), 0644); err != nil {
fmt.Printf("failed write file, err=%v", err)
}
}

quic草案的阅读总是晦涩难懂的，如果没有多读几遍，压根就不懂这说的是啥意思，阅读草案之前建议读者先了解相关知识，带着相关知识去阅读更易理解。

QUIC之基础概念

connection

连接用途在客户端和服务器之间建立连接。和tcp不同的是(tcp是通过连接四元组[client ip、client port、server ip、server port]来确定一个连接)，quic是通过连接id(connectionId)来标识一个连接。

stream

stream是一个抽象的概念，它表达了一个有序传输的字节流，而这些字节其实就是由Stream Frame(一系列的帧)排在一起构成。在一个quic connection上，可以同时传输多条流。

流可以是单向的或双向的，单向流只能往一个方向传输数据，双向流允许双端向对端发送数据。

在连接中，通过StreamID来标志一个流，通过流ID的最小有效位标志流的发起者，流ID的次小有效位标志流的类型。

流帧封装应用层发送的数据。终端使用流帧的流ID及偏移字段整理数据并将流数据以一个有序字节流传递给应用层，终端可以从一条流的同一个偏移位置多次接收数据，如果数据已经被接收过，则直接丢弃此数据。

流状态

流有两种状态，分为发送流和接收流

在流的发送部分，应用层协议可以：

• 写数据，只有当流量控制给数据写出留足空间，才能成功写入；
• 结束流（清理并关闭），发送一个设置FIN位为1的流帧；
• 重置流（中止并关闭），当流未处在终止状态时发送一个RESET_STREAM帧。

在流的接收部分，应用层协议可以:

• 读数据
• 中止读取流数据并请求关闭流，该操作可能需要发送STOP_SENDING帧

Frame帧

在对QUIC数据包进行解密且去除掉header后，packet的荷载里都是frame（至少包括1个）。

如果packet的荷载里，不包括ACK, PADDING, CONNECTION_CLOSE这种三种类型的帧，那么这个packet则被定义为ack确认帧，意味着对端必须对这种packet生成相应的ack通知发送方，以确保数据没有丢失。

packet的荷载里frames的类型在多达30种类型，每种类型都有自己的应用场景，如ACK Frame用于可靠传输（Recovery)，Crypto用于安全传输（TLS握手），Stream Frame用于业务数据传递，MAX_DATA/DATA_BLOCKED用于流控，PING Frame可以用于mtu探测，具体参考(https://autumnquiche.github.io/RFC9000_Chinese_Translation/#19_Frame_Types_and_Formats)

QUIC数据包

一个UDP报文包含一个或者多个数据包，QUIC定义了两类数据包头，长包头和短包头。区分长包头还是短包头主要是根据第一个字节的最高位来区分。

除了1-RTT属于短包头外，其余的数据包都属于长包头(initial包，0-RTT包，handshake包,重试数据包都属于长包头)，长包头被用于在1-RTT密钥建立前发送的数据包。一旦有了1-RTT密钥，发送方就会改用短包头发送数据包

QUIC之地址校验

地址校验主要是用于确保端点不会被用于流量放大攻击（traffic amplification attack）。攻击者如果伪造数据包的源地址为受害者的地址，发送大量的数据包给服务端，如果服务端没有进行地址验证，直接响应大量数据包给源地址（受害者），就会被攻击者利用、进行流量放大攻击。

QUIC 针对放大攻击的主要防御措施是验证端点是否能够在其声明的传输地址接收数据包。地址验证在连接建立（connection establishment）期间和连接迁移（connection migration）期间进行。

连接建立时的地址校验

连接建立时，为了验证客户端的地址是否是攻击者伪造的，服务端会生成一个令牌（token）并通过重试包（Retry packet）响应给客户端。客户端需要在后续的初始包（Initial packet）带上这个令牌，以便服务端进行地址验证。

服务端可以在当前连接中通过 NEW_TOKEN 帧预先发布令牌，以便客户端在后续的新连接使用，这是 QUIC 实现 0-RTT 很重要的一个功能。

重试数据包（Retry packet）中提供的令牌只能立即使用，不能用于后续连接的地址验证。而 NEW_TOKEN 帧生成的令牌可以在一个时间范围内使用，这个令牌应该有一个过期时间，可以是显式的过期时间，也可以是可用于动态计算过期时间的时间戳（timestamp）。服务端可以存储过期时间，也可以在令牌中以加密的形式包含它。

需要注意的是：

1. 在验证客户端的地址之前，服务端发送的字节数不能超过它接收到的字节数的三倍，用于避免攻击者在地址验证之前进行放大攻击。

2. 客户端必须确保初始数据包（Initial packets）的大小至少1200 字节，如果少于 1200 字节则可以添加 PADDING 帧填充。

3. 如果客户端没有收到来自服务端发送的初始数据包或者握手包，而且客户端没有发送额外的初始包或者握手包，那么这会引发死锁。因此为了防止死锁，客户端必须在探测超时(PTO)时（重新）发送数据包，如果客户端没有握手秘钥，那么他必须（重新）发送初始化数据包，如果有握手秘钥，那么它应该发送一个握手数据包

路径验证

路径验证用于（端点）连接迁移时校验更新后路径是否可达，在路径验证中，端点会校验本地地址和对端地址间的可达性(这里说的地址是指IP+端口组成的二元组)

路径验证测试是在一条路径上发送给对端的数据包有没有被对端收到，使用地址验证用于确保端点从迁移方收到的数据包不携带伪造的源地址。

启动路径验证

端点通过发送一个PATH_CHALLENGE帧用于启动路径验证，PATH_ChALLENGE帧中的必须包含一个不可预测的 payload，以便它可以将对端响应的PATH_CHALLENGE帧关联起来。

端点可以发送多个 PATH_CHALLENGE 帧以防止数据包丢失。但是不应该在同一个数据包（packet）中发送多个 PATH_CHALLENGE 帧，而是要分别在不同的数据包（packet）中发送。

端点必须将包含PATH_CHALLENGE帧的数据包扩展到至少1200字节(如果不足1200字节需要使用PADDING帧填充)

端点不应该以高于初始化数据包(Initial包)的频率发送PATH_CHALLENGE帧，以确保连接迁移不会比建立新连接带来更多的载荷

响应路径验证

端点在接收到 PATH_CHALLENGE 帧时，必须通过 PATH_RESPONSE 帧响应，PATH_RESPONSE帧的payload跟PATH_CHALLENGE帧一致。除非受到拥塞控制（congestion control）的限制，否则端点不得延迟传输包含 PATH_RESPONSE 帧的数据包。

PATH_RESPONSE 帧必须在接收到 PATH_CHALLENGE 的那条路径上发送。

端点(也)必须将包含 PATH_RESPONSE 帧的数据报扩展到 至少1200 字节。

端点不能发送多个 PATH_RESPONSE 帧来响应一个 PATH_CHALLENGE 帧。

QUIC之版本协商

QUIC标准化的过程中，发布了多个版本的草案，市面上的QUIC协议实现可能基于不同的版本(daft-29,daft-30),这意味着客户端跟服务端支持的quic协议版本不一样，因此在建立连接时需要先进行版本协商，使用双发都支持的一个版本。

发送版本协商包

客户端发送的第一个包(Initial包)决定服务端是否发送版本协商包，客户端和服务端创建连接时，客户端在首次发起请求时需要带上它支持的协议版本号。

• 如果服务端可以支持客户端的版本， 服务端将为连接的整个生命周期使用这个协议版本。
• 如果服务端不支持该版本，服务端将发送版本协商包附上它所支持的版本集合，这将增加 1-RTT（Round-Trip Time） 的延迟开销。

需要注意的是：

• 为了减少放大攻击（amplification attacks），QUIC 协议要求客户端发送的初始数据包大小（Initial Datagram Size）最少为 1200 字节。如果初始数据包小于 1200 字节，需要使用 PADDING frame 填充，不然该数据包会被服务端丢弃。
• 只有服务端可以发送版本协商包（Version Negotiation packet），客户端不能发送。
• 服务端识别到 0-RTT 数据包（之前有成功连接过），可以选择不发送版本协商包，以减少额外的 1-RTT 版本协商延迟。
• 服务端响应发送的初始（Initial）数据包或版本协商数据包可能丢失，客户端可以继续发送新的数据包、直到它成功接收到服务端响应，或者放弃连接尝试。

处理版本协商包

客户端收到版本协商包后，从服务端所支持的版本集合里面挑选它所支持的版本。

• 如果所有的版本都不支持，则客户端需要丢弃连接。
• 如果有匹配到支持的版本，客户端尝试使用该版本创建新连接。新连接必须使用一个新的随机目标连接ID（Destination Connection ID）。

如果客户端已接收并成功处理了任何其他包（包括早期的版本协商包），则客户端必须丢弃它后来新收到的版本协商包。

关于QUIC的版本：

QUIC 版本使用 32 位无符号数字标识，版本号 0x00000000 被保留用来表示版本协商。版本号 0x00000001 作为 RFC 发布的协议版本

0x?a?a?a?a 格式的版本号被保留（reserved）用于强制执行版本协商

版本协商包格式

注意事项：

• 版本协商包不需要 ACK
• 版本协商包没有 Packet Number 和 Length 字段。因此，它将使用整个 UDP 数据报（datagram）。
• 服务端不能在单个 UDP 数据报（datagram）里面发送多个版本协商包。

QUIC之连接建立

Packet Number及其上下文

Packet Number 为整型变量，其值在 0 到 2^62-1 之间，它也用于生成数据包加密所需的 nonce。通讯双方维护各自的 Packet Number 体系， 并且分为三个独立的上下文空间:

• Initial 空间：所有的 Initial 数据包的 Packet Number 均在这个上下文空间里；
• Handshake 空间：所有的握手数据包；
• 应用数据空间：所有的 0-RTT 和 1-RTT 包。

所谓的 Packet Number 空间，指得是一种上下文关系，在这个上下文关系里，数据包被处理, 被确认。数据包在不同的Packet Number Namespace有不同的加密等级，初始数据包只能使用初始数据包专用的密钥，也只能确认初始数据包。类似的， 握手包只能使用握手包专用的密钥，也只能确认握手数据包。

从 Initial 阶段进入 Handshake 阶段后， Initial 阶段使用的密钥就可以被丢弃了，0-RTT 和 1-RTT 共享同一个 Packet Number 空间，这样做是为了更容易实现这两类数据包的丢包处理算法。

在同一连接同一个 Packet Number 空间里，你不能复用包号，包号必须是单调递增的，当然，具体实现的时候草案并不强制要求每次都递增1， 你可以递增 20，30。当 Packet Number 达到 2^62 -1 时，发送方必须关闭该连接。

需要注意的是：在特定的包号空间里，有些帧是被禁止使用的(https://autumnquiche.github.io/RFC9000_Chinese_Translation/#12.4_Frames_and_Frame_Types)

• Padding帧、Ping帧和Crypto帧可以出现在任何数据包号空间中。
• 标志着QUIC层错误（类型为0x1c）的连接关闭帧可以出现在任何数据包号空间中。标志着应用错误（类型为0x1d）的连接关闭帧必须只能出现在应用数据空间中。
• ACK帧可以出现在任何数据包号空间中，但是只能确认在同一个数据包号空间中的数据包。0-RTT数据包不能包含ACK帧。
• 所有其他类型的帧必须只能出现在应用数据空间中。

连接之建立过程

传输参数定义

在连接建立期间，双端会对各自的传输参数作出验证声明，传输参数通过在quic_transport_parameters字段中定义，传输参数包括最大超时时间(max_idle_timeout)， 无状态重置令牌(stateless_reset_token), 最大udp有效载荷（max_udp_payload_size），初始最大数据量(initial_max_data)等,具体参数参考(https://autumnquiche.github.io/RFC9000_Chinese_Translation/#18_Transport_Parameter_Encoding)

同一个传输参数在特定的传输扩展中不能声明多次，一旦握手完成，由对端声明的传输参数就生效了

开启0-RTT，终端需要保存服务端传输参数的值及在连接上收到的任何会话票据（session ticket），终端也需要保存其他任何应用协议或加密握手所需要的信息。但是需要注意的是不是所有的传输参数都需要保存(因为部分参数不会在0-RTT建连期间起作用)， ack_delay_exponent、max_ack_delay、initial_source_connection_id等这些个参数的值不能被保存。

如果终端不支持某一些传输参数，那么必须忽略他(例如B定义了一个传输参数x, A不支持此参数，那么需要忽略他)

协商连接ID

当客户端发送初始包时，会生成不可预测值填充发送的初始包的目标连接ID字段。目标连接ID的长度必须至少8字节。客户端在一条连接上必须使用同一个目标连接ID，直到收到服务端发来的数据包为止。

客户端发送的首个初始数据包的目标连接ID字段用于确定初始数据包的包保护密钥。这些密钥在收到重试数据包后变更。(初始秘钥值是通过对值为0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a的盐和值为目标连接ID进行HKDF算法而得出）

在首次收到从服务端发来的初始数据包或重试数据包后，客户端将服务的提供的源连接ID作为后续发送数据包的目标连接ID，包括任何0-RTT包。这意味着客户端可能需要在连接建立阶段将目标连接ID字段的值变更两次：一次是响应服务端发来的重试数据包，一次是响应服务端发来的初始数据包

QUIC之连接迁移

TCP的连接标识是通过“源ip+源端口+目标ip+目标端口+协议”唯一五元组构成，当其中的任何一个变量改变，都会造成tcp的重新建连。而quic也有唯一标识，他是通过一个64位的Connection ID表示，当用户在WIFI和移动网络发生网络切换时，用户的IP和Port可能会发生改变，但是quic的Connection ID不会发生改变，因此无需重新建立连接，这种用户无感知的网络切换，叫做连接迁移。

探测帧（probing frames）：PATH_CHALLENGE、PATH_RESPONSE、NEW_CONNECTION_ID、PADDING，发起的包是探测包（probing packet）

非探测帧（non-probing frames）：除探测帧之外的是非探测帧，发起的包是非探测包（non-probing packet）

探测新路径

在发起连接之前，客户端会发起探测帧，校验新地址到对端是否可达，也就是路径验证，校验不通过表示该条路径不通，但不会关闭连接。

发起连接迁移

客户端发起非探测帧数据包给对端，从而实现连接迁移。新路径没有老路径的发送速率，所以新路径会重置拥塞控制和RTT相关配置。

响应连接

当对端收到非探测帧数据包时，意味着连接迁移成功。

QUIC之连接关闭

共有三种方法终止一个已建立的quic连接：

1. 空闲超时
2. 立即关闭
3. 无状态重置

空闲超时

每个终端会在传输参数中指定的最大空闲超时时间(max_idle_timeout)，如果某个连接持续空闲时间超过了两个终端宣告的max_idle_timeout中较小值，那么这个连接就会被静默关闭，并且它的状态会被丢弃。

当终端收到并且处理了一个来自对端的数据包时，终端需要重置它的空闲计时器。当正要发送ACK触发包时，如果自上一次接收并处理数据包后还没有发送过任何ACK触发包，那么终端也会重启它的空闲计时器。

如果终端正在等待响应数据但是没有或无法发送应用数据，那么终端可能需要发送ACK触发包以避免空闲超时。终端可以定期发送一个Ping帧，使得对端重置自己的空闲超时定时器。

立即关闭

终端可以发送连接关闭帧(CONNECTION_CLOSE)来终止连接，连接关闭帧会使所有的流都被立即关闭，当终端发起立即关闭帧后进入关闭状态，当终端收到连接关闭帧后立即进入排空状态(排空状态许多方面都跟关闭状态一致，但是处于排空状态的终端必须不发送任何数据包。一旦连接处于排空状态，就没有必要再保留数据包保护密钥了)

终端在收到连接关闭帧后在进入排空状态之前可以发送一个包含连接关闭帧的数据包。

处于关闭状态的连接在收到连接关闭帧后可以转化为排空状态

无状态重置

崩溃或中断可能造成对端持续向一个没有正常地维持连接的终端发送数据，终端可以在接收到一个它无法关联到某个活跃连接的数据包时发送无状态重置作为响应。

无状态重置不适合用来表明在活跃连接中出现的错误。想要传达致命的连接错误这一消息的终端在有能力的情况下必须使用连接关闭帧。

为了支持无状态重置，终端会签发一个无状态重置令牌，它是一个难以猜测的16字节长的值。如果对端后续收到了无状态重置，也就是一个以那个无状态重置令牌结尾的UDP数据报，那么对端将立即结束这条连接。

QUIC之不可靠传输

QUIC传输协议[RFC9000]为传输可靠的应用数据流提供了一个安全的、多路复用的连接。QUIC使用携带了多种类型帧的数据包传输数据，需要可靠传输的应用数据流使用 STREAM 帧发送。但是有些应用，尤其是需要传输实时数据的应用，更倾向于使用不可靠传输，QUIC为了实现不可靠传输，通过定义新的Datagram帧类型。

Datagram帧传输参数

1. QUIC在握手期间可以用传输参数(name=max_datagram_frame_size，value=0x20)来通告对端是否支持datagram帧，默认值为0表示不支持DATAGRAM帧，大于 0 的值表示端点支持 DATAGRAM 帧类型并且告诉对端自己可以接收datagram帧的最大长度。

2. 端点在握手期间（如果使用0-RTT，则是上一次握手期间），在未收到具有非零值的 max_datagram_frame_size 传输参数之前，不得发送 DATAGRAM 帧， 端点不得发送大于对端通告的 max_datagram_frame_size 长度的 DATAGRAM 帧，如果未收到是否支持datagram帧的通道而收到datagram帧，那么需要以PROTOCOL_VIOLATION类型错误而终止。

3. max_datagram_frame_size 传输参数可以是单向的，也就是可以单端使用。

Datagram帧的发送和接收处理

1. 当应用在QUIC连接上发送数据报时，QUIC将生成一个新的 DATAGRAM 帧并在第一个可用数据包中发送。该帧应该尽快投递并且可以与其他帧合并。当 QUIC 端点接收到一个有效的 DATAGRAM 帧时，应该立即传递给应用。

2. 与 STREAM 帧一样，DATAGRAM 帧包含应用数据，并且必须使用 0-RTT 或 1-RTT 密钥进行保护。

3. 虽然 DATAGRAM 帧在丢包检测时不会重传，但它们也是 ACK 触发帧，所以接收方应该支持延迟发送 ACK 帧以对接收到仅包含 DATAGRAM 帧的数据包做出响应，因为即使这些包短期内未被确认，发送方也不会采取任何行动。

4. 与任何 ACK 触发帧一样，当发送方怀疑仅包含 DATAGRAM 帧的数据包丢失时，它会发送探测包以引发更快的 ACK 确认。如果发送方检测到包含特定 DATAGRAM 帧的数据包可能已经丢失，则QUIC实现可以通知应用它认为数据报已丢失了。

5. 如果包含 DATAGRAM 帧的数据包被确认，则QUIC实现可以通知发送方，应用数据报已被成功发送和接收，需要注意的是，对 DATAGRAM 帧的确认仅表明接收方的传输层接收并处理了该帧，并不保证接收方的应用层成功处理了该数据。

6. DATAGRAM帧没有明确的流控信号且DATAGRAM帧不影响其他流的流量控制(也就是DATAGRAM帧不在stream的流量控制范围内)。

7. DATAGRAM 帧的拥塞控制属于连接级别，QUIC实现可以选择让应用指定一个发送过期时间，超过该时间，受拥塞控制的 DATAGRAM 帧应该被丢弃不传输。

MPQUIC实现多路径传输

多路径协商

1. 端点在握手期间需要使用传输参数(enable_multipath（实验使用0xbabf))来协商是否支持多路径，0表示禁用多路径。
2. 如果任何一个端点，该参数不存在或设置为 0，则端点必须回退到QUIC模式

路径的启动和关闭

1. 当协商多路径选项时，想要使用附加路径的客户端必须首先使用PATH_CHALLENGE 和 PATH_RESPONSE 帧启动地址验证过程。在新路径上接收到来自客户端的数据包后，如果服务器决定使用新路径，则服务器必须执行路径验证，除非它之前已经验证了该地址。

2. 如果验证成功，客户端可以在新路径上发送非探测的 1-RTT 数据包。服务端收到新路径上的非探测1-RTT数据包表示新路径可以使用，但是不能表示连接迁移到新路径。

3. 每个端点可以管理一组路径，如果端点想要关闭指定路径，应该通过PATH_ABANDON帧来终止路径，一旦路径被标记为“已放弃”，端点可以释放与该路径相关的资源，例如已使用的连接ID。

4. 当包含 PATH_ABANDON 帧的数据包对端被确认时，发送 PATH_ABANDON 帧的端点应该认为一条路径已被放弃。当释放该路径的资源时，端点应该为路径上使用的连接 ID 发送一个 RETIRE_CONNECTION_ID 帧，如果有的话。

5. PATH_ABANDON 帧的接收者不应立即释放其资源，而应等待接收到已使用的连接 ID的RETIRE_CONNECTION_ID 帧或 3 个 RTO 的 RETIRE_CONNECTION_ID 帧。

6. PATH_ABANDON 帧向接收对等方指示发送方不再打算在该路径上发送任何数据包，PATH_ABANDON 帧的接收者也可以发送一个 PATH_ABANDON 帧来表示它自己愿意不再在这条路径上发送任何数据包。

7. PATH_ABANDON 帧可以在任何路径上发送，而不仅仅是在要关闭的路径上发送。如果在废弃路径上发送并被认为丢失的可重传帧应该在其他路径上重传。

8. QUIC中如果只有一条路径存活并且服务端收到了PATH_ABANDON帧，那么服务端应该发送CONNECTION_CLOSE 帧并进入关闭状态，如果客户端在唯一一条存活路径上收到PATH_ABANDON 帧，它可能会尝试打开新路径（如果可用），并且仅在路径验证失败或从服务器接收到 CONNECTION_CLOSE 帧时才启动连接关闭。

9. 在路径验证过程中，端点可以通过不发送PATH_RESPONSE帧来拒绝对等方发起的新路径建立。

路径的状态管理

端点使用 PATH_STATUS 帧来通知对等方应该按照这些帧表达的偏好发送数据包。需要注意的是，端点可能不遵循对等方的通告

PATH_STATUS 帧描述了路径的两种状态：

• 将路径标记为“可用”，即允许在当前路径上发送流量。
• 将路径标记为“备用”，即建议如果另一条路径可用，则不应在该路径上发送流量。

端点使用 PATH_STATUS 帧中的路径标识符字段来标识哪个路径的状态将被更改。PATH_STATUS 帧可以通过不同的路径发送。如果端点收到的路径状态帧会使所有路径都不可用，那么端点可以忽略PATH_STATUS帧。

PATH_STATUS利用PATH_ID来标识它希望改变哪个路径的状态。另外利用path-status-seq-num来标记PATH_STATUS的有效性：

1. 这是个递增的序号，只有收到更高序号的PATH_STATUS才判定为有效
2. 不同路径上的序号不互相干涉，也就是说如果收到path-1上的高序号，不会去影响path2的状态。

路径的拥塞控制

1. 每个路径需要为每个路径都维护一个独立的拥塞状态
2. mpquic连接和普通quic连接并不使用统一的拥塞控制机制，因为这可能导致带宽分配不均，带宽会被倾向分配给多路径的connection。
3. 协议推荐在mpquic下使用LIA拥塞控制机制：RFC6356

参考文档

• RFC9000中译：QUIC传输协议
• QUIC-TLS协议中文版（rfc9001）
• MP-QUIC协议草案
• 多路径调度器草案
• https://github.com/alibaba/xquic)
• 深入 HTTP/3（一）｜从 QUIC 链接的建立与关闭看协议的演进
• 深入 HTTP/3（2）｜不那么 Boring 的 SSL
• 揭秘QUIC的性能与安全
• 积跬步至千里：QUIC 协议在蚂蚁集团落地之综述
• 提速 30%！腾讯TQUIC 网络传输协议
• 淘宝多路径 quic 服务
• TLS1.2 和 TLS1.3的简要区别
• https原理–ECDHE密钥协商算法

负载均衡(Load Balance)的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上，让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时，还可以避免资源浪费。负载均衡的原理就是当用户的请求到达前端负载均衡器(Director Server)时，通过设置好的调度算法，智能均衡的将请求分发到后端真正服务器上(Real Server)。根据请求类型的不同可以将负载均衡分为四层负载均衡(L4)和七层负载均衡(L7)， 常见的负载均衡器包括LVS，Nginx, HAProxy等。

LVS概述

LVS是Linux Virtual Server的简称， 也就是 Linux 虚拟服务器，工作在 OSI 模型的传输层，即四层负载均衡。LVS主要由两部分组成，包括ipvs和ipvsadm。

• ipvs(ip virtual server)：工作在内核空间，是真正生效实现调度的代码。
• ipvsadm：工作在用户空间，叫 ipvsadm，负责为 ipvs 内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)

LVS 基本工作原理

LVS的底层是利用NETIFILTER的钩子能力：

1. 当用户向负载均衡调度器（Director Server）发起请求，调度器将请求发往至内核空间
2. PREROUTING 链首先会接收到用户请求，判断目标 IP 确定是本机 IP，将数据包发往 INPUT 链
3. IPVS 是工作在 INPUT 链上的，当用户请求到达 INPUT 时，IPVS 会将用户请求和自己已定义好的集群服务进行比对，如果用户请求的就是定义的集群服务，那么此时 IPVS 会强行修改数据包里的目标 IP 地址及端口，并将新的数据包发往 POSTROUTING 链
4. POSTROUTING 链接收数据包后发现目标 IP 地址刚好是自己的后端服务器，那么此时通过选路，将数据包最终发送给后端的服务器

LVS 调度算法

前言说到负载均衡器原理是根据负载均衡算法把请求转发到后端真实服务器上。LVS作为四层负载均衡器，针对不同的网络服务需求和服务器配置，LVS调度器实现了多种负载均衡调度算法，主要包括如下：

1. 轮询调度 rr（Round Robin）：这种算法是最简单的，就是按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是简单。轮询算法假设所有的服务器处理请求的能力都是一样的，调度器会将所有的请求平均分配给每个真实服务器，不管后端 RS 配置和处理能力，非常均衡地分发下去。

2. 加权轮叫 wrr（Weighted Round Robin）：这种算法比 rr 的算法多了一个权重的概念，可以给 RS 设置权重，权重越高，那么分发的请求数越多，权重的取值范围 0 – 100。主要是对 rr 算法的一种优化和补充，LVS 会考虑每台服务器的性能，并给每台服务器添加要给权值，如果服务器 A 的权值为 1，服务器 B 的权值为 2，则调度到服务器 B 的请求会是服务器 A 的 2 倍。权值越高的服务器，处理的请求越多。

3. 最少链接 lc（Least Connections）：这个算法会根据后端 RS 的连接数来决定把请求分发给谁，比如 RS1 连接数比 RS2 连接数少，那么请求就优先发给 RS1。

4. 加权最少链接 wlc（Weighted Least Connections）：这个算法比最少链接 lc算法多了一个权重的概念。

5. 基于局部性的最少链接 lblc（Locality-Based Least Connections）：这个算法是针对目标 IP 地址的负载均衡，目前主要用于 Cache 集群系统。该算法根据请求的目标 IP 地址找出该目标 IP 地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用 “最少链接” 的原则选出一个可用的服务 器，将请求发送到该服务器。

6. 复杂的基于局部性最少的连接算法 lblcr（Locality-Based Least Connections with Replication）*：这个算法也是针对目标 IP 地址的负载均衡，目前主要用于 Cache 集群系统。它与 LBLC 算法的不同之处是它要维护从一个 目标 IP 地址到一组服务器的映射，而 LBLC 算法维护从一个目标 IP 地址到一台服务器的映射。该算法根据请求的目标 IP 地址找出该目标 IP 地址对应的服务 器组，按 “最小连接” 原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按 “最小连接” 原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。

7. 目标地址散列 dh（Destination Hashing）：这个算法根据请求的目标 IP 地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

8. 源地址散列 sh（Source Hashing）：这个调度算法根据请求的源 IP 地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

LVS 工作模式

根据负载均衡器对数据包的处理方式分类，LVS支持三种工作模式，分别为NAT模式，DR模式以及TUN模式。原生的LVS工作模式不支持FULLNAT，FULLNAT模式需要自己重新编译LVS。在介绍LVS工作模式之前有必要先解释下相关名词：

• DS：Director Server，指的是前端负载均衡器节点。
• RS：Real Server，后端真实的工作服务器。
• VIP：向外部直接面向用户请求，作为用户请求的目标的 IP 地址。
• DIP：Director Server IP，主要用于和内部主机通讯的 IP 地址。
• RIP：Real Server IP，后端服务器的 IP 地址。
• CIP：Client IP，访问客户端的 IP 地址。

LVS NAT模式

LVS NAT的工作原理

1. 当用户请求到达 Director Server，此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源 IP 为 CIP，目标 IP 为 VIP
2. PREROUTING 检查发现数据包的目标 IP 是本机，将数据包送至 INPUT 链
3. IPVS 比对数据包请求的服务是否为集群服务，若是，修改数据包的目标 IP 地址为后端服务器 IP，然后将数据包发至 POSTROUTING 链。 此时报文的源 IP 为 CIP，目标 IP 为 RIP
4. POSTROUTING 链通过选路，将数据包发送给 Real Server
5. Real Server 比对发现目标为自己的 IP，开始构建响应报文发回给 Director Server。 此时报文的源 IP 为 RIP，目标 IP 为 CIP
6. Director Server 在响应客户端前，此时会将源 IP 地址修改为自己的 VIP 地址，然后响应给客户端。 此时报文的源 IP 为 VIP，目标 IP 为 CIP

LVS NAT模式特点

• RS 应该使用私有地址，RS 的网关必须指向 DIP。
• DIP 和 RIP 必须在同一个网段内。
• 支持端口映射。
• RS 可以使用任意操作系统。
• 请求和响应报文都需要经过 Director Server，高负载场景中，Director Server 易成为性能瓶颈。

LVS NAT模式实践

一、使用Docker模拟(适用于没虚拟机的情况)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# 1. 起两个nginx容器，分别是 
[root@localhost ~]# docker run -d -p 8000:8000 --name first -t jwilder/whoami
[root@localhost ~]# docker run -d -p 8001:8000 --name second -t jwilder/whoami

# 2. 获取容器的IP地址
[root@localhost ~]# docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' first
[root@localhost ~]# docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' second

# 执行curl获取结果(ip为步骤二返回的结果)
[root@localhost ~]# curl 172.17.0.2:8000
[root@localhost ~]# curl 172.17.0.3:8000

# 创建ipvs规则
[root@localhost ~]# ipvsadm -A -t 192.168.56.102:80 -s rr
[root@localhost ~]# ipvsadm -a -t 192.168.56.102:80 -r 172.17.0.2:8000 -m
[root@localhost ~]# ipvsadm -a -t 192.168.56.102:80 -r 172.17.0.3:8000 -m
[root@localhost ~]# ipvsadm -Ln
TCP  192.168.56.102:80 rr
  -> 172.17.0.2:8000              Masq    1      0          0         
  -> 172.17.0.3:8000              Masq    1      0          0   
# 验证是否生效(返回结果一次是A，一次是B)
[root@localhost ~]# curl 192.168.56.102
I'm fdb291a03b87
[root@localhost ~]# curl 192.168.56.102
I'm 9799eb62225c

二、使用虚拟机模拟

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 前置条件：
#   1. 虚拟机网段一致
#   2. 服务器2，3上部署了http服务器,且内容不一致

# 在虚拟机1上执行， (本机IP为192.168.56.101)
ipvsadm -A -t 192.168.57.4:80 -s rr
ipvsadm -a -t 192.168.57.4:80 -r 192.168.56.102:80 -m
ipvsadm -a -t 192.168.57.4:80 -r 192.168.56.104:80 -m

## 开启ip forward
echo 1 >/proc/sys/net/ipv4/ip_forward

# 在虚拟机2，3上执行，(本机IP为192.168.56.102， 192.168.56.104), 如果默认路由不设置为虚拟机1，发现是访问不通的
ip route del default
ip route add default via 192.168.56.101

# 检查是否能够访问, 在虚拟机1上执行curl
curl 192.168.57.4

LVS DR模式

DR（Direct Routing 直接路由模式）模式时 LVS 调度器只接收客户发来的请求并将请求转发给后端服务器，后端服务器处理请求后直接把内容直接响应给客户，而不用再次经过 LVS 调度器。LVS 只需要将网络帧的 MAC 地址修改为某一台后端服务器 RS 的 MAC，该包就会被转发到相应的 RS 处理，注意此时的源 IP 和目标 IP 都没变。RS 收到 LVS 转发来的包时，链路层发现 MAC 是自己的，到上面的网络层，发现 IP 也是自己的，于是这个包被合法地接受，RS 感知不到前面有 LVS 的存在。而当 RS 返回响应时，只要直接向源 IP（即用户的 IP）返回即可，不再经过 LVS。

LVS DR模式工作原理

1. 当用户请求到达 Director Server，此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源 IP 为 CIP，目标 IP 为 VIP。
2. PREROUTING 检查发现数据包的目标 IP 是本机，将数据包送至 INPUT 链。
3. IPVS 比对数据包请求的服务是否为集群服务，若是，将请求报文中的源 MAC 地址修改为 DIP 的 MAC 地址，将目标 MAC 地址修改 RIP 的 MAC 地址，然后将数据包发至 POSTROUTING 链。 此时的源 IP 和目的 IP 均未修改，仅修改了源 MAC 地址为 DIP 的 MAC 地址，目标 MAC 地址为 RIP 的 MAC 地址。
4. 由于 DS 和 RS 在同一个网络中，所以是通过二层来传输。POSTROUTING 链检查目标 MAC 地址为 RIP 的 MAC 地址，那么此时数据包将会发至 Real Server。
5. RS 发现请求报文的 MAC 地址是自己的 MAC 地址，就接收此报文。处理完成之后，将响应报文通过 lo 接口传送给 eth0 网卡然后向外发出。 此时的源 IP 地址为 VIP，目标 IP 为 CIP。
6. 响应报文最终送达至客户端。

LVS DR模式特点

• 保证前端路由将目标地址为 VIP 报文统统发给 Director Server，而不是 RS。
• RS 可以使用私有地址；也可以是公网地址，如果使用公网地址，此时可以通过互联网对 RIP 进行直接访问。
• VIP与DIP，RIP可以不在同一网段中.
• 所有的请求报文经由 Director Server，但响应报文必须不能进过 Director Server。
• 不支持地址转换，也不支持端口映射。
• RS 可以是大多数常见的操作系统。
• RS 的网关绝不允许指向 DIP（因为我们不允许他经过 Director Server）。
• RS 上的 lo 接口配置 VIP 的 IP 地址。
• RS 和 DS 必须在同一个物理网络中(同一机房中)。

LVS DR模式的相关问题

为了解决保证前端路由将目标地址为 VIP 报文统统发给 Director Server，而不是 RS。的问题一般有如下解决方案：

• 在前端路由器做静态地址路由绑定，将对于 VIP 的地址仅路由到 Director Server。但用户未必有路由操作权限，因为有可能是运营商提供的，所以这个方法未必实用。
• arptables：在 arp 的层次上实现在 ARP 解析时做防火墙规则，过滤 RS 响应 ARP 请求。这是由 iptables 提供的。
• 修改 RS 上内核参数（arp_ignore 和 arp_announce）将 RS 上的 VIP 配置在 lo 接口的别名上，并限制其不能响应对 VIP 地址解析请求。

关于arp_ignore和arp_announce

arp_ignore：定义接收 ARP 请求时的响应级别

• 0：响应任意网卡上接收到的对本机 IP 地址的 ARP 请求（包括环回网卡），不论目的 IP 地址是否在接收网卡上
• 1：只响应目的 IP 地址为接收网卡地址的 ARP 请求
• 2：只响应目的 IP 地址为接收网卡地址的 ARP 请求，且 ARP 请求的源 IP 地址必须和接收网卡的地址在同网段

1
2
3
4
5
6
7
8
9
10
11
12
13
14

arp_ignore - INTEGER
    Define different modes for sending replies in response to
    received ARP requests that resolve local target IP addresses:
        0 - (default): reply for any local target IP address, configured on any interface
        1 - reply only if the target IP address is local address configured on the incoming interface
        2 - reply only if the target IP address is local address configured on the incoming interface
            and both with the sender's IP address are part from same subnet on this interface
        3 - do not reply for local addresses configured with scope host,
            only resolutions for global and link addresses are replied
        4-7 - reserved
        8 - do not reply for all local addresses

    The max value from conf/{all,interface}/arp_ignore is used
    when ARP request is received on the {interface}

arp_announce：定义将自己地址向外通告时的通告级别

• 0：允许任意网卡上的任意地址向外通告
• 1：尽量仅向目标网络通告与其网络匹配的地址
• 2：仅向与本地接口上地址匹配的网络进行通告

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

arp_announce - INTEGER
    Define different restriction levels for announcing the local source IP address
    from IP packets in ARP requests sent on interface:
        0 - (default) Use any local address, configured on any interface
        1 - Try to avoid local addresses that are not in the target's subnet for this interface.
            This mode is useful when target hosts reachable via this interface require the source IP
            address in ARP requests to be part of their logical network configured on the receiving
            interface. When we generate the request we will check all our subnets that include the
            target IP and will preserve the source address if it is from such subnet.
            If there is no such subnet we select source address according to the rules for level 2.
        2 - Always use the best local address for this target. In this mode we ignore the source
            address in the IP packet and try to select local address that we prefer for talks
            with the target host. Such local address is selected by looking for primary IP addresses
            on all our subnets on the outgoing interface that include the target IP address.
            If no suitable local address is found we select the first local address we have on the
            outgoing interface or on all other interfaces, with the hope we will receive reply
            for our request and even sometimes no matter the source IP address we announce.

    The max value from conf/{all,interface}/arp_announce is used.

    Increasing the restriction level gives more chance for receiving answer from the resolved target
    while decreasing the level announces more valid sender's information.

LVS DR模式实践

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 前置条件：
#   1. 虚拟机网段一致
#   2. 服务器2，3上部署了http服务器,且内容不一致

# 在虚拟机1上执行， (本机IP为192.168.56.101)
ip addr add 192.168.56.200/32 dev enp0s8
ipvsadm -A -t 192.168.56.200:80 -s wrr
ipvsadm -a -t 192.168.56.200:80 -r 192.168.56.102:80 -g -w 1
ipvsadm -a -t 192.168.56.200:80 -r 192.168.56.104:80 -g -w 3

## 开启ip forward
echo 1 >/proc/sys/net/ipv4/ip_forward

# 在虚拟机2，3上执行，(本机IP为192.168.56.102， 192.168.56.104)
ip addr add 192.168.56.200/32 dev lo
ip route add 192.168.56.200 dev lo
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce

# 检查是否能够访问, 在外部主机上执行curl
curl 192.168.56.200

LVS TUN 模式

TUN工作在三层，TAP工作在二层

LVS TUN模式工作原理

1. 当用户请求到达 Director Server，此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源 IP 为 CIP，目标 IP 为 VIP。
2. PREROUTING 检查发现数据包的目标 IP 是本机，将数据包送至 INPUT 链。
3. IPVS 比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层 IP 报文，封装源 IP 为 DIP，目标 IP 为 RIP。然后发至 POSTROUTING 链。 此时源 IP 为 DIP，目标 IP 为 RIP。
4. POSTROUTING 链根据最新封装的 IP 报文，将数据包发至 RS（因为在外层封装多了一层 IP 首部，所以可以理解为此时通过隧道传输）。 此时源 IP 为 DIP，目标 IP 为 RIP。
5. RS 接收到报文后发现是自己的 IP 地址，就将报文接收下来，拆除掉最外层的 IP 后，会发现里面还有一层 IP 首部，而且目标是自己的 lo 接口 VIP，那么此时 RS 开始处理此请求，处理完成之后，通过 lo 接口送给 eth0 网卡，然后向外传递。 此时的源 IP 地址为 VIP，目标 IP 为 CIP。
6. 响应报文最终送达至客户端。

LVS TUN模式特点

• 不改变请求数据包，而是在请求数据包上新增一层 IP 首部信息。因此负载均衡器不能对端口进行转发，但可以和真实服务器不在同一局域网内，且真实服务器需要支持能够解析两层 IP 首部信息，即需要支持“IP Tunneling”或“IP Encapsulation”协议
• 真实服务器中的 VIP，只能被自己 “看见”，其他设备不可知。因此 VIP 必须绑定在真实服务器的 lo 网卡上，并且不允许将此网卡信息经过 ARP 协议对外通告
• 请求的数据包经过负载均衡器后，直接由真实服务器返回给客户端，响应数据包不需要再经过负载均衡器
• RS 的网关不会也不可能指向 DIP。

LVS TUN模式实践

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# 前置条件：
#   2. 服务器2，3上部署了http服务器,且内容不一致

# 在虚拟机1上执行， (本机IP为192.168.56.101)
ip addr add 192.168.56.210/32 dev enp0s8
ipvsadm -A -t 192.168.56.210:80 -s rr
ipvsadm -a -t 192.168.56.210:80 -r 192.168.56.102:80 -i
ipvsadm -a -t 192.168.56.210:80 -r 192.168.56.104:80 -i

# 在虚拟机2，3上执行，(本机IP为192.168.56.102， 192.168.56.104)
modprobe ipip // 启用ipip
lsmod | grep ipip
ip addr add 192.168.56.210/32 dev tunl0
ip link set tunl0 up
ip route add 192.168.56.210 dev tunl0

echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 >/proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 >/proc/sys/net/ipv4/conf/all/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/tunl0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

# 检查是否能够访问, 在外部主机上执行curl
curl 192.168.56.210

LVS FULLNAT模式

LVS NAT, DR模式中，RS跟DS必须在同一个VLAN中，当集群规模较小时，使用 NAT、DR 模式都是没有问题的，当集群内有几十台以上时，那么这些服务器通常都不在同一个 VLAN/网段 内了。这时，必须再研发出一种能支持跨 VLAN/网段 通信的模式，FULLNAT 模式就是为了解决这个问题而生的。

LVS FullNAT 模式几乎和 LVS NAT 模式相同，不同之处即是：引入 Local Address（内网 IP 地址）。CIP->VIP 转换换为 LIP->RIP，而 LIP 和 RIP 均为 IDC 内网 IP，因此可以跨 VLAN 通讯。LVS原生模式不支持FULLNAT，因此需要自己手动编译内核～

LVS FULLNAT内核编译

注意：内核编译的内核包需要跟自己的操作系统内核版本对应上(大版本对应上~)，暂时未找到centos7对应的内核包在哪儿。

本机的内核版本为：2.6.32-220

1. 安装依赖

1
2
3
4
5
6

yum -y install elfutils-devel.x86_64 audit-libs-devel.x86_64
yum -y install rpmdevtools yum-utils
yum -y install redhat-rpm-config
yum -y install gcc xmlto patchutils asciidoc zlib-devel binutils-devel newt-devel python-devel hmaccalc perl-ExtUtils-Embed.x86_64
yum -y install rng-tools 随机数生成器
yum -y install bison

2. 下载内核包，ipvs补丁包

1
2
3
4

# 内核包
wget ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6.32-220.23.1.el6.src.rpm
# lvs fullnat包
wget http://kb.linuxvirtualserver.org/images/a/a5/Lvs-fullnat-synproxy.tar.gz

3. 生成内核代码

1
2
3
4
5
6
7
8
9

rpm -ivh kernel-2.6.32-220.23.1.el6.src.rpm

# 生成随机数(一定要生成随机数，否则rpmbuild的时候会卡住)
rngd -r /dev/urandom   

# rpmbuild -bp kernel.spec
cd ~/rpmbuild/SPECS

rpmbuild -bp --target=$(uname -m) kernel.spec

4. 打 LVS补丁

1
2
3
4
5

tar -zxvf Lvs-fullnat-synproxy.tar.gz

cp ~/lvs-fullnat-synproxy/lvs-2.6.32-220.23.1.el6.patch ~/rpmbuild/BUILD/kernel-2.6.32-220.23.1.el6/linux-2.6.32-220.23.1.el6.x86_64 && cd $_

patch -p1 < lvs-2.6.32-220.23.1.el6.patch

5. 编译内核

1
2
3
4
5

# 最好不要重新修改内核版本(遇到过改了内核版本后，编译没问题，重启后触发Kernel panic – not syncing: Attempted to kill init的问题)
# 使用-j 加快内核编译速度
make -j16
make modules_install
make install

6. 重启操作系统

1
2
3

reboot

# 重启后发现系统版本已经改变了， Linux localhost.localdomain 2.6.32 #2 SMP Thu Dec 30 03:38:53 EST 2021 x86_64 x86_64 x86_64 GNU/Linux

7. 编译ipvsadm, keepalived等工具

1
2
3
4
5
6
7
8
9
10
11
12
13

cd ~/lvs-fullnat-synproxy && tar -zxvf lvs-tools.tar.gz

# 编译 keepalived
cd ~/lvs-fullnat-synproxy/tools/keepalived
./configure --with-kernel-dir="/lib/modules/`uname -r`/build" && make && make install
 
# 编译 ipvsadm
cd ~/lvs-fullnat-synproxy/tools/ipvsadm
make && make install

# 编译 quaage
cd ~/lvs-fullnat-synproxy/tools/quagga
./configure --disable-ripd --disable-ripngd --disable-bgpd --disable-watchquagga --disable-doc  --enable-user=root --enable-vty-group=root --enable-group=root --enable-zebra --localstatedir=/var/run/quagga && make && make install

8. 验证是否编译成功

1
2
3
4
5
6

# 输入 ipvsadm -h 可以看到有fullnat 模式

  --gatewaying   -g                   gatewaying (direct routing) (default)
  --ipip         -i                   ipip encapsulation (tunneling)
  --fullnat      -b                   fullnat mode
  --masquerading -m                   masquerading (NAT)

LVS FULLNAT模式工作原理

1. 当用户请求到达 Director Server，此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源 IP 为 CIP，目标 IP 为 VIP
2. PREROUTING 检查发现数据包的目标 IP 是本机，将数据包送至 INPUT 链
3. IPVS 比对数据包请求的服务是否为集群服务，若是，修改数据包的源IP地址分发服务器IP，目标 IP 地址为后端服务器 IP，然后将数据包发至 POSTROUTING 链。 此时报文的源 IP 为 DIP，目标 IP 为 RIP
4. POSTROUTING 链通过选路，将数据包发送给 Real Server
5. Real Server 比对发现目标为自己的 IP，开始构建响应报文发回给 Director Server。 此时报文的源 IP 为 RIP，目标 IP 为 DIP
6. Director Server 在响应客户端前，此时会将源 IP 地址修改为自己的 VIP 地址，然后响应给客户端。 此时报文的源 IP 为 VIP，目标 IP 为 CIP

LVS FULLNAT模式实践

1
2
3
4
5
6
7
8
9
10

# 虚拟机4的IP地址为192.168.58.100， 虚拟机2，3的IP地址为192.168.56.102， 192.168.56.104, 在虚拟机上执行：
ip addr add 192.168.58.200/32 dev eth1

ipvsadm -A -t 192.168.58.200:80 -s wrr
ipvsadm -a -t 192.168.58.200:80 -r 192.168.56.102:80 -b -w 2
ipvsadm -a -t 192.168.58.200:80 -r 192.168.56.104:80 -b -w 1
ipvsadm -P -t 192.168.58.200:80 -z 192.168.58.100

# 集群外执行curl, 验证是否成功
curl 192.168.56.200

参考文档

• LVS 负载均衡原理及安装配置详解 // 推荐阅读
• LVS 原理介绍和配置实践 // 推荐阅读
• 深入浅出 LVS 负载均衡系列（一）：NAT、FULLNAT 模型原理 //这系列文章不错
• 深入浅出 LVS 负载均衡系列（二）：DR、TUN 模型原理 //这系列文章不错
• 深入浅出 LVS 负载均衡（三）实操 NAT、DR 模型 //这系列文章不错
• LVS FULLNAT 实战 // lvs fullnat 编译，样例
• IPVS FULLNAT and SYNPROXY // 编译 lvs fullnat
• LVS/fullnat模式（内核编译）

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment

Go 语言作为一个原生支持用户态进程（Goroutine）的语言，当提到并发编程、多线程编程时，往往都离不开锁这一概念。锁是一种并发编程中的同步原语（Synchronization Primitives），它能保证多个 Goroutine 在访问同一片内存时不会出现竞争条件（Race condition）等问题。go语言在Sync包中提供了用于同步的一些基本原语，包括常见的sync.Mutex、sync.RWMutex、sync.WaitGroup、sync.Once 和 sync.Cond：

前提知识

悲观锁与乐观锁

悲观锁是一种悲观思想，它总认为最坏的情况可能会出现，它认为数据很可能会被其他人所修改，不管读还是写，悲观锁在执行操作之前都先上锁。

对读对写都需要加锁导致性能低，所以悲观锁用的机会不多。但是在多写的情况下，还是有机会使用悲观锁的，因为乐观锁遇到写不一致的情况下会一直重试，会浪费更多的时间。

乐观锁的思想与悲观锁的思想相反，它总认为资源和数据不会被别人所修改，所以读取不会上锁，但是乐观锁在进行写入操作的时候会判断当前数据是否被修改过。乐观锁的实现方案主要包含CAS和版本号机制。乐观锁适用于多读的场景，可以提高吞吐量。

CAS即Compare And Swap（比较与交换），是一种有名的无锁算法。即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步。CAS涉及三个关系：指向内存一块区域的指针V、旧值A和将要写入的新值B。CAS实现的乐观锁会带来ABA问题，同时整个乐观锁在遇到数据不一致的情况下会触发等待、重试机制，这对性能的影响较大。

版本号机制是通过一个版本号version来实现版本控制。

自旋锁

之前介绍的CAS就是自旋锁的一种。同一时刻只能有一个线程获取到锁，没有获取到锁的线程通常有两种处理方式：

• 一直循环等待判断该资源是否已经释放锁，这种锁叫做自旋锁，它不用将线程阻塞起来(NON-BLOCKING)；
• 把自己阻塞起来，等待重新调度请求，这种是互斥锁。

自旋锁的原理比较简单，如果持有锁的线程能在短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞状态，它们只需要等一等(自旋)，等到持有锁的线程释放锁之后即可获取，这样就避免了用户进程和内核切换的消耗。

但是如果长时间上锁的话，自旋锁会非常耗费性能，它阻止了其他线程的运行和调度。线程持有锁的时间越长，则持有该锁的线程将被OS调度程序中断的风险越大。如果发生中断情况，那么其他线程将保持旋转状态(反复尝试获取锁)，而持有该锁的线程并不打算释放锁，这样导致的是结果是无限期推迟，直到持有锁的线程可以完成并释放它为止。

解决上面这种情况一个很好的方式是给自旋锁设定一个自旋时间，等时间一到立即释放自旋锁。自旋锁的目的是占着CPU资源不进行释放，等到获取锁立即进行处理。

golang锁的实现

Golang的Mutex其实是在不断改进的，到目前为止Mutex经历的四个阶段的改进，具体可以参考链接二中大佬的博客。

Go 语言的 sync.Mutex 由两个字段 state 和 sema 组成。其中 state 表示当前互斥锁的状态，而 sema 是用于控制锁状态的信号量。

1
2
3
4

type Mutex struct {
state int32
sema  uint32
}

其中state的最低三位mutexLocked, mutexWoken, mutexStarving表示锁的三种状态：

• mutexLocked — 表示互斥锁的锁定状态；
• mutexWoken — 表示从正常模式被从唤醒；
• mutexStarving — 当前的互斥锁进入饥饿状态；
• waitersCount — 当前互斥锁上等待的 Goroutine 个数；

互斥锁的加锁过程比较复杂，它涉及自旋、信号量以及调度等概念：

• 如果互斥锁处于初始化状态，会通过置位 mutexLocked 加锁；
• 如果互斥锁处于 mutexLocked 状态并且在普通模式下工作，会进入自旋，执行 30 次 PAUSE 指令消耗 CPU 时间等待锁的释放；
• 如果当前 Goroutine 等待锁的时间超过了 1ms，互斥锁就会切换到饥饿模式；
• 互斥锁在正常情况下会通过 runtime.sync_runtime_SemacquireMutex 将尝试获取锁的 Goroutine 切换至休眠状态，等待锁的持有者唤醒；
• 如果当前 Goroutine 是互斥锁上的最后一个等待的协程或者等待的时间小于 1ms，那么它会将互斥锁切换回正常模式；

互斥锁的解锁过程与之相比就比较简单，其代码行数不多、逻辑清晰，也比较容易理解：

• 当互斥锁已经被解锁时，调用 sync.Mutex.Unlock 会直接抛出异常；
• 当互斥锁处于饥饿模式时，将锁的所有权交给队列中的下一个等待者，等待者会负责设置 mutexLocked 标志位；
• 当互斥锁处于普通模式时，如果没有 Goroutine 等待锁的释放或者已经有被唤醒的 Goroutine 获得了锁，会直接返回；在其他情况下会通过 sync.runtime_Semrelease 唤醒对应的 Goroutine；

死锁

​ 死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。

​ 例如：两个线程A、B各自持有一个无法共享的资源，并且他们都需要获取对方现在持有的资源才能进行下一步，但是他们又必须等对方释放了才能去获取，于是A等待B，B也在等待A。如此这般，死锁就产生了。

产生死锁的条件及预防死锁

死锁的产生必须具备如下四个必要条件：

1. 互斥条件：资源不能被共享，只能由某一个进程使用
2. 请求和保持: 已经得到资源的进程可以再次申请新的资源。
3. 不可剥夺条件: 已经分配的资源不能从相应的进程中被强制地剥夺。
4. 循环等待条件：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。

这四个条件太抽象了，现在就以一个例子说明：

​ 两个线程各自持有一个无法共享(互斥条件)的资源，并且他们都需要获取（请求与保持条件）对方现在持有的资源才能进行下一步，但是他们又必须等对方释放了才能去获取(不可剥夺条件)，于是A等待B，B也在等待A（环路等待条件）。如此这般，死锁就产生了。

要预防死锁，只需要破坏四个必要条件中的一个或多个，使死锁永远无法满足即可。

参考文档

• https://draveness.me/golang/docs/part3-runtime/ch06-concurrency/golang-sync-primitives/#cond // 面向信仰编程，这文章也挺不错的~
• https://nxw.name/2021/golang-mutexde-shi-xian-yuan-li-1ef30cc7 // 这篇文章值得好好看
• https://cloud.tencent.com/developer/article/1493418 // 死锁的产生条件
• https://segmentfault.com/a/1190000039712353 // 这文章也不错

云原生（Cloud Native）是一套技术体系和方法论，它由2个词组成，云（Cloud）和原生（Native）。云（Cloud）表示应用程序位于云中，而不是传统的数据中心；原生（Native）表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳状态运行，充分利用和发挥云平台的弹性和分布式优势。

云原生的技术要素

根据CNCF的定义，CNCF 将不可变基础设施、微服务、声明式 API、容器和服务网格列为云原生架构的技术块。

不可变基础设施

不可变基础设施意味着用于托管云原生应用程序的服务器在部署后保持不变。如果应用程序需要更多计算资源，则会丢弃旧服务器，并将应用程序移至新的高性能服务器。通过避免手动升级，不可变基础设施使云原生部署成为一个可预测的过程。

微服务

微服务是小型的独立软件组件，它们作为完整的云原生软件共同运行。每个微服务都侧重于一个小而具体的问题。微服务是松散耦合的，这意味着它们是相互通信的独立软件组件。开发人员通过处理单个微服务来更改应用程序。这样，即使一个微服务出现故障，应用程序仍能继续运行。

申明式API

应用程序编程接口（API）是两个或多个软件程序用来交换信息的方法。云原生系统使用 API 将松散耦合的微服务整合在一起。API 会告诉您微服务想要什么数据以及它能给您带来什么结果，而不是指定实现结果的步骤。

服务网格

服务网格是云基础设施中的一个软件层，用于管理多个微服务之间的通信。开发人员使用服务网格来引入其他功能，而无需在应用程序中编写新代码。

容器

容器是云原生应用程序中最小的计算单元。它们是将微服务代码和其他必需文件打包在云原生系统中的软件组件。通过容器化微服务，云原生应用程序独立于底层操作系统和硬件运行。这意味着软件开发人员可以在本地、云基础设施或混合云上部署云原生应用程序。 开发人员使用容器将微服务与其各自的依赖项（例如主应用程序运行所需的资源文件、库和脚本）打包。

参考文档

• 云原生之容器安全实践 // 美团容器安全实践，说的不错
• 什么是云原生？ // aws 关于云原生的定义
• 云原生的定义

常见的垃圾回收算法

参考文档

• golang垃圾回收gc // 推荐阅读此大佬的所有go文章，写得针不戳
• Golang GC 垃圾回收机制详解 // 对常见的gc做了说明
• 万字长文深入浅出 Golang Runtime //之前go夜读有看到分享，说的贼好

Go语言内置运行时(Runtime), 抛弃了传统的内存分配方式，改为自主管理。这样可以自主地实现更好的内存使用模式，比如内存池、预分配等等。这样，不会每次内存分配都需要进行系统调用。

Golang运行时的内存分配算法主要源自 Google 为 C 语言开发的TCMalloc算法，全称Thread-Caching Malloc。核心思想就是把内存分为多级管理，从而降低锁的粒度。它将可用的堆内存采用二级分配的方式进行管理：每个线程都会自行维护一个独立的内存池，进行内存分配时优先从该内存池中分配，当内存池不足时才会向全局内存池申请，以避免不同线程对全局内存池的频繁竞争。

TC Malloc原理

go 内存分配

make与new的区别

参考文档

• 万字长文深入浅出 Golang Runtime // go夜读的分享，推荐去看下go夜读

• TC Malloc 内存分配原理简析 // 简洁tc malloc的原理

• 图解Go语言内存分配 // 绕全成大佬写的，通俗易懂

• golang内存分配原理及make和new的区别 // 强烈推荐这篇文档，这位大佬的go系列文章都很牛批

在golang语言中创建协程（Goroutine）的成本非常低，因此稍不注意就可能创建出大量的协程，一方面会造成资源的浪费，例如有一万个任务需要处理，如果启用一万个goroutine同时处理，意味了CPU内存资源大量的飙升，所以一般会控制goroutine的数量，例如最多只有一百个goroutine在运行，本章将看下如何控制goroutine的并发数量

goroutine并发控制

并发未控制情形

在说明goroutine并发控制前，先看下并发不控制的代码逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

package main

import (
"fmt"
"sync"
)

func main() {
wg := sync.WaitGroup{}
workerCount := 100
for i := 0; i < workerCount; i++ {
wg.Add(1)
go func(i int) {
defer wg.Done()
fmt.Printf("i am goroutine %d \n", i)
}(i)
}

wg.Wait()
fmt.Println("worker have done")

}

上面的输出如下, 在多核的场景下，goroutine不一定是顺序输出的:

1
2
3
4
5
6
7
8
9
10
11

......
i am goroutine 88 
i am goroutine 63 
i am goroutine 89 
i am goroutine 98 
i am goroutine 82 
i am goroutine 93 
i am goroutine 87 
i am goroutine 95 
i am goroutine 97 
worker have done

下图展示了为每个 job 创建一个 goroutine 的情况（换句话说，goroutine 的数量是不受控制的）。此种情况虽然生成了很多的 goroutine，但是每个 CPU 核上同一时间只能执行一个 goroutine；当 job 很多且生成了相应数目的 goroutine 后，会出现很多等待执行的 goroutine，从而造成资源上的浪费。

并发控制概述

给每个 job 生成一个 goroutine 的方式显得粗暴了很多，那么可以通过什么样的方式控制 goroutine 的数目呢？其实上面的代码通过一个 for-range 循环完成了两件事情：①为每个 job 创建 goroutine；②把任务相关的标识传给相应的 goroutine 执行。为了控制 goroutine 的数目，完全可以把上面的两个过程拆分开：a）先通过一个 for-range 循环创建指定数目的 goroutine，b）然后通过 channel/buffered channel 给每个 goroutine 传递任务相关的信息（这里的channel是否缓冲无所谓，主要用到的是 channel 的线程安全特性）。如下图所示。

goroutine并发控制方案一

针对上面的代码，如果想达到goroutine并发执行的控制，我们可以加个buffer channel来限制最多只有多少个goroutine在执行，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package main

import (
"fmt"
"sync"
)

func main() {
taskCount := 10
worker := make(chan int, 3)
wg := sync.WaitGroup{}

for i := 0; i < taskCount; i++ {
wg.Add(1)

go func(i int) {
defer wg.Done()

worker <- i
fmt.Println("i am worker ", i)
<-worker
}(i)
}

wg.Wait()
}

通过channel限制最多有三个goroutine在执行，其余的被挂起等待中，但是此方案也有个缺陷，那就是goroutine还是都被创建了，只不过这些goroutine被挂起了而已。

goroutine并发控制方案二

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

package main

import (
"fmt"
"sync"
)

func main() {
taskCount, workerCount := 10, 3
worker := make(chan int, workerCount)
wg := sync.WaitGroup{}

for i := 0; i < workerCount; i++ {
go func() {
for w := range worker {
fmt.Println("i am worker ", w)
wg.Done()
}
}()
}

for i := 0; i < taskCount; i++ {
wg.Add(1)
worker <- i
}

wg.Wait()
}

在方案二中，我们起了三个goroutine一直去消费woker以达到限制goroutine最大并发数的目的。

参考文档

• 【图示】控制 Goroutine 的并发数量的方式 // jing 维大佬
• 来，控制一下 goroutine 的并发数量 // 煎鱼老师

什么是goroutine? Goroutine 可以看作对 thread 加的一层抽象，它更轻量级，可以单独执行。

goroutine(协程) 跟 线程的区别

goroutine跟线程的区别可以从内存消耗、创建与销毀、切换三个维度说明

• 内存创建： 创建一个 goroutine 的栈内存消耗为 2 KB，实际运行过程中，如果栈空间不够用，会自动进行扩容。创建一个 thread 则需要消耗 1 MB 栈内存，而且还需要一个被称为 “a guard page” 的区域用于和其他 thread 的栈空间进行隔离。
• 创建和销毀： 线程创建和销毀都会有巨大的消耗，因为要和操作系统打交道，是内核级的，通常解决的办法就是线程池。而 goroutine 因为是由 Go runtime 负责管理的，创建和销毁的消耗非常小，是用户级。
• 切换： 当 threads 切换时，需要保存各种寄存器，以便将来恢复， 而 goroutines 切换只需保存三个寄存器：Program Counter, Stack Pointer and BP。因此goroutines 切换成本比 threads 要小得多。

G-P-M模型概述

在 Go 语言中，每一个 goroutine 是一个独立的执行单元，相较于每个 OS 线程固定分配 2M 内存的模式，goroutine 的栈采取了动态扩容方式， 初始时仅为2KB，随着任务执行按需增长，最大可达 1GB（64 位机器最大是 1G，32 位机器最大是 256M），且完全由 golang 自己的调度器 Go Scheduler 来调度。此外，GC 还会周期性地将不再使用的内存回收，收缩栈空间。 因此，Go 程序可以同时并发成千上万个 goroutine 是得益于它强劲的调度器和高效的内存模型。

将 goroutines 调度到线程上执行，仅仅是 runtime 层面的一个概念，在操作系统之上的层面，在golang中有三个基础的结构体来实现 goroutines 的调度。g，m，p， 俗称GPM模型：

• G: 表示 Goroutine，每个 Goroutine 对应一个 G 结构体，G 存储 Goroutine 的运行堆栈、状态以及任务函数，可重用。G 并非执行体，每个 G 需要绑定到 P 才能被调度执行。
• P: Processor，表示逻辑处理器， 对 G 来说，P 相当于 CPU 核，G 只有绑定到 P(在 P 的 local runq 中)才能被调度。对 M 来说，P 提供了相关的执行环境(Context)，如内存分配状态(mcache)，任务队列(G)等，P 的数量决定了系统内最大可并行的 G 的数量（前提：物理 CPU 核数 >= P 的数量），P 的数量由用户设置的 GOMAXPROCS 决定，但是不论 GOMAXPROCS 设置为多大，P 的数量最大为 256。
• M: Machine，OS 线程抽象，代表着真正执行计算的资源，在绑定有效的 P 后，进入 schedule 循环；而 schedule 循环的机制大致是从 Global 队列、P 的 Local 队列以及 wait 队列中获取 G，切换到 G 的执行栈上并执行 G 的函数，调用 goexit 做清理工作并回到 M，如此反复。M 并不保留 G 状态，这是 G 可以跨 M 调度的基础，M 的数量是不定的，由 Go Runtime 调整，为了防止创建过多 OS 线程导致系统调度不过来，目前默认最大限制为 10000 个。
• 每个 P 维护一个 G 的本地队列；
• 当一个 G 被创建出来，或者变为可执行状态时，就把他放到 P 的本地可执行队列中，如果满了则放入Global；
• 当一个 G 在 M 里执行结束后，P 会从队列中把该 G 取出；如果此时 P 的队列为空，即没有其他 G 可以执行， M 就随机选择另外一个 P，从其可执行的 G 队列中取走一半。

除了GPM外，还有两个比较重要的组件： 全局可运行队列（GRQ）和本地可运行队列（LRQ）。 LRQ 存储本地（也就是具体的 P）的可运行 goroutine，GRQ 存储全局的可运行 goroutine，这些 goroutine 还没有分配到具体的 P。

调度过程

1. 当通过 go 关键字创建一个新的 goroutine 的时候，它会优先被放入 P 的本地队列。
2. 为了运行 goroutine，M 需要持有（绑定）一个 P，接着 M 会启动一个 OS 线程，循环从 P 的本地队列里取出一个 goroutine 并执行。
3. 执行调度算法：当 M 执行完了当前 P 的 Local 队列里的所有 G 后，P 也不会就这么在那划水啥都不干，它会先尝试从 Global 队列寻找 G 来执行，如果 Global 队列为空，它会随机挑选另外一个 P，从它的队列里中拿走一半的 G 到自己的队列中执行。

调度时机

在四种情形下，goroutine 可能会发生调度，但也并不一定会发生，只是说 Go scheduler 有机会进行调度。

1. 使用关键字 go： go 创建一个新的 goroutine，Go scheduler 会考虑调度
2. GC: 由于进行 GC 的 goroutine 也需要在 M 上运行，因此肯定会发生调度。当然，Go scheduler 还会做很多其他的调度，例如调度不涉及堆访问的 goroutine 来运行。GC 不管栈上的内存，只会回收堆上的内存
3. 系统调用: 当 goroutine 进行系统调用时，会阻塞 M，所以它会被调度走，同时一个新的 goroutine 会被调度上来
4. 内存同步访问: atomic，mutex，channel 操作等会使 goroutine 阻塞，因此会被调度走。等条件满足后（例如其他 goroutine 解锁了）还会被调度上来继续运行

同步/异步系统调用

当 G 需要进行系统调用时，根据调用的类型，它所依附的 M 有两种情况：同步和异步。

• 对于同步的情况，M 会被阻塞，进而从 P 上调度下来，P 可不养闲人，G 仍然依附于 M。之后，一个新的 M 会被调用到 P 上，接着执行 P 的 LRQ 里嗷嗷待哺的 G 们。一旦系统调用完成，G 还会加入到 P 的 LRQ 里，M 则会被“雪藏”，待到需要时再“放”出来。

  

• 对于异步的情况，M 不会被阻塞，G 的异步请求会被“代理人” network poller 接手，G 也会被绑定到 network poller，等到系统调用结束，G 才会重新回到 P 上。M 由于没被阻塞，它因此可以继续执行 LRQ 里的其他 G。

  

goroutine状态流转

GPM结构

G 结构

g是goroutine的缩写，是goroutine的控制结构，是对goroutine的抽象。看下它内部主要的一些结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

type g struct {
  //堆栈参数。
  //堆栈描述了实际的堆栈内存：[stack.lo，stack.hi）。
  // stackguard0是在Go堆栈增长序言中比较的堆栈指针。
  //通常是stack.lo + StackGuard，但是可以通过StackPreempt触发抢占。
  // stackguard1是在C堆栈增长序言中比较的堆栈指针。
  //它是g0和gsignal堆栈上的stack.lo + StackGuard。
  //在其他goroutine堆栈上为〜0，以触发对morestackc的调用（并崩溃）。
  //当前g使用的栈空间，stack结构包括 [lo, hi]两个成员
  stack       stack   // offset known to runtime/cgo
  
  // 用于检测是否需要进行栈扩张，go代码使用
  stackguard0 uintptr // offset known to liblink
  
  // 用于检测是否需要进行栈扩展，原生代码使用的
  stackguard1 uintptr // offset known to liblink
  
  // 当前g所绑定的m
  m              *m      // current m; offset known to arm liblink
  // 当前g的调度数据，当goroutine切换时，保存当前g的上下文，用于恢复
  sched          gobuf
  // goroutine运行的函数
  fnstart        *FuncVal
  // g当前的状态
  atomicstatus   uint32
  
  // 当前g的id
  goid           int64
  // 状态Gidle,Grunnable,Grunning,Gsyscall,Gwaiting,Gdead
  status   int16
  
  // 下一个g的地址，通过guintptr结构体的ptr set函数可以设置和获取下一个g，通过这个字段和sched.gfreeStack sched.gfreeNoStack 可以把 free g串成一个链表
  schedlink      guintptr
  // 判断g是否允许被抢占
  preempt        bool       // preemption signal, duplicates stackguard0 = stackpreempt
  // g是否要求要回到这个M执行, 有的时候g中断了恢复会要求使用原来的M执行
  lockedm        muintptr
  // 用于传递参数，睡眠时其它goroutine设置param，唤醒时此goroutine可以获取       param  *void
  // 创建这个goroutine的go表达式的pc
  uintptr    gopc
}

其中包含了栈信息stackbase和stackguard，有运行的函数信息fnstart。这些就足够成为一个可执行的单元了，只要得到CPU就可以运行。goroutine切换时，上下文信息保存在结构体的sched域中。goroutine切换时，上下文信息保存在结构体的sched域中。goroutine是轻量级的线程或者称为协程，切换时并不必陷入到操作系统内核中，很轻量级。

1
2
3
4
5
6
7
8

struct Gobuf
{
    //这些字段的偏移是libmach已知的（硬编码的）。
    sp   uintper;
    pc   *byte;
    g    *G;
    ...
};

P 结构

P是Processor的缩写。结构体P的加入是为了提高Go程序的并发度，实现更好的调度。M代表OS线程。P代表Go代码执行时需要的资源。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

type p struct {
   lock mutex
   
   id          int32
   
   // p的状态
   status      uint32 // one of pidle/prunning/...

    // 下一个p的地址，可参考 g.schedlink
    link        puintptr　　　　// 每次调用 schedule 时会加一　　　　
    schedtick   uint32   　　　　// 每次系统调用时加一　　　　
    syscalltick uint32　　　　// 用于 sysmon 线程记录被监控 p 的系统调用时间和运行时间　　
    sysmontick  sysmontick // last tick observed by sysmon10 
    
    // p所关联的m  指向绑定的 m，如果 p 是 idle 的话，那这个指针是 nil
    m           muintptr   // back-link to associated m (nil if idle)

    // 内存分配的时候用的，p所属的m的mcache用的也是这个
    mcache      *mcache
   
    // Cache of goroutine ids, amortizes accesses to runtime·sched.goidgen.
    // 从sched中获取并缓存的id，避免每次分配goid都从sched分配
    goidcache    uint64
    goidcacheend uint64

    // Queue of runnable goroutines. Accessed without lock.
    // p 本地的runnbale的goroutine形成的队列
    runqhead uint32
    runqtail uint32
    runq     [256]guintptr

    // runnext，如果不是nil，则是已准备好运行的G
    //当前的G，并且应该在下一个而不是其中运行
    // runq，如果运行G的时间还剩时间
    //切片。它将继承当前时间剩余的时间
    //切片。如果一组goroutine锁定在
    //交流等待模式，该计划将其设置为
    //单位并消除（可能很大）调度
    //否则会由于添加就绪商品而引起的延迟
    // goroutines到运行队列的末尾。

    // 下一个执行的g，如果是nil，则从队列中获取下一个执行的g
    runnext guintptr

    // Available G's (status == Gdead)
    // 状态为 Gdead的g的列表，可以进行复用
    gfree    *g
    gfreecnt int32
}

跟G不同的是，P不存在waiting状态。MCache被移到了P中，但是在结构体M中也还保留着。在P中有一个Grunnable的goroutine队列，这是一个P的局部队列。当P执行Go代码时，它会优先从自己的这个局部队列中取，这时可以不用加锁，提高了并发度。如果发现这个队列空了，则去其它P的队列中拿一半过来，这样实现工作流窃取的调度。这种情况下是需要给调用器加锁的。

M 结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

type m struct {
   // g0是用于调度和执行系统调用的特殊g
   g0      *g             // goroutine with scheduling stack
  
   // m当前运行的g
   curg    *g             // current running goroutine
   // 当前拥有的p
   p        puintptr      // attached p for executing go code (nil if not executing go code)
   // 线程的 local storage
   tls      [6]uintptr    // thread-local storage
   // 唤醒m时，m会拥有这个p
   nextp         puintptr
   id            int64
   // 如果 !="", 继续运行curg
   preemptoff    string   // if != "", keep curg running on this m
   // 自旋状态，用于判断m是否工作已结束，并寻找g进行工作
   spinning      bool     // m is out of work and is actively looking for work
   // 用于判断m是否进行休眠状态
   blocked       bool     // m is blocked on a note
   // m休眠和唤醒通过这个，note里面有一个成员key，对这个key所指向的地址进行值的修改，进而达到唤醒和休眠的目的
   park          note
   // 所有m组成的一个链表
   alllink       *m       // on allm
   // 下一个m，通过这个字段和sched.midle 可以串成一个m的空闲链表
   schedlink     muintptr
   // mcache，m拥有p的时候，会把自己的mcache给p
   mcache        *mcache
   // lockedm的对应值
   lockedg       guintptr
   // 待释放的m的list，通过sched.freem 串成一个链表
   freelink      *m      // on sched.freem
}

和G类似，M中也有alllink域将所有的M放在allm链表中。lockedg是某些情况下，G锁定在这个M中运行而不会切换到其它M中去。M中还有一个MCache，是当前M的内存的缓存。M也和G一样有一个常驻寄存器变量，代表当前的M。同时存在多个M，表示同时存在多个物理线程。

参考文档

• 深度解密go语言之scheduler //绕全成大佬的解密完全看不懂
• GoLang GPM模型 //写的不错
• 万字长文深入浅出 Golang Runtime //之前go夜读有看到分享，说的贼好
• go中的协程-goroutine的底层实现 // pdd 牛皮

在说明什么是Webassembly之前，我们有必要了解一下asm.js。2012年，Mozilla 的工程师 Alon Zakai 在研究 LLVM 编译器时突发奇想：许多 3D 游戏都是用 C / C++ 语言写的，如果能将 C / C++ 语言编译成 JavaScript 代码，它们不就能在浏览器里运行了吗？众所周知，JavaScript 的基本语法与 C 语言高度相似。于是，他开始研究怎么才能实现这个目标，为此专门做了一个编译器项目 Emscripten。这个编译器可以将 C / C++ 代码编译成 JS 代码，但不是普通的 JS，而是一种叫做 asm.js 的 JavaScript 变体，性能差不多是原生代码的50%。

之后Google开发了Portable Native Client，也是一种能让浏览器运行C/C++代码的技术。 后来可能是因为彼此之间有共同的更高追求，Google, Microsoft, Mozilla, Apple等几家大公司一起合作开发了一个面向Web的通用二进制和文本格式的项目，那就是WebAssembly。asm.js 与 WebAssembly 功能基本一致，就是转出来的代码不一样：asm.js 是文本，WebAssembly 是二进制字节码，因此运行速度更快、体积更小。

WebAssembly(又称 wasm) 是一种新的字节码格式，主流浏览器都已经支持 WebAssembly。 和 JS 需要解释执行不同的是，WebAssembly 字节码和底层机器码很相似可快速装载运行，因此性能相对于 JS 解释执行大大提升。 也就是说 WebAssembly 并不是一门编程语言，而是一份字节码标准，需要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行， 浏览器厂商需要做的就是根据 WebAssembly 规范实现虚拟机。

这里引用MDN上官方对其的解释：WebAssembly是一种新的编码方式，可以在现代的网络浏览器中运行 － 它是一种低级的类汇编语言，具有紧凑的二进制格式，可以接近原生的性能运行，并为诸如C / C ++ / Rust等语言提供一个编译目标，以便它们可以在Web上运行。它也被设计为可以与JavaScript共存，允许两者一起工作(总结一句话：Webassembly就像是JVM虚拟机，可以执行二进制码)。

有人这么评价Webassembly： Webassembly是Rust押宝的唯一使用场景(Rust语言的使用场景太少了，不像golang在云原生跟中间键领域有很多应用)。

为什么需要WebAssembly

自从 JavaScript 诞生起到现在已经变成最流行的编程语言，这背后正是 Web 的发展所推动的。Web 应用变得更多更复杂，但这也渐渐暴露出了 JavaScript 的问题：

1. 语法太灵活导致开发大型 Web 项目困难；
2. 性能不能满足一些场景的需要。

针对以上两点缺陷，近年来出现了一些 JS 的代替语言，例如：

1. 微软的 TypeScript 通过为 JS 加入静态类型检查来改进 JS 松散的语法，提升代码健壮性；
2. 谷歌的 Dart 则是为浏览器引入新的虚拟机去直接运行 Dart 程序以提升性能；
3. 火狐的 asm.js 则是取 JS 的子集，JS 引擎针对 asm.js 做性能优化。

以上尝试各有优缺点，其中：

1. TypeScript 只是解决了 JS 语法松散的问题，最后还是需要编译成 JS 去运行，对性能没有提升；
2. Dart 只能在 Chrome 预览版中运行，无主流浏览器支持，用 Dart 开发的人不多；
3. asm.js 语法太简单、有很大限制，开发效率低。

三大浏览器巨头分别提出了自己的解决方案，互不兼容，这违背了 Web 的宗旨； 是技术的规范统一让 Web 走到了今天，因此形成一套新的规范去解决 JS 所面临的问题迫在眉睫。于是 WebAssembly 诞生了，WebAssembly 是一种新的字节码格式，主流浏览器都已经支持 WebAssembly。 和 JS 需要解释执行不同的是，WebAssembly 字节码和底层机器码很相似可快速装载运行，因此性能相对于 JS 解释执行大大提升。 也就是说 WebAssembly 并不是一门编程语言，而是一份字节码标准，需要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行， 浏览器厂商需要做的就是根据 WebAssembly 规范实现虚拟机。

总结一句话就是：主流厂商极力主导 + webassembly速度快

Webassembly原理

要搞懂 WebAssembly 的原理，需要先搞懂计算机的运行原理。 电子计算机都是由电子元件组成，为了方便处理电子元件只存在开闭两种状态，对应着 0 和 1，也就是说计算机只认识 0 和 1，数据和逻辑都需要由 0 和 1 表示，也就是可以直接装载到计算机中运行的机器码。 机器码可读性极差，因此人们通过高级语言 C、C++、Rust、Go 等编写再编译成机器码。

由于不同的计算机 CPU 架构不同，机器码标准也有所差别，常见的 CPU 架构包括 x86、AMD64、ARM， 因此在由高级编程语言编译成可自行代码时需要指定目标架构。WebAssembly 字节码是一种抹平了不同 CPU 架构的机器码，WebAssembly 字节码不能直接在任何一种 CPU 架构上运行， 但由于非常接近机器码，可以非常快的被翻译为对应架构的机器码，因此 WebAssembly 运行速度和机器码接近，这听上去非常像 Java 字节码。

在javascript中，JavaScript引擎是执行 JavaScript 代码的程序或解释器。JavaScript引擎可以实现为标准解释器，或者以某种形式将JavaScript编译为字节码的即时编译器。不用的浏览器使用不同的引擎如下所示：

• V8 — 开源，由 Google 开发，用 C ++ 编写

• Rhino — 由 Mozilla 基金会管理，开源，完全用 Java 开发

• SpiderMonkey — 是第一个支持 Netscape Navigator 的 JavaScript 引擎，目前正供 Firefox 使用

• JavaScriptCore — 开源，以Nitro形式销售，由苹果为Safari开发

• KJS — KDE 的引擎，最初由 Harri Porten 为 KDE 项目中的 Konqueror 网页浏览器开发

• Chakra (JScript9) — Internet Explorer

• Chakra (JavaScript) — Microsoft Edge

• Nashorn, 作为 OpenJDK 的一部分，由 Oracle Java 语言和工具组编写

• JerryScript — 物联网的轻量级引擎

因此我们看下javascript在V8引擎下的工作机制: javacript运行中，引擎首先解析javascript生成抽象语法树(AST), 然后生成机器码。

接着通过V8 的优化编译器 (TurboFan)的优化，把优化后的机器码推向后端(所谓的后端就是即时编译器JIT)

但是webassembly并不需要以上的全部步骤－如下所示是它被插入到执行过程示意图:

可以看到webassembly并不需要编译阶段，而是直接把编译后的字节码发送给后端，因此速度更快。

目前能编译成 WebAssembly 字节码的高级语言有：

• AssemblyScript:语法和 TypeScript 一致，对前端来说学习成本低，为前端编写 WebAssembly 最佳选择；

• C\C++:官方推荐的方式，详细使用见文档;

• Rust:语法复杂、学习成本高，详细使用见文档;

• Kotlin:语法和 Java、JS 相似，语言学习成本低，详细使用见文档;

• Golang:语法简单学习成本低。详细使用见文档。

• 其他语言: 详细见文档。

Webassembly使用场景：

总体而言，WASM不会替代JavaScript，但是却可以辅助解决很多JavaScript无法解决的问题。下面是Webassembly的一些场景：

浏览器场景：

• 更好的让一些语言和工具可以编译到 Web 平台运行。

• 图片/视频编辑。

• 游戏：

  • 需要快速打开的小游戏

• AAA 级，资源量很大的游戏。

• 游戏门户（代理/原创游戏平台）

• P2P 应用（游戏，实时合作编辑）

• 音乐播放器（流媒体，缓存）

• 图像识别

• 视频直播

• VR 和虚拟现实

• CAD 软件

• 科学可视化和仿真

• 互动教育软件和新闻文章。

• 模拟/仿真平台(ARC, DOSBox, QEMU, MAME, …)。

• 语言编译器/虚拟机。

非浏览器场景：

• 游戏分发服务（便携、安全）。

• 服务端执行不可信任的代码。

• 服务端应用。

• 移动混合原生应用。

• 多节点对称计算

下一步

基于golang实现webassembly的demo

require/exports 出生在野生规范当中，什么叫做野生规范？即这些规范是 JavaScript 社区中的开发者自己草拟的规则，得到了大家的承认或者广泛的应用。比如 CommonJS、AMD、CMD 等等。import/export 则是名门正派。TC39 制定的新的 ECMAScript 版本，即 ES6（ES2015）中包含进来。

关于 import 和 require 的不同，其实可以理解成 CommonJs 和 ES Module 的区别。这两者都是前端模块化的规范。

CommonJs

Nodejs 是 CommonJS 规范的主要实践者，在 CommonJs 里每个文件就是一个模块，有自己的作用域。在一个文件里面定义的变量、函数、类，都是私有的，对其他文件不可见。

1
2
3
4
5
6
7
8
9
10

class MyClass {
  constructor(name) {
    this.name = name;
  }
}

module.exports.MyClass = Myclass

const MyClass = require('./myclass.js')
const obj = new MyClass('hello')

ES Module

ES6 模块的设计思想是尽量的静态化，使得编译时就能确定模块的依赖关系，以及输入和输出的变量。所以ES6 模块不是对象，而是通过 export 命令显式指定输出的代码，再通过 import 命令输入。这种加载称为“编译时加载”或者静态加载，即 ES6 可以在编译时就完成模块加载，效率要比 CommonJS 模块的加载方式高。

1
2
3
4
5
6
7
8

export default class MyClass {
constructor(name) {
    this.name = name;
  }
}

import MyClass from './myclass'
const obj = new MyClass('hello')

区别

关于调用

1. require的引用可以在代码的任何地方。
2. import语法规范上是放在文件开头。

参考文档

• https://juejin.cn/post/6844903765489745927 // 值得一看
• https://www.zhihu.com/question/56820346 // 值得一看
• https://segmentfault.com/a/1190000023082896 // 值得一看

在命令top中可以方便的查看系统的cpu和内存信息(如下图所示), 然后你可能不清楚每一个字段代表的含义，现在就一块揭秘top命令中每个字段的含义

us：user time，表示 CPU 执行用户进程的时间，包括 nice 时间。通常都是希望用户空间CPU越高越好。

sy：system time，表示 CPU 在内核运行的时间，包括 IRQ 和 softirq。系统 CPU 占用越高，表明系统某部分存在瓶颈。通常这个值越低越好。

ni：nice time，具有优先级的用户进程执行时占用的 CPU 利用率百分比。

id：idle time，表示系统处于空闲期，等待进程运行。

wa：waiting time，表示 CPU 在等待 IO 操作完成所花费的时间。系统不应该花费大量的时间来等待 IO 操作，否则就说明 IO 存在瓶颈。

hi：hard IRQ time，表示系统处理硬中断所花费的时间。

si：soft IRQ time，表示系统处理软中断所花费的时间。

st：steal time，被强制等待（involuntary wait）虚拟 CPU 的时间，此时 Hypervisor 在为另一个虚拟处理器服务

cpu 平均负载Load Average

​ 在上面的top命令中跟cpu相关的信息还有一个叫load average, load average这一列中的三个数值分别表示过去一分钟，五分钟，十五分钟这个节点上的load average。那么到底啥是load average呢?

​ 这里的load average表示对CPU资源需求的度量(说的很好，但是等于放屁~)，举个例子你可能就懂了，对于一个单个 CPU 的系统，如果在 1 分钟的时间里，处理器上始终有一个进程在运行，同时操作系统的进程可运行队列中始终都有 9 个进程在等待获取 CPU 资源。那么对于这 1 分钟的时间来说，系统的”load average”就是 1+9=10(这个定义对绝大部分的Unix 系统都适用)。

总结一句话就是: load average 等于单位时间内正在运行的进程+可运行队列的进程(注意，这里说的是unix系统)，因此：

• 第一，不论计算机 CPU 是空闲还是满负载，Load Average 都是 Linux 进程调度器中可运行队列（Running Queue）里的一段时间的平均进程数目。
• 第二，计算机上的 CPU 还有空闲的情况下，CPU Usage 可以直接反映到”load average”上，什么是 CPU 还有空闲呢？具体来说就是可运行队列中的进程数目小于 CPU个数，这种情况下，单位时间进程 CPU Usage 相加的平均值应该就是”load average”的值。
• 第三，计算机上的 CPU 满负载的情况下，计算机上的 CPU 已经是满负载了，同时还有更多的进程在排队需要 CPU 资源。这时”load average”就不能和 CPU Usage 等同了。比如对于单个 CPU 的系统，CPU Usage 最大只是有 100%，也就 1 个 CPU；而”loadaverage”的值可以远远大于 1，因为”load average”看的是操作系统中可运行队列中进程的个数。

对于linux系统来说： load average = 可运行队列的进程 + 处于TASK_UNINTERRUPTIBLE状态的进程(D 状态进程)

TASK_UNINTERRUPTIBLE 是 Linux 进程状态的一种，是进程为等待某个系统资源而进入了睡眠的状态，并且这种睡眠的状态是不能被信号打断的。俗称D状态进程

因此，如果发现系统的load average很高，而CPU还是处于空闲状态，说明有很多进程处于阻塞状态，这时候得检查下代码写的是否有问题啦~(通过 ps 命令可以查阅D状态进程的信息)

top命令原理

分析了top命令中cpu字段的含义，你肯定还有疑问top命令中的数值是怎么计算出来的，

容器中如何查看cpu信息

参考文档

• https://github.com/silenceshell/topic // 容器中正确展示top信息

• https://zhuanlan.zhihu.com/p/66252461 //知乎专栏
• https://cloud.tencent.com/developer/article/1375877 //腾讯云
• https://github.com/kubernetes/kubernetes/tree/master/build/pause // pause 源码解析
• https://o-my-chenjian.com/2017/10/17/The-Pause-Container-Of-Kubernetes/

参考文档

• https://spongecaptain.cool/SimpleClearFileIO/1.%20page%20cache.html