【Kafka核心】架构模型：Producer、Broker、Consumer、Consumer Group、Topic、Partition、Replica

小江的记录本2026-05-03 22:10

文章目录

Kafka核心------架构模型

本文基于Kafka最新稳定版（3.x+，含KRaft架构），围绕Producer、Broker、Consumer、Consumer Group、Topic、Partition、Replica七大核心实体，构建从顶层设计→核心实体拆解→全链路协同→核心机制→设计哲学→落地实践的完整知识体系，实现全方位、结构化的知识闭环。

一、Kafka架构顶层设计与核心分层

Kafka是分布式、高吞吐、可持久化的事件流平台，采用发布-订阅架构，核心设计理念是「基于分区的分布式存储+基于消费者组的弹性消费模型」，整体为三层解耦的去中心化集群架构，无单点瓶颈。

架构分层 核心实体 核心职责
数据生产层 Producer 消息的生产、序列化、分区路由、批量投递，向集群写入数据
核心服务层 Broker、Topic、Partition、Replica 集群核心载体，负责消息的持久化存储、副本同步、请求处理、元数据管理，是生产与消费的中间桥梁
数据消费层 Consumer、Consumer Group 消息的拉取、反序列化、业务处理，通过消费者组实现弹性并行消费与多场景消息投递
元数据控制层 KRaft控制器（3.x推荐）/ZooKeeper 集群元数据管理、控制器选举、分区Leader选举、Topic生命周期管理、故障转移

核心架构演进：3.3版本后KRaft模式生产可用，逐步替代ZooKeeper，架构更简洁，支持更大规模集群，元数据同步延迟更低，分区数上限大幅提升。

二、核心存储实体层：Topic、Partition、Replica

存储实体是Kafka数据的载体，三者为层级包含关系：Topic是逻辑容器，Partition是物理存储单元，Replica是Partition的冗余副本，共同支撑Kafka的水平扩展、有序性、高可用与持久化能力。

2.1 Topic（主题）

核心定义

Kafka中消息的逻辑分类与隔离容器，是发布-订阅模型的核心载体。生产者向指定Topic投递消息，消费者订阅指定Topic消费消息，不同业务/场景通过Topic实现数据隔离。

核心特性与设计要点
  1. 纯逻辑抽象：Topic本身不存储数据，数据全部落地在其下属的Partition中，仅维护元数据信息。
  2. 多租户隔离：权限控制、消息保留策略、清理策略的最小粒度为Topic，支持多业务场景的资源隔离。
  3. 流式存储特性：消息采用追加写入模式，消费不会删除消息，仅更新消费位移；支持可配置的消息生命周期（时间/大小/压缩策略），支持数据回溯与重放。
  4. 水平扩展底座：一个Topic可绑定多个Partition，分布在不同Broker节点，实现吞吐能力的线性扩展。
核心元数据配置

分区数、副本因子、消息保留时间/大小、清理策略（delete/compact）、最小同步副本数、压缩类型等。

2.2 Partition（分区）

核心定义

Topic下的物理存储最小单元，是Kafka实现高吞吐、有序性、并行消费的核心基石。一个Topic的多个Partition均匀分布在集群不同Broker节点，实现分布式存储与并行处理。

核心特性与核心机制
  1. 严格的有序性边界
    • 单Partition内消息严格按写入顺序持久化，全局（多Partition）无法保证有序；
    • 每条消息在Partition内有唯一的offset（偏移量），单调递增，是消息在分区内的唯一身份标识。
  2. 极致的写入性能
    • 分区采用顺序追加写的日志结构，磁盘顺序写性能接近内存，彻底规避随机写的性能损耗，是Kafka高吞吐的核心根源。
  3. 水平扩展能力
    • Topic的吞吐能力随Partition数量线性扩展，不同Partition可并行处理读写请求，突破单节点的硬件性能上限。
  4. 消费并行度绑定规则
    • 消费者组内，一个Partition只能被一个Consumer消费，一个Consumer可同时消费多个Partition；
    • 单消费者组的消费并行度上限=Topic的分区数，消费者数量超过分区数时，多余消费者会处于空闲状态。
内部物理存储结构

