kafka相关问题

给我个面子中不2024-12-15 17:03

Kafka 通过事务机制与幂等性功能相结合，实现了跨会话的幂等性。以下是详细解释：

kafka是怎么通过事物保证跨会话的幂等性？

1. 幂等性与跨会话幂等性

  • 幂等性：指相同的操作被执行多次，其结果是一样的。在 Kafka 中，主要是指生产者发送相同的消息不会导致重复。
  • 跨会话幂等性：在生产者会话关闭并重启后，Kafka 仍能保证发送的消息不会被重复处理。

2. Kafka 的幂等性原理

Kafka 的幂等性主要通过 Producer ID（PID） 和 Sequence Number（序列号） 来实现：

  • Producer ID (PID) ：
    • Kafka 为每个生产者分配一个唯一的 PID。
    • PID 在生产者实例重启时会发生变化。
  • Sequence Number ：
    • 每个分区内的每条消息都会有一个严格递增的序列号。
    • Broker 通过比较当前接收到的消息序列号和之前存储的序列号，判断是否是重复消息。

幂等性只在单个会话内生效，因为生产者重启后，PID 会发生变化，导致之前的 Sequence Number 信息无法继续使用。

3. 跨会话幂等性的挑战

生产者在重启后，如何避免之前发送的消息与新会话的消息冲突？这就需要事务的支持。

4. 事务如何保证跨会话幂等性

Kafka 的事务机制通过以下步骤实现跨会话的幂等性：

1) 事务 ID (Transactional ID)
  • 事务 ID 是幂等性和事务的关键点 ：
    • 与 Producer ID 不同，事务 ID 是应用层定义的，用于标识逻辑上的生产者实例。
    • Kafka 通过事务 ID 追踪生产者的状态，即使生产者实例重启，Kafka 仍然知道之前的事务记录。
2) 事务管理

  • 事务协调器 (Transaction Coordinator)：

    • Kafka 集群中的一个组件，负责管理事务状态和日志。
    • 通过事务 ID 映射到特定的事务协调器。

  • 事务状态存储：

    • 事务的状态信息（如最新的 PID 和对应的事务状态）存储在 Kafka 的内部主题 __transaction_state 中。
    • 当生产者重启时，Kafka 根据事务 ID 恢复生产者的 PID 和事务上下文。
3) 幂等性与事务的结合

  • 事务性生产者：

    • 当生产者开启事务功能时，Kafka 生成一个新的 PID，同时确保事务 ID 和 PID 的关联。
    • 即使生产者重启，Kafka 仍能通过事务 ID 恢复会话，保证幂等性。

  • 幂等性校验：

    • 事务管理会检查消息的 Sequence Number 是否符合逻辑顺序。
    • 重复的消息会被直接丢弃。

5. 示例流程

  1. 生产者启动：

    • 指定 transactional.id，启动一个事务性生产者。
    • Kafka 分配一个新的 PID。

  2. 消息生产与提交：

    • 消息被写入 Kafka 的分区，同时标记为事务性消息。
    • 提交时，Kafka 将更新事务状态为 COMMITTED。

  3. 生产者重启：

    • Kafka 根据事务 ID 恢复 PID 和未完成的事务状态。
    • 未完成的事务会被标记为 ABORTED，丢弃其未提交的消息。

  4. 新的消息发送：

    • 新的会话中继续使用恢复的上下文，保证消息的幂等性和事务一致性。

6. 注意事项

  1. 开启事务功能需要配置：

    properties 复制代码 
    enable.idempotence=true
transactional.id=<事务ID>

  2. 跨会话的幂等性依赖于事务 ID，因此事务 ID 应该是全局唯一的且与生产者实例绑定。

通过上述机制，Kafka 能够在跨会话场景下结合事务与幂等性，确保消息处理的准确性和一致性。

kafka保证消息有序消费

需要有序消费的场景

一个典型的有序消费场景是订单处理系统。例如：

  1. 用户在电商平台下单，包含创建订单、支付订单、取消订单等操作。
  2. 系统必须按照用户的操作顺序处理事件：订单先被创建，后被支付，可能再被取消。
  3. 如果事件处理顺序乱了，比如先处理"支付"再处理"创建"，业务逻辑将会出错。

在这种场景下，需要保证事件按照其产生的顺序被消费和处理。

Kafka 如何保证有序消费