每个Partition对应磁盘上的一个独立目录，由多个固定大小的LogSegment（日志段） 组成，当前活跃写入的为Active Segment，其余为只读的历史Segment。每个LogSegment包含3个核心文件：

  • .log：消息数据实体文件，存储序列化后的消息内容；
  • .index：偏移量稀疏索引文件，记录offset与.log文件中物理位置的映射，实现消息的快速查找；
  • .timeindex：时间戳稀疏索引文件，实现基于时间的消息回溯与查找。

2.3 Replica（副本）

核心定义

Partition的数据冗余副本，是Kafka实现高可用、数据不丢失的核心机制。每个Partition有1个Leader副本 + N个Follower副本（N=副本因子-1），副本必须分布在不同Broker节点，严禁同节点多副本，避免单点故障。

核心角色与职责划分
副本角色 核心职责 读写权限
Leader副本 每个Partition唯一的主副本，所有客户端的读写请求必须由Leader副本处理；维护ISR列表，管理Follower副本同步状态 全权处理读写请求
Follower副本 被动从Leader副本拉取消息数据，保持与Leader的同步；不处理任何客户端读写请求；Leader宕机时参与新Leader选举 仅同步数据，不对外提供服务
优先副本（Preferred Replica） Partition创建时的第一个副本，是默认的优先Leader副本，用于集群负载均衡，执行优先副本选举可让Leader回归该副本，平衡集群负载 同Leader/Follower规则
观察者副本（Observer Replica） 3.0+新增，不参与ISR选举与Leader竞选，仅同步数据，用于跨地域同步、读负载隔离，不影响主集群可用性 仅同步数据，可配置只读权限
核心机制：ISR（In-Sync Replicas 同步副本集）

ISR是Kafka平衡数据可靠性与可用性的核心设计，是与Leader保持数据同步的副本集合（包含Leader本身）。

  1. 同步判定标准 ：Follower副本在replica.lag.time.max.ms时间内持续从Leader拉取数据，且消息落后量在阈值内，才会被纳入ISR。
  2. 核心作用
    • 数据可靠性保障：只有ISR内所有副本都同步成功的消息，才会被标记为已提交（Committed），消费者只能消费已提交的消息；
    • 高可用选举保障：Leader宕机时，只能从ISR集合中选举新的Leader，彻底避免已提交消息丢失。
  3. 关键配套参数 ：min.insync.replicas，指定ISR集合的最小副本数，配合acks=all使用，保证数据写入的强可靠性。

三、核心交互实体层：Producer、Broker、Consumer、Consumer Group

交互实体是Kafka数据流转的核心载体，负责消息的生产、中转、消费全流程处理，与存储实体深度协同，实现完整的消息流转闭环。

3.1 Producer（生产者）

核心定义

负责消息的生产、序列化、分区路由、批量发送、可靠性保障的客户端组件，核心目标是将业务消息高效、可靠地投递到指定Topic的Partition Leader副本。

核心工作流程与内部组件
复制代码 
业务消息 → 序列化 → 分区路由 → 消息累加器（批量攒包） → Sender线程 → 网络IO层 → Broker Leader副本
  1. 消息序列化：将业务对象序列化为字节数组，Kafka自带基础序列化器，支持自定义Avro/Protobuf/JSON等高性能序列化方案。
  2. 分区路由策略 ：决定消息投递的目标Partition，核心策略包括：
    • 轮询策略：key为空时默认采用，轮询所有Partition，实现消息均匀分布；
    • Hash策略：指定key时，按key的hash值对分区数取模，保证相同key的消息始终投递到同一个Partition，实现单key全局有序；
    • 自定义策略：实现Partitioner接口，自定义路由规则。
  3. 消息累加器（RecordAccumulator） ：Producer端核心缓冲组件，消息先写入累加器的内存批次（Batch），当批次满（batch.size）或达到等待超时时间（linger.ms），由Sender线程批量发送，大幅减少网络IO次数，提升吞吐。
  4. Sender线程与网络IO：独立的IO线程，将批次按Broker分组，通过Java NIO客户端发送到对应Partition Leader所在的Broker，同时处理Broker的ACK响应与异常重试。
核心可靠性保障：ACK机制

ACK是生产者控制消息投递可靠性的核心配置，直接决定吞吐与数据安全的平衡：