Kafka 的设计通过 分区（Partition） 和 生产者-消费者机制 来实现有序消费，具体如下：

1. 分区内顺序保证

Kafka 在单个分区（Partition）中保证消息的顺序。消息是按写入顺序（Append-only）存储在日志中，每条消息都有一个递增的偏移量（Offset）。消费者从分区中读取消息时，Kafka按偏移量顺序返回消息，因此消费者读取到的消息顺序与生产者写入的顺序一致。

关键点：

  • 单个分区内的顺序是严格保证的。
  • 不同分区之间的消息顺序无法保证。
2. 生产者如何指定分区

为了利用分区内的有序特性，生产者需要确保相同类型的消息始终写入同一个分区。Kafka 提供两种机制来控制分区选择：

  • Key-based Partitioning: 生产者在发送消息时可以指定一个 Key，Kafka 会使用 Key 的哈希值决定消息所属的分区。
  • Custom Partitioning: 生产者可以实现自定义的分区策略，将消息路由到特定的分区。

例如，对于订单处理，可以使用订单 ID 作为消息的 Key，这样同一订单的所有事件会被写入同一个分区，从而保证顺序。

3. 消费者组消费分区

Kafka 的消费者组模型使得多个消费者可以协作消费消息：

  • 每个分区只能由一个消费者实例消费，确保同一分区的消息不会被多个消费者并发处理，从而维护顺序。
  • 如果消费者实例增加或减少，Kafka 会重新分配分区到消费者实例，但单个分区的顺序仍然被维护。
4. 消息乱序的可能性与应对

在某些情况下，可能出现乱序问题，比如：

  • 一个分区包含多个不同类型的消息，处理速度不同。
  • 消息写入不同分区。

解决办法：

  • 设计消息模型，确保同一逻辑处理单元的消息归属于一个分区。
  • 在消费者端实现缓冲机制，将乱序的消息重新排序后再处理。

Kafka 的其他相关特性

幂等性生产者

Kafka 提供了幂等性生产者（Idempotent Producer），防止因重试导致的重复消息写入，从而进一步帮助维护消息的顺序。

事务

Kafka 支持事务，使得生产者可以保证一组消息的原子性写入。事务在分布式环境中保证了多分区的消息一致性，但不会跨分区维护消息顺序。

总结

Kafka 能够通过分区内顺序、Key-based 路由和消费分配策略实现严格的有序消费。要在实际场景中保证有序消费，开发者需要：

  1. 合理设计分区策略。
  2. 使用 Key 将相关消息路由到同一分区。
  3. 确保消费者组的设计能够维护分区的独占性。

消费者组的偏移量是怎么保存的

假设我们有一个 Kafka 主题 topic1，它有 6 个分区（partition 0 到 partition 5），并且有一个消费者组 group1，这个消费者组包含 3 个消费者（consumer1, consumer2, consumer3）。下面我通过一个例子来详细解释在这种情况下，Kafka 是如何保存偏移量的。

1. 消费者组和分配

Kafka 会将消费者组 group1 内的消费者分配到不同的分区上。假设 Kafka 采用轮询或其他策略来平衡消费者与分区之间的关系，那么在这个例子中，可能会出现以下分配情况：

  • consumer1 负责 partition 0 和 partition 1
  • consumer2 负责 partition 2 和 partition 3
  • consumer3 负责 partition 4 和 partition 5

这种分配确保每个分区都只有一个消费者在消费，避免了多个消费者竞争消费同一个分区的消息。

2. 消费者消费消息并更新偏移量

每个消费者会从自己负责的分区中消费消息，并跟踪它消费的进度。Kafka 会通过消费者组内的偏移量来记录这些进度。下面我们假设每个分区中有 10 条消息（编号为 0 到 9），消费者开始消费消息。

consumer1（负责 partition 0 和 partition 1）：
  • 假设 consumer1 已经消费了 partition 0 中的前 4 条消息（0-3），并消费了 partition 1 中的前 6 条消息（0-5）。
  • Kafka 会在内部的 __consumer_offsets 主题中为 consumer1 保存如下偏移量：
    • partition 0 的偏移量：4（表示 consumer1 已消费至第 5 条消息）
    • partition 1 的偏移量：6（表示 consumer1 已消费至第 7 条消息）
consumer2（负责 partition 2 和 partition 3）：
  • 假设 consumer2 已消费了 partition 2 中的前 3 条消息（0-2），并消费了 partition 3 中的前 7 条消息（0-6）。
  • Kafka 会为 consumer2 保存以下偏移量：
    • partition 2 的偏移量：3
    • partition 3 的偏移量：7
consumer3（负责 partition 4 和 partition 5）：
  • 假设 consumer3 已消费了 partition 4 中的前 5 条消息（0-4），并消费了 partition 5 中的前 8 条消息（0-7）。
  • Kafka 会为 consumer3 保存以下偏移量：
    • partition 4 的偏移量：5
    • partition 5 的偏移量：8

3. Kafka 如何保存这些偏移量？

偏移量是保存在 Kafka 内部的 __consumer_offsets 主题中的。这个主题会记录每个消费者组、每个分区的偏移量信息。Kafka 会为每个消费者组（例如 group1）的每个分区（例如 partition 0、partition 1 等）保存一条偏移量记录。

因此，在上述的例子中，__consumer_offsets 主题中的数据可能是这样的：

Consumer Group Partition Offset
group1 partition 0 4
group1 partition 1 6
group1 partition 2 3
group1 partition 3 7
group1 partition 4 5
group1 partition 5 8

这意味着：

  • consumer1 在 partition 0 上的消费进度是 4（即它已经消费了 partition 0 中的前 4 条消息）。
  • consumer1 在 partition 1 上的消费进度是 6（即它已经消费了 partition 1 中的前 6 条消息）。
  • consumer2 在 partition 2 上的消费进度是 3，依此类推。

4. 偏移量的更新与提交

偏移量的更新由消费者来决定。Kafka 提供了两种偏移量提交方式：

  1. 自动提交偏移量（Auto Commit） ：

    如果启用了自动提交，消费者在消费消息后会自动提交偏移量。通常，这个操作会在一定时间间隔后完成（比如每隔 5 秒）。

  2. 手动提交偏移量（Manual Commit） ：

    如果启用了手动提交，消费者可以显式地控制什么时候提交偏移量。例如，消费者可能在处理完一批消息后才提交偏移量，或者在确认消息已正确处理之后才提交偏移量。

不论哪种方式，偏移量最终会保存到 __consumer_offsets 主题中。每个消费者组的偏移量是独立的，消费者组间的消费进度互不影响。

5. 重点总结

  • 偏移量是 消费者组 维护的，而不是单个消费者。
  • Kafka 为每个消费者组记录每个分区的偏移量，存储在 __consumer_offsets 主题中。
  • 每个消费者组的偏移量更新是独立的，消费者组之间的消费进度互不干扰。
  • 偏移量是由消费者控制和提交的，可以选择自动提交或者手动提交。

这个机制确保了 Kafka 中的消息消费是高效且可扩展的，同时允许消费者组独立地跟踪自己的消费进度。

往broker写入数据的流程

Kafka 是一个高吞吐量的分布式消息队列系统，其数据写入和持久化设计精巧，保证了性能和可靠性。以下是 Kafka 写入消息到 Broker 时的详细过程，包括持久化和索引的原理及流程。

Kafka 写入数据的过程

1. 生产者发送消息

生产者将消息发送到 Kafka 的特定主题（Topic）。每个主题分为多个分区（Partition），生产者根据分区策略选择将消息写入哪一个分区。

2. Broker 接收消息

每个分区由一个 Kafka Broker 管理。当生产者发送消息到 Broker 时，Broker 会：

  • 验证消息的合法性（例如主题是否存在）。
  • 接收消息并将其写入分区的日志文件。
3. 日志存储

Kafka 的日志存储是分区的核心，其组织方式如下：

  • 分段存储（Segmented Storage） :
    • 每个分区的日志被分为多个固定大小的段（Segment），每个段是一个日志文件。
    • 日志文件以追加方式（Append-only）写入，文件名是起始偏移量。
  • 追加写入（Write-Ahead Logging） :
    • 消息按照写入顺序追加到当前活跃的日志段中。
    • 每条消息都包含元数据，例如偏移量（Offset）、时间戳等。
4. 索引文件

Kafka 为每个分段创建索引文件，用于快速定位消息：

  • 时间索引（TimeIndex）：记录消息时间戳与偏移量的映射。
  • 偏移量索引（OffsetIndex）：记录偏移量与消息的物理位置（字节偏移）的映射。