ACK配置 核心规则 吞吐 可靠性 适用场景
acks=0 生产者发送后不等待Broker任何响应，直接认为发送成功 最高 最低，网络抖动/Leader宕机极易丢消息 日志采集等非关键数据、极致吞吐需求
acks=1（默认） 等待Leader副本写入本地日志成功后，返回ACK响应 中等 中等，Leader写入后宕机、Follower未同步完成时会丢消息 通用业务场景，平衡吞吐与可靠性
acks=-1/all 等待ISR内所有副本全部同步写入成功后，返回ACK响应 最低 最高，配合min.insync.replicas≥2，可保证已提交消息零丢失 金融、交易等关键业务，强数据可靠性需求
核心容错与高级特性
  1. 重试机制 ：通过retries配置重试次数，针对网络抖动、Leader切换等可重试异常自动重试，配合retry.backoff.ms设置重试间隔。
  2. 幂等性 ：3.0+默认开启（enable.idempotence=true），通过Producer ID + 消息序列号，保证单生产者会话内消息「不重复、不丢失、不乱序」，是Exactly Once语义的基础。
  3. 事务支持：支持跨分区、跨Topic的事务性写入，实现生产端的Exactly Once语义，完美适配流处理、数据同步等场景。

3.2 Broker（代理节点）

核心定义

Kafka集群的核心服务节点 ，是部署Kafka服务进程的单个服务器节点，集群由多个Broker组成，每个Broker有唯一的broker.id，是连接生产与消费的核心枢纽，负责数据存储、副本同步、请求处理、集群元数据管理。

核心职责与核心组件

  1. 分区副本全生命周期管理

    • 托管本机上的Partition Leader与Follower副本，处理副本的创建、删除、数据同步；
    • 维护每个Partition的ISR列表，同步给集群控制器；
    • 执行消息清理与过期管理，按Topic配置的保留策略，清理过期日志段，支持delete（删除过期）和compact（日志压缩，保留每个key的最新值）两种清理模式。

  2. 客户端请求全链路处理

    • 基于Java NIO的Reactor模式设计网络通信层，分为Acceptor线程（接收客户端连接）、Processor线程（网络IO读写）、Handler线程（业务逻辑处理），实现高并发请求处理；
    • 处理Producer写入请求：权限校验、写入Leader副本本地日志、等待ISR同步、返回ACK响应；
    • 处理Consumer拉取请求：权限校验、读取已提交消息、通过零拷贝技术返回给消费者。

  3. 副本同步机制

    • Follower副本所在Broker，通过Fetch请求持续从Leader所在Broker拉取消息，更新本地日志，保持与Leader的同步；
    • 支持机架感知策略，将Partition副本分布在不同机架的Broker上，避免单机架宕机导致数据丢失与服务不可用。

  4. 集群控制器（Controller）职责

    集群中会选举出一个Broker作为Active Controller，是集群的大脑，KRaft模式下由控制器节点集群选举产生，核心职责：

    • 分区Leader选举、副本状态管理、故障转移；
    • Topic的创建、删除、分区扩容等生命周期管理；
    • Broker上下线的事件处理与负载均衡；
    • 集群元数据的管理与全集群同步。
核心性能优化设计
  1. 零拷贝技术 ：使用Linux sendfile 零拷贝系统调用，将数据从磁盘文件直接发送到网络网卡，避免内核态与用户态之间的多次数据拷贝，消费吞吐提升30%+。
  2. 稀疏索引设计 ：.index与.timeindex均采用稀疏索引，不存储每条消息的索引项，大幅减少磁盘占用与内存开销，同时保证毫秒级消息查找能力。
  3. 页缓存（PageCache）优先：优先利用操作系统的页缓存，将热点数据缓存在内存中，避免频繁的磁盘IO，实现接近内存的读写性能，JVM堆内存建议控制在16G以内，避免GC开销，预留更多内存给页缓存。

3.3 Consumer（消费者）

核心定义

负责从Kafka集群拉取已提交消息、反序列化、业务处理的客户端组件，核心目标是可靠、高效地消费消息，并管理消费进度。

核心工作流程与核心特性

  1. 订阅模式

    • 主题订阅：通过subscribe()方法订阅一个/多个Topic，支持正则匹配，自动分配分区，受消费者组重平衡管理；
    • 手动分配：通过assign()方法手动指定消费的Partition，不受消费者组重平衡影响，适合固定分区的批处理场景。

  2. 拉取模型（Pull）设计

    Kafka采用消费者主动拉取模型，而非服务端推送模型，核心优势：消费者可根据自身消费能力，自主控制拉取速度、批量大小、拉取时机，彻底避免消费能力不足时被服务端推送压垮的问题。

    • 长轮询优化：通过fetch.max.wait.ms配置，Broker无新消息时会hold住请求，直到有新消息或超时，减少消费者空轮询的网络IO开销。

  3. 位移（Offset）管理

    位移是消费者消费进度的唯一标识，记录消费者在对应Partition的消费位置，3.x版本默认持久化在系统Topic __consumer_offsets 中，替代老版本的ZooKeeper存储。

    • 核心提交方式：
      1. 自动提交 ：默认开启（enable.auto.commit=true），每隔auto.commit.interval.ms自动提交位移，配置简单但存在消息丢失/重复消费风险；
      2. 手动提交 ：分为同步提交commitSync()和异步提交commitAsync()，可精准控制位移提交时机，业务处理完成后再提交，保证消息不丢失，是关键业务的推荐方案。

  4. 消费语义保障

    消费语义 实现方式 核心特点 适用场景
    最多一次（At Most Once） 先提交位移，再处理业务消息 消息不会重复消费，业务处理失败会丢失消息 日志采集、非关键数据统计，可容忍少量数据丢失
    至少一次（At Least Once，默认） 先处理业务消息，处理成功后再提交位移 消息绝对不会丢失，位移提交失败会导致重复消费 绝大多数业务场景，优先保证数据不丢失，业务端做幂等处理
    精确一次（Exactly Once） 生产端幂等+事务+消费端幂等处理 消息处理且仅处理一次，无丢失无重复 金融交易、数据对账、精准统计等强一致性场景
核心容错机制
  • 心跳机制：消费者向消费者组协调者持续发送心跳，证明自身存活，超时未发送会被踢出消费者组，触发分区重分配；
  • 故障重试：网络异常、拉取失败时自动重试，配合重试间隔配置，避免瞬时异常导致消费中断。

3.4 Consumer Group（消费者组）

核心定义

Kafka实现消息单播/广播、弹性并行消费、消费故障转移的核心机制，是多个Consumer的逻辑分组。同一个消费者组内的消费者共同消费订阅Topic的全量Partition，组内实现负载均衡，组间完全隔离、互不影响。

核心设计黄金规则（重中之重）
  1. 分区消费排他性 ：同一个Topic的一个Partition，只能被同一个消费者组内的一个Consumer消费，绝对禁止同组内多个Consumer同时消费同一个Partition，保证单分区消息的消费有序性。
  2. 消费并行度上限 ：单消费者组的有效消费并行度=组内存活的消费者数量，上限=订阅Topic的分区数。若消费者数量超过分区数，多余的消费者会处于空闲状态，无法消费任何消息，造成资源浪费。
  3. 组间完全隔离性：不同消费者组之间完全独立，各自维护消费位移，全量消费订阅Topic的消息，互不影响。例如同一个Topic，消费者组G1和G2分别订阅，G1的消费进度不会影响G2，天然实现消息广播。
  4. 消息投递模型实现 ：
    • 单播模型：所有消费者加入同一个消费者组，一条消息只会被组内的一个消费者消费；
    • 广播模型：每个消费者单独一个消费者组，一条消息会被所有消费者全量消费。
核心组件：消费者协调者（Coordinator）

每个消费者组对应集群中的一个Broker作为组协调者，是消费者组的管理核心，职责包括：

  • 消费者组成员管理：处理消费者的加入、退出请求，维护组成员列表；
  • 位移管理：处理消费者的位移提交请求，将位移数据持久化到__consumer_offsets；
  • 重平衡触发与管理：监听组内状态变化，触发并协调重平衡流程。
核心机制：重平衡（Rebalance）