这些索引文件被定期刷盘，存储在与日志文件相同的目录中。

Kafka 的持久化机制

1. 消息持久化的时机

Kafka 使用 PageCache（操作系统的文件系统缓存）来提高性能，并通过以下机制控制持久化：

  • **实时写入：**消息首先写入文件系统缓存（内存）。
  • 刷盘时机（Flush） :
    • 定时刷盘：根据配置参数 log.flush.interval.messages 或 log.flush.interval.ms，定期将数据从内存刷到磁盘。
    • 强制刷盘：当生产者设置 acks=all 时，所有副本完成写入后，Kafka 会强制刷盘。
2. 持久化的方式

Kafka 将日志文件和索引文件持久化到磁盘。它使用高效的 I/O 模型：

  • 使用顺序写入来减少磁盘寻址开销。
  • 文件段和索引文件被存储在 Kafka Broker 的日志目录（log.dirs）中。
3. 持久化的位置

Kafka 日志和索引文件的持久化位置可以通过配置 log.dirs 参数指定，支持多路径存储来提高数据冗余和性能。

举例：写入数据的完整流程

场景：用户下单事件写入 Kafka

  1. 生产者发送消息

    • 消息：{"orderId": 12345, "status": "created", "timestamp": 1697037600}
    • 主题：orders
    • 分区策略：使用订单 ID (12345) 的哈希值选择分区，例如分区 0。

  2. Broker 接收消息

    • Broker A 管理 orders 的分区 0。
    • 消息被追加到分区 0 当前活跃段的日志文件 000000000000.log 中。

  3. 索引文件更新

    • 偏移量为 42 的消息被写入日志文件。
    • 索引文件更新：
      • 偏移量索引记录：偏移量 42 -> 物理位置（字节偏移量）。
      • 时间索引记录：时间戳 1697037600 -> 偏移量 42。

  4. 消息持久化

    • 消息首先写入操作系统缓存（PageCache）。
    • 当满足刷盘条件（例如日志段达到一定大小或超时）时，数据被刷到磁盘上的日志目录 /var/lib/kafka/logs/orders-0/。

  5. 消息消费者消费

    • 消费者从分区 0 的偏移量 42 开始拉取消息。
    • 消费者通过偏移量索引定位消息在日志文件中的具体位置，从而快速读取消息。

总结

Kafka 的写入和持久化机制通过高效的日志结构、索引文件和刷盘策略实现了高性能和可靠性。整个流程如下：

  1. 消息写入分区日志文件并更新索引。
  2. 使用 PageCache 提高性能，满足条件时刷盘。
  3. 日志文件和索引文件被存储在指定的目录中，实现持久化和快速定位。

这种设计使 Kafka 能够在保证可靠性的同时，提供极高的吞吐量，非常适合大规模实时数据流处理的场景。

消费者读取文件的流程

Kafka 的索引文件和日志文件是紧密对应的，索引文件的作用是快速定位日志文件中的消息，避免逐条遍历日志文件查找。以下是它们的对应关系和快速定位原理的详细说明。

日志文件和索引文件的关系

日志文件
  • 每个分区的日志由多个固定大小的段（Segment）组成，每个段由一个日志文件和多个索引文件组成。
  • 日志文件存储实际的消息，文件名为段的起始偏移量，例如 00000000000000000000.log 表示该段的起始偏移量为 0。
索引文件
  • 偏移量索引文件（OffsetIndex） ：记录逻辑偏移量与物理位置的映射，文件名类似于 00000000000000000000.index。
  • 时间戳索引文件（TimeIndex） ：记录时间戳与逻辑偏移量的映射，文件名类似于 00000000000000000000.timeindex。

每对日志段和索引文件通过相同的起始偏移量关联。例如：

  • 00000000000000000000.log 对应 00000000000000000000.index 和 00000000000000000000.timeindex。

快速定位消息的过程

Kafka 使用二分查找和顺序读取的组合来快速定位消息。

查找步骤

  1. 确定日志段

    • 消费者请求读取偏移量（例如，偏移量为 42）的消息。
    • Kafka 根据段的起始偏移量范围（例如，[0, 100)，[100, 200)）快速确定偏移量所属的日志段。
    • 如果偏移量为 42，则定位到 00000000000000000000.log。

  2. 通过偏移量索引快速定位物理位置

    • 打开对应的索引文件 00000000000000000000.index。

    • 在索引文件中通过二分查找找到目标偏移量（42）对应的物理位置。

    • 索引文件存储偏移量到日志文件物理位置的映射，例如：

      Offset: 40 -> Position: 1024