重平衡是消费者组的分区负载均衡机制，当触发条件满足时，重新将Topic的Partition分配给组内的消费者，保证消费负载均衡。

  1. 触发条件

    • 消费者组成员变化：新消费者加入、消费者宕机/主动退出、消费者心跳超时；
    • 订阅关系变化：消费者新增/删除订阅的Topic；
    • 订阅Topic的分区数变化：Topic执行分区扩容。

  2. 重平衡核心流程

    1. 选举组协调者：确定消费者组对应的协调者Broker；
    2. 加入组（Join Group）：所有消费者向协调者发送加入组请求，协调者选举一个消费者作为组领导者（Group Leader）；
    3. 同步分配（Sync Group）：组领导者制定分区分配方案，发送给协调者，协调者将方案同步给组内所有消费者，消费者按方案接管对应分区。

  3. 分区分配策略

    分配策略 核心规则 适用场景
    Range策略（默认） 按Topic维度，将分区按范围分配给消费者 单Topic消费场景
    RoundRobin策略 轮询分配所有订阅Topic的全量分区，均匀分配 多Topic消费场景
    Sticky策略 粘性分配，尽量保留之前的分配结果，减少重平衡时的分区变动 通用场景，减少消费中断
    Cooperative Sticky策略 合作式粘性分配，增量重平衡，避免重平衡时全组停止消费 3.x推荐，生产环境首选，大幅降低重平衡影响

  4. 重平衡痛点与优化

    • 核心痛点：传统Eager模式下，重平衡时所有消费者会停止消费、放弃分区，重新加入组，导致消费中断；频繁重平衡会严重影响消费性能。
    • 优化方案：
      1. 采用Cooperative Sticky分配策略，实现增量重平衡，避免全组停消费；
      2. 配置静态成员ID（group.instance.id），避免消费者重启触发重平衡；
      3. 合理调整session.timeout.ms和heartbeat.interval.ms，避免网络波动导致的误判重平衡；
      4. 优化消费逻辑，避免消费阻塞导致心跳超时。

四、核心组件全链路协同工作流（一条消息的完整生命周期）

复制代码 
元数据获取 → 消息生产写入 → 副本同步与提交 → 持久化存储 → 消息拉取消费 → 位移提交 → 故障转移

  1. 元数据获取阶段

    Producer/Consumer启动后，先向配置的Bootstrap Servers发送元数据请求，获取目标Topic的分区分布、Leader副本所在Broker地址等元数据，缓存到本地，并定期更新/异常时主动刷新。

  2. 消息生产写入阶段

    • Producer将业务消息序列化，通过分区路由策略确定目标Partition；
    • 消息写入Producer端消息累加器，攒成批量数据；
    • Sender线程将批量数据发送到目标Partition的Leader副本所在Broker；
    • Leader副本将消息写入本地日志，更新offset。

  3. 副本同步与消息提交阶段

    • Follower副本持续从Leader拉取消息，写入本地日志，向Leader发送同步ACK；
    • 当ISR内所有副本全部同步完成，消息被标记为已提交（Committed）；
    • Broker根据Producer的acks配置，向Producer返回对应的ACK响应。

  4. 持久化存储阶段

    • 消息以顺序追加的方式持久化到Partition的LogSegment中；
    • Broker根据Topic的保留策略，管理消息生命周期，清理过期数据。

  5. 消息拉取与消费阶段

    • Consumer加入消费者组，与组协调者通信完成分区分配，获取自身负责的Partition；
    • Consumer向对应Partition的Leader副本发送Fetch拉取请求，指定拉取offset与批量大小；
    • Broker校验请求，通过零拷贝技术将已提交的消息数据返回给Consumer；
    • Consumer反序列化消息，执行业务处理逻辑。

  6. 位移提交阶段

    • 业务处理完成后，Consumer按配置的提交方式，向组协调者提交消费位移；
    • 协调者将位移数据持久化到__consumer_offsets系统Topic，完成消费进度的持久化。

  7. 故障转移阶段

    • 若Leader副本所在Broker宕机，集群控制器会从ISR集合中选举新的Leader，更新集群元数据；
    • Producer/Consumer自动感知Leader切换，将请求路由到新的Leader副本；
    • 若消费者组内的Consumer宕机，组协调者触发重平衡，将该Consumer负责的Partition重新分配给组内存活的Consumer，保证消费不中断。

五、架构核心设计哲学与核心优势

  1. 高吞吐的底层设计：分区水平扩展+顺序追加写+批量处理+零拷贝+页缓存利用，实现单机百万级TPS的消息处理能力，远超传统消息队列。
  2. 极致的高可用保障：多副本冗余+ISR同步机制+去中心化集群+自动故障转移+消费者组重平衡，实现集群级、节点级、进程级的多层容灾，无单点故障。
  3. 灵活的消息模型：通过消费者组天然实现单播与广播的灵活切换，支持发布-订阅、队列、流式处理等多种消息模型，适配绝大多数业务场景。
  4. 持久化与数据回溯能力：消息持久化到磁盘，支持长周期数据存储，基于offset与时间戳的回溯能力，完美适配数据重放、故障修复、离线计算等场景。
  5. 可扩展性与兼容性：支持从单节点到上千节点的集群平滑扩容，兼容上下游大数据生态（Flink、Spark、Hadoop等），是实时数仓、事件驱动架构的标准基础设施。

六、核心架构落地最佳实践与避坑指南

6.1 Topic与Partition设计

  • 分区数不是越多越好：单Broker分区数建议≤1000，集群总分区数≤10万，过多分区会增加控制器压力、文件句柄开销、故障恢复时间；
  • 分区数建议设置为Broker节点数的整数倍，保证均匀分布；
  • 副本因子建议设置为3，关键业务强制3副本，非关键业务可设置为2，严禁1副本；
  • 有序性需求：全局有序只能使用单分区，单key有序使用key hash分区策略。

6.2 Producer生产端优化

  • 关键业务强制开启幂等性，配置acks=all + min.insync.replicas=2，保证数据零丢失；
  • 合理设置batch.size与linger.ms，平衡吞吐与延迟，通用场景建议batch.size=16KB，linger.ms=5ms；
  • 推荐使用LZ4/ZSTD压缩算法，大幅减少网络IO与磁盘占用，提升吞吐。

6.3 Consumer消费端优化

  • 消费者数量不超过订阅Topic的分区数，避免资源浪费；
  • 关键业务使用手动位移提交，保证消费语义，避免消息丢失；
  • 生产环境首选Cooperative Sticky分区分配策略，减少重平衡影响；
  • 消费逻辑严禁阻塞，避免心跳超时触发频繁重平衡，长耗时业务建议异步解耦。

6.4 Broker集群优化

  • 配置机架感知，将副本分布在不同机架，提升机房级容灾能力；
  • JVM堆内存建议设置为8-16G，预留更多内存给操作系统页缓存；
  • 生产环境优先使用SSD磁盘，提升副本同步、索引查找的随机IO性能；
  • 定期执行优先副本选举，平衡集群Leader负载，避免单节点压力过大。
相关推荐
dvjr cloi1 小时前
MySQL Workbench菜单汉化为中文
android·数据库·mysql
止语Lab1 小时前
从手动到框架：Go DI 演进的三个拐点
开发语言·后端·golang
yaoxin5211232 小时前
397. Java 文件操作基础 - 创建常规文件与临时文件
java·开发语言·python
dFObBIMmai2 小时前
MySQL主从同步中大事务导致的延迟_如何拆分大事务优化同步
jvm·数据库·python
szccyw02 小时前
mysql如何限制特定存储过程执行权限_MySQL存储过程安全访问
jvm·数据库·python
一切皆是因缘际会2 小时前
AI数字分身的底层原理：破解意识、自我与人格复刻的核心难题
大数据·人工智能·ai·架构
czlczl200209252 小时前
利用“延迟关联”优化 MySQL 巨量数据的深分页查询
数据库·mysql
ACP广源盛139246256733 小时前
IX8024与科学大模型的碰撞@ACP#筑牢科研 AI 算力高速枢纽分享
运维·服务器·网络·数据库·人工智能·嵌入式硬件·电脑
Elastic 中国社区官方博客3 小时前
ES|QL METRICS_INFO 和 TS_INFO：为你的时间序列数据建立目录
大数据·数据库·elasticsearch·搜索引擎·信息可视化·全文检索
热门推荐
01要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法02GitHub 镜像站点03Codex 接入 DeepSeek API 完整配置文档04【AI】2026 年具身智能模型和世界模型总结05裂开！ChatGPT 居然开始要手机号验证，附详细解决方法06零基础教你claude code 接入 deepseek V4072026年AI前瞻：量子AI、具身智能与科学发现的新纪元08实测可用｜小米 MiMo 百万亿 Token 免费领，开发者速冲09在Windows 11上安装Docker的踩坑记录10CC-Switch & Claude 基于 Linux 服务器安装使用指南