Offset: 50 -> Position: 2048
      • 偏移量 42 在偏移量 40 和 50 之间，因此物理位置在 1024 ~ 2048 之间。

  3. 顺序读取日志文件

    • 根据索引文件提供的物理位置范围，Kafka 从日志文件的 1024 字节位置开始顺序读取，直到找到偏移量 42 的消息。
时间戳查找（按时间定位）

如果消费者请求按照时间戳查找消息，Kafka 使用时间戳索引文件 00000000000000000000.timeindex：

  1. 在时间戳索引文件中通过二分查找找到目标时间戳（例如 1697037600）对应的偏移量。
  2. 按偏移量查找步骤获取对应的日志位置。

举例说明

场景

分区 0 的日志文件和索引文件如下：

  • 00000000000000000000.log: 存储消息偏移量为 [0, 99]。

  • 00000000000000000000.index: 偏移量索引文件，部分内容如下：

    Offset: 0  -> Position: 0
Offset: 50 -> Position: 1024
Offset: 100 -> Position: 2048

消费者请求获取偏移量为 72 的消息。

查找流程

  1. 确定日志段

    • 偏移量 72 位于 [0, 99] 范围内，因此使用 00000000000000000000.log。

  2. 使用偏移量索引快速定位

    • 在 00000000000000000000.index 中二分查找：
      • 偏移量 72 在偏移量 50 和 100 之间。
      • 物理位置范围为 [1024, 2048)。

  3. 读取日志文件

    • 从日志文件 00000000000000000000.log 的位置 1024 开始顺序读取。
    • 跳过偏移量 50 到 71 的消息，找到偏移量为 72 的目标消息。

总结

Kafka 索引文件和日志文件通过段的起始偏移量关联，配合使用以下机制快速定位消息：

  1. 根据请求的偏移量或时间戳，通过段的范围快速定位日志段。
  2. 使用偏移量索引文件进行二分查找，确定日志文件中的物理位置范围。
  3. 结合顺序读取，从日志文件中高效提取目标消息。

这种设计使得 Kafka 在保证高吞吐量的同时，仍能快速处理消息定位需求，非常适合大规模数据流的实时处理场景。

kafka幂等性

Kafka 的幂等性（Idempotence）旨在解决因网络故障或其他异常导致生产者重复发送消息的问题，确保无论生产者如何重试，同一条消息只会被持久化到 Kafka 一次。以下是 Kafka 幂等性的底层实现原理的详细讲解。

幂等性的关键机制

Kafka 的幂等性依赖以下几个核心组件和机制：

1. Producer ID（PID）
  • 每个 Kafka 生产者在初始化时，Kafka 会为其分配一个唯一的 Producer ID。
  • PID 是生产者的全局标识，用于区分不同的生产者实例。
2. 序列号（Sequence Number）
  • 每个生产者针对每个分区维持一个递增的 序列号。
  • 序列号记录了生产者发送到分区的每条消息的顺序。
3. Log End Offset（LEO）
  • Kafka Broker 为每个分区维护一个 Log End Offset（LEO），表示该分区中当前最新消息的偏移量。
  • 结合序列号和 LEO，可以确保消息不会被重复写入。
4. 幂等性控制表（Producer State Table）
  • Kafka Broker 为每个分区维护一个 Producer State Table ，记录生产者和该分区的状态，包括：
    • Producer ID: 生产者的唯一标识。
    • Last Sequence Number: 最近一次成功写入该分区的序列号。

幂等性实现流程

生产者发送消息
  1. 生产者为每条消息生成一个递增的序列号，并在消息中附带 PID 和序列号。
  2. 消息发送到 Kafka Broker，目标为某个特定分区。
Broker 校验幂等性

  1. 查找 Producer State Table:

    • Broker 检查分区对应的 Producer State Table 是否有该生产者（通过 PID 标识）。
    • 如果 PID 存在，读取其最新序列号。
    • 如果 PID 不存在，则初始化状态记录，并接受消息。

  2. 校验序列号:

    • 如果消息的序列号等于 Last Sequence Number + 1，说明消息按序到达，Broker 接收并写入。
    • 如果序列号小于或等于 Last Sequence Number，说明消息已被写入，Broker 忽略消息。
    • 如果序列号大于 Last Sequence Number + 1，说明存在消息丢失或乱序，Broker 抛出错误。
更新 Producer State Table
  • 如果消息被成功写入日志，Broker 更新 Producer State Table 中该生产者的最新序列号。
响应生产者
  • Broker 向生产者返回 ACK，确认消息写入成功或被忽略。

示例：幂等性保障过程

场景
  • 生产者发送三条消息到分区 P0，序列号依次为 0、1、2。
  • 由于网络问题，生产者未收到消息序列号为 1 的 ACK，触发重试。
过程

  1. 发送消息 0:

    • 序列号为 0，PID 为 12345。
    • Broker 的 Producer State Table 初始为空。
    • Broker 接受消息，更新 Last Sequence Number = 0。
    • 消息写入分区日志，返回 ACK。

  2. 发送消息 1:

    • 序列号为 1，PID 为 12345。
    • Broker 检查 Producer State Table，序列号正确。
    • 消息写入分区日志，更新 Last Sequence Number = 1。
    • 返回 ACK，但生产者未收到。

  3. 重试消息 1:

    • 生产者再次发送序列号为 1 的消息。
    • Broker 检查 Producer State Table，发现序列号等于 Last Sequence Number。
    • 消息已写入，Broker 忽略消息，返回 ACK。

  4. 发送消息 2:

    • 序列号为 2，PID 为 12345。
    • Broker 检查 Producer State Table，序列号正确。
    • 消息写入分区日志，更新 Last Sequence Number = 2。
    • 返回 ACK。

幂等性的限制和扩展

幂等性的限制
  • 单分区保障: 幂等性只保证生产者对每个分区的消息不重复，但不能跨分区。
  • 有限重试窗口: 由于 Broker 的 Producer State Table 存储有限，Kafka 幂等性无法无限期跟踪历史记录。
事务的扩展

为了跨分区的原子性和一致性，Kafka 引入事务机制（Transaction），结合幂等性提供更强的保障：

  • 生产者在事务内发送多条消息，Kafka 确保这些消息要么全部写入，要么全部失败。
  • 事务依赖幂等性和事务协调器（Transaction Coordinator）共同实现。

总结

Kafka 的幂等性通过以下关键步骤实现：

  1. Producer ID 唯一标识生产者实例。
  2. 序列号 确保生产者向分区发送的消息按顺序到达。
  3. Producer State Table 记录生产者最新状态，校验消息的重复性和正确性。

这种设计使 Kafka 能在分布式系统中高效保障消息的不重复写入，同时通过事务机制进一步扩展幂等性的适用范围，为用户提供可靠的数据一致性保障。

相关推荐
亦是远方几秒前
C++编译过程
java·开发语言·c++
阿年、嗯啊23 分钟前
hadoop服役新节点后，NameNode的web页面无法访问节点信息
大数据·hadoop·分布式·服役新节点·无法访问节点信息·无法访问9864端口
Lojarro23 分钟前
【Tomcat】第二站：Tomcat通过反射机制运行项目
java·tomcat
【上下求索】32 分钟前
学习笔记069——Java集合框架
java·集合
.生产的驴43 分钟前
Docker Compose 多应用部署 一键部署
java·运维·后端·spring cloud·docker·容器·gateway
上海拔俗网络1 小时前
“AI数据生成系统：创造数据新动力
java·团队开发
冰之杍1 小时前
springboot2升级到springboot3过程相关修改
java·spring boot
珂朵莉MM1 小时前
第六届全球校园人工智能算法精英大赛-算法巅峰专项赛（系列文章）-- 开篇
java·人工智能·python·算法·职场和发展
drebander1 小时前
手撕 HttpClient：自己实现简单的 HTTP 请求工具
java·网络
热门推荐
01WPS-0DAY-20230809的分析和利用复现02玄机平台应急响应—webshell查杀03(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明04如何解决电脑无声问题：排除故障的几种常见方法05MacBook外接键盘修改键位06Docker 夺命连环 15 问07文心一言最新重磅发布！08【凡人修仙传_01】散修厉飞羽是如何出师未捷身先死的！09PyTorch机器学习实现液态神经网络10硬件知识积累 USB 接口 type - A type - B type - C 的介绍与功能说明 （简单介绍）