企业官网建设流程全解析

1. 为什么说Kafka不是“又一个消息队列”，而是一套重新定义数据流动的基础设施

你打开任何一家中型以上公司的技术栈图谱，Kafka 几乎都稳居数据中枢位置——它不只在“发消息”，更在持续吞吐、缓冲、重放、分发每一条业务事件：用户点击、订单创建、库存变更、风控打标、实时推荐特征更新……这些原本散落在各服务日志里的“毛细血管级”数据流，在 Kafka 里被统一建模为不可变、有序、可重放的时间序列事件流。这和 RabbitMQ 或 RocketMQ 的“队列-消费者”范式有本质区别：后者关注“任务是否被处理”，前者关注“数据是否被完整、一致、可控地流转”。

我最早接触 Kafka 是在某高校实验室做模拟项目X时，团队用传统 HTTP 接口同步订单状态，结果促销活动一开，下游库存服务直接雪崩。后来换成 Kafka，把“下单成功”这个事件作为 Topic 发出去，库存、物流、积分、风控四个系统各自订阅，互不阻塞——哪怕库存服务宕机两小时，重启后自动从上次 offset 拉取积压数据，整个链路零丢失、零人工干预。那一刻我才真正理解：Kafka 的核心价值从来不是“快”，而是确定性——对数据位置的确定性（offset）、对分区顺序的确定性（partition-level ordering）、对消费进度的确定性（commit 语义）、对集群状态的确定性（ZooKeeper/KRaft 协调）。

标题里写“Kafka私房菜”，不是指教你怎么敲几行命令跑起来，而是带你拆开它的“灶台”：看清楚 Producer 怎么把数据切成块塞进 Partition，Consumer Group 怎么协作“分田到户”地读数据，Controller 如何在脑中画出整个集群的拓扑地图，ZooKeeper 又如何像老账房先生一样一笔笔记下 broker 的生死簿。这些机制不是孤立存在的，它们环环相扣——比如你调高linger.ms降低网络开销，就必然影响端到端延迟；你设小replication.factor节省磁盘，就等于主动放弃容错能力；你让 Consumer 手动 commit offset，就得自己扛住重复消费或丢失消费的风险。

所以这篇内容不按“安装→配置→启动”的线性教程走，而是回到问题原点：当你面对一个真实业务场景——比如要支撑每秒 5 万笔支付事件的实时风控计算，你会怎么设计 Kafka 集群？这需要你同时考虑：Topic 分区数怎么定（不能拍脑袋）、副本怎么分布（避免单点故障）、Producer 的acks设多少（性能与可靠性权衡）、Consumer 的auto.offset.reset选什么（首次启动行为）、甚至磁盘 IO 调度策略（避免 page cache 争抢）。这些决策背后，全是 Kafka 系统架构的底层逻辑在说话。

提示：别急着复制粘贴配置文件。先问自己三个问题：我的数据有多重要？我能容忍多久的不可用？我的下游系统处理能力瓶颈在哪？答案不同，Kafka 的“做法”就完全不同。

2. Kafka 的四层骨架：从消息模型到集群心跳，每一层都在解决一个具体矛盾

Kafka 不是黑盒，它由四层清晰可辨的逻辑骨架构成，每一层都直面一个分布式系统中的经典矛盾。理解这四层，比死记参数更有价值。

2.1 第一层：Topic-Partition-Replica 模型——解决“海量数据如何既可扩展又不丢”

这是 Kafka 最外显的结构，但很多人只看到“Topic 是个名字”，没看到它背后是三重抽象：

• Topic 是逻辑容器：它不存数据，只定义数据契约（如payment_events_v2），类似数据库里的表名；
• Partition 是物理分片：每个 Topic 被切分成 N 个 Partition，数据按 Key 哈希或轮询写入，实现水平扩展。关键点在于：同一个 Partition 内消息严格有序，跨 Partition 不保证顺序。这意味着如果你要保证“同一用户的所有支付事件按时间排序”，就必须用用户 ID 作 Key，强制同用户事件落到同一 Partition；
• Replica 是冗余副本：每个 Partition 有多个 Replica（含 1 个 Leader + N-1 个 Follower），Leader 处理所有读写，Follower 异步/半同步拉取数据。这里藏着一个易错点：min.insync.replicas=2意味着写入必须等至少 2 个副本落盘才返回成功，但如果只有 2 个副本且其中一个宕机，Producer 就会卡住——所以生产环境replication.factor至少设为 3，min.insync.replicas设为 2，留出 1 个副本容错空间。

实测过一个案例：某公司把replication.factor设为 2，集群运行半年无事，直到一次磁盘故障导致一个 broker 离线，所有写入瞬间失败。他们翻文档才发现，acks=all+min.insync.replicas=2在双副本下等于“全有或全无”，毫无弹性。后来改成三副本，故障时自动降级为两副本写入，业务完全无感。

2.2 第二层：Producer-Consumer-Group 模型——解决“一对多分发如何兼顾吞吐与语义准确”

这一层决定了数据怎么“进”和怎么“出”，也是最容易踩坑的地方。

Producer 的核心参数不是bootstrap.servers，而是这三个：

• acks：0（发完即忘，最快但可能丢）、1（Leader 写成功即返回，平衡点）、all（ISR 中所有副本写成功，最安全但最慢）；
• retries和retry.backoff.ms：网络抖动时自动重试，但注意：若enable.idempotence=true（开启幂等），重试不会造成重复；否则需业务层去重；
• batch.size和linger.ms：攒批发送。batch.size=16384（16KB）+linger.ms=20是常见组合，实测在千兆网卡下吞吐提升 3~5 倍，延迟增加不到 20ms。

Consumer 的灵魂在 Group：

• 同一 Group 内多个 Consumer 实例自动分配 Partition（Rebalance），实现并行消费；
• Offset 由 Group 维护，不是单个 Consumer。所以你重启一个 Consumer 实例，它会从 Group 记录的 offset 继续读，而非从头开始；
• 关键陷阱：auto.offset.reset=earliest（从头读）和latest（从最新读）只在 Group 第一次启动或 offset 不存在时生效。一旦 Group 有提交记录，这个参数就失效了——很多人误以为改了它就能“重放历史数据”，结果发现毫无作用。

我们曾在线上遇到一个诡异问题：新上线的风控 Consumer Group 连续三天没收到任何数据。排查发现，开发在测试环境用earliest启动过一次，触发了 offset 提交，线上环境复用同一 Group ID，Kafka 就默认从那个“测试 offset”往后读——而那个 offset 对应的是三个月前的数据，早已被清理。解决方案很简单：换新 Group ID，或用kafka-consumer-groups.sh --reset-offsets命令强制重置。

2.3 第三层：Controller 与元数据管理——解决“集群大脑如何保持全局视图一致”

Kafka 集群没有中心节点，但必须有一个“临时大脑”来协调。在 ZooKeeper 时代，这个角色叫 Controller，由 ZooKeeper 选举产生（ZooKeeper 中/controller节点数据最小的 broker 当选）。

Controller 干三件大事：

• Broker 上下线感知：监听 ZooKeeper/brokers/ids路径变化，Broker 启动时在此路径下创建临时节点，宕机则节点消失；
• Partition 副本状态管理：维护每个 Partition 的 ISR（In-Sync Replicas）列表，当 Follower 落后太多（replica.lag.time.max.ms=10000默认值），Controller 就把它踢出 ISR；
• Leader 选举：当 Leader 宕机，Controller 从 ISR 中选一个新 Leader，并通知所有 broker 更新元数据。

这里有个隐藏成本：Controller 本身是单点，虽然选举快（毫秒级），但大规模集群（>50 broker）中，Controller 负载会成为瓶颈。这也是 Kafka 3.3+ 推出 KRaft 模式的主因——用内置的 Raft 协议替代 ZooKeeper，让 Controller 职能分布式化。不过目前（2024年中）生产环境仍以 ZooKeeper 模式为主，KRaft 多用于新项目验证。

2.4 第四层：Log Segment 与索引机制——解决“TB 级数据如何毫秒定位消息”

Kafka 的高性能秘密不在内存，而在磁盘。它把每个 Partition 的数据分成多个 Log Segment（默认 1GB 或 7 天滚动），每个 Segment 包含：

• .log文件：实际消息存储，顺序追加，操作系统 page cache 缓存；
• .index文件：稀疏索引，每 4KB 消息建一条索引项，记录物理位置（offset → position）；
• .timeindex文件：时间戳索引，支持按时间查找（如log.roll.hours=168）。

这意味着：查找 offset=123456789 的消息，Kafka 先通过二分法在.index中定位到该 offset 所在的 segment，再根据索引项找到.log中的字节偏移量，最后读取——整个过程 O(log N)，与数据总量无关。我们压测过：10TB 数据盘，随机查任意 offset，P99 延迟稳定在 3ms 内。

但这也带来运维细节：.index文件大小直接影响内存占用。默认index.interval.bytes=4096，如果消息极小（如 100 字节），索引密度就太高，1TB 数据可能生成 2GB 索引文件。这时可调大index.interval.bytes到 8192 或 16384，用少量定位精度换内存。

3. ZooKeeper + Kafka 集群部署：不是“照着文档配”，而是“带着故障预案配”

部署 Kafka 集群不是终点，而是运维长跑的起点。我见过太多团队把 Kafka 部署在虚拟机上，三台机器共用一块 SSD，结果一次磁盘 I/O 飙升，整个集群假死。真正的部署，必须从第一天就预设“哪里会坏”。

3.1 硬件与系统层：绕不开的五个硬约束

Kafka 对硬件有明确偏好，违背它等于自埋地雷：

特别提醒：永远不要把 ZooKeeper 和 Kafka Broker 部署在同一台物理机上。ZooKeeper 对延迟极度敏感（会话超时默认 40s），Kafka 的批量刷盘和 GC 会干扰 ZooKeeper 的心跳检测，导致 ZooKeeper 频繁假死，进而引发 Kafka 元数据混乱。

3.2 ZooKeeper 集群部署：三节点是底线，五节点是甜点

ZooKeeper 必须奇数节点（防脑裂），生产环境最低三节点，推荐五节点（容忍两节点故障）。

部署要点：

• 独立磁盘：ZooKeeper 的dataDir和dataLogDir必须分盘，dataLogDir（事务日志）务必放在高速 SSD；
• JVM 参数：-Xms2G -Xmx2G -XX:+UseG1GC，堆内存严禁超过 4G；
• 配置关键项：

  tickTime=2000 initLimit=10 syncLimit=5 autopurge.purgeInterval=24

  tickTime是 ZooKeeper 心跳基本单位，initLimit表示 follower 连接 leader 的最长时间（单位 tickTime），syncLimit是 follower 与 leader 数据同步的最大延迟（单位 tickTime）。我们曾把syncLimit设为 2，在网络抖动时 follower 频繁被踢出集群，调到 5 后稳定。

ZooKeeper 部署完成后，务必验证：

echo "stat" | nc localhost 2181 | grep "Mode:" # 输出 "Mode: follower" 或 "Mode: leader" 表示正常 echo "mntr" | nc localhost 2181 | grep "zk_followers" # 查看 follower 数量

3.3 Kafka Broker 配置：九个必调参数与它们的真实含义

Kafka 的server.properties有上百参数，但生产环境只需盯紧这九个，它们覆盖 90% 的性能与稳定性问题：

其中advertised.listeners是最高频错误点。举个真实例子：某公司在 Kubernetes 部署 Kafka，listeners设PLAINTEXT://0.0.0.0:9092，advertised.listeners却写成PLAINTEXT://kafka-0.kafka-headless:9092。结果外部应用通过 Ingress 访问时，Kafka 返回这个内部 DNS 名，外部根本解析不了。正确做法是：advertised.listeners写 Ingress 的公网域名或 LoadBalancer IP。

3.4 集群启停与验证：三步确认法，拒绝“看起来在跑”

启动顺序铁律：先 ZooKeeper，后 Kafka。ZooKeeper 未就绪，Kafka 会疯狂重试连接，日志刷屏。

启动后，执行三步验证：

第一步：检查 ZooKeeper 中 Kafka 节点

# 进入 ZooKeeper CLI echo "ls /brokers/ids" | ./zkCli.sh -server zk1:2181 # 应输出所有 broker.id，如 [1,2,3] echo "get /brokers/ids/1" | ./zkCli.sh -server zk1:2181 # 应返回 broker 1 的元数据 JSON

第二步：检查 Kafka 自身状态

# 查看所有 topic（应包含 __consumer_offsets） kafka-topics.sh --bootstrap-server kafka1:9092 --list # 查看某 topic 详情（确认分区、副本、leader 分布） kafka-topics.sh --bootstrap-server kafka1:9092 --describe --topic test-topic # 输出示例： # Topic: test-topic PartitionCount: 6 ReplicationFactor: 3 Configs: # Topic: test-topic Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3 # Topic: test-topic Partition: 1 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1 # 注意：Replicas 是分配方案，Isr 是当前同步中的副本，两者必须一致才健康

第三步：端到端收发验证

# 创建测试 topic kafka-topics.sh --bootstrap-server kafka1:9092 --create --topic smoke-test --partitions 3 --replication-factor 3 # 启动控制台 Producer（输入几行文本） kafka-console-producer.sh --bootstrap-server kafka1:9092 --topic smoke-test # 启动控制台 Consumer（应立刻收到消息） kafka-console-consumer.sh --bootstrap-server kafka1:9092 --topic smoke-test --from-beginning --max-messages 10

注意：--from-beginning只对新 Group 有效。如果之前有同名 Group，需加--group smoke-test-group-$(date +%s)用新 Group 测试。

4. 超详细图解：从一条消息的诞生到被消费，全程可视化追踪

文字描述再细，不如一张图看清数据流向。下面这张图，是我给某公司运维团队培训时手绘的简化版（已脱敏），它展示了从 Producer 发送一条消息，到 Consumer Group 中某个实例最终消费的完整链路，每个环节标注了关键动作和潜在瓶颈点。

+----------------+ +---------------------+ +------------------+ +----------------------+ | Producer | | Kafka Cluster | | ZooKeeper | | Consumer Group | | | | | | | | | | 1. 构造Record |---->| a. 接收请求 |<---->| a. 存 broker 元数据 |<---->| 1. Join Group | | (key,value) | | b. 查找 Leader | | b. 存 topic/partition | | 2. Sync Group | | 2. 序列化 | | c. 写入 Leader log | | c. 存 controller info | | 3. 分配 Partition | | 3. 轮询/Hash | | d. Follower 拉取 | | | | 4. Fetch 数据 | | 4. 发送批次 |<----| e. 更新 ISR | | |<----| 5. Commit offset | +----------------+ +----------+--------+ +------------------+ +----------------------+ | | 6. Controller 选举（若 Leader 宕机） v +-------------------+ | New Leader | | (原 Follower) | +-------------------+

现在，我们沿着这条链路，逐帧拆解一条消息的“生命旅程”：

4.1 Producer 侧：四步完成“交付承诺”

Step 1：Metadata 获取
Producer 启动时，先向任一 broker（bootstrap.servers中指定）发送MetadataRequest，获取集群元数据：有哪些 broker、哪些 topic、每个 topic 的 partition 分布、每个 partition 的 leader 在哪。这个过程会缓存，后续发送消息时直接查缓存，避免每次请求都走网络。

Step 2：Key Hash 与 Partition 选择
Producer 根据partitioner.class（默认DefaultPartitioner）计算分区：

• 若 Record 有 Key，用hash(key) % numPartitions确定分区；
• 若无 Key，用轮询（RoundRobin）或粘性（Sticky）策略。

实操心得：业务上要求“同用户事件有序”，必须确保 Key 是用户 ID，且不能为 null。我们曾发现一个 SDK 把 Key 设为 UUID，导致同一用户事件分散在多个 Partition，下游无法按时间聚合。

Step 3：RecordAccumulator 攒批
消息进入RecordAccumulator（内存缓冲区），按<topic,partition>分桶。当满足以下任一条件，批次（RecordBatch）被封装准备发送：

• batch.size达到（如 16KB）；
• linger.ms超时（如 20ms）；
• send.buffer.bytes（socket 发送缓冲区）满。

Step 4：NetworkClient 发送与重试
NetworkClient将批次发往 Leader broker。若失败（如网络超时、Leader 切换），根据retries和retry.backoff.ms重试。若开启幂等（enable.idempotence=true），Producer 会为每个<PID,Epoch>维护一个序列号，broker 校验序列号防止重复。

4.2 Broker 侧：五道关卡守护数据可靠

Gate 1：Socket Server 接收
SocketServer线程池接收请求，放入RequestChannel队列，由KafkaRequestHandlerPool中的ApiHandler线程处理。

Gate 2：Log Manager 写入
LogManager找到对应 Partition 的 Log，将消息追加到当前活跃的 LogSegment 的.log文件末尾。同时更新.index文件（稀疏索引）。

Gate 3：Replica Manager 同步
ReplicaManager检测到新消息，通知所有 Follower。Follower 通过FetchRequest主动拉取数据，Leader 收到后更新其 ISR 列表。

Gate 4：Controller 监控与仲裁
Controller持续监听 ZooKeeper 中/brokers/ids和/brokers/topics节点。当发现某 Follower 落后超过replica.lag.time.max.ms（默认 10 秒），将其踢出 ISR；若 Leader 宕机，则从 ISR 中选新 Leader。

Gate 5：Group Coordinator 管理消费
每个 broker 内置GroupCoordinator，负责管理 Consumer Group。当 Consumer 发送JoinGroupRequest，Coordinator 分配 Partition；发送SyncGroupRequest，下发分配结果；Consumer 提交 offset 时，Coordinator 将其写入内部 topic__consumer_offsets。

4.3 Consumer 侧：三阶段实现“可控消费”

Phase 1：Group 协作（Rebalance）
Consumer 启动时，向 GroupCoordinator 发送JoinGroupRequest，Coordinator 选出 Leader Consumer（第一个加入的）。Leader 拿到所有成员信息后，执行分区分配策略（Range、RoundRobin、Sticky），再通过SyncGroupRequest将分配结果广播给所有成员。

注意：Rebalance 是重量级操作，期间所有 Consumer 暂停消费。因此要避免频繁 Rebalance：确保session.timeout.ms（默认 10s）大于max.poll.interval.ms（默认 5 分钟），且 Consumer 的poll()调用间隔不能超时。

Phase 2：数据拉取（Fetch）
Consumer 根据分配到的 Partition，向对应 Leader broker 发送FetchRequest，携带当前 offset。Broker 返回一批消息（fetch.min.bytes控制最小返回量，fetch.max.wait.ms控制最大等待时间）。

Phase 3：Offset 提交（Commit）
Consumer 处理完一批消息后，调用commitSync()（同步阻塞）或commitAsync()（异步）。Offset 被提交到__consumer_offsetstopic，由 GroupCoordinator 持久化。enable.auto.commit=true时，Consumer 会按auto.commit.interval.ms（默认 5s）自动提交。

关键经验：commitSync()在提交失败时会重试，但若 Consumer 在重试中崩溃，可能造成重复消费；commitAsync()不重试，需配合回调函数处理失败。我们线上采用commitAsync()+ 回调重试commitSync()的混合策略，平衡性能与可靠性。

5. 部署后的第一周：必须做的七项健康巡检与调优动作

集群上线不是结束，而是观察期的开始。我给自己定了一条铁律：新 Kafka 集群上线后第一周，每天必须完成这七项巡检，连续七天无异常，才算初步稳定。

5.1 检查 JVM GC 行为：G1GC 的停顿时间是生命线

Kafka 对 GC 停顿极其敏感。jstat是你的第一道哨兵：

# 每 2 秒查看一次 GC 统计（替换 pid 为 Kafka 进程 ID） jstat -gc -h10 <pid> 2s

重点关注：

• G1YGCT：Young GC 次数，每分钟 > 10 次说明 Eden 区太小；
• G1FGCT：Full GC 次数，必须为 0，出现即严重问题；
• G1YGC和G1FGC的Time列：Young GC 停顿应 < 100ms，Full GC 停顿 > 1s 就危险。

若发现 Full GC，立即导出堆 dump：

jmap -dump:format=b,file=/tmp/kafka-heap.hprof <pid>

然后用 VisualVM 分析，90% 的原因是ByteBuffer泄漏（如 Producer 配置了过大的buffer.memory且消息发送慢）或日志框架（Log4j2）的异步 Appender 队列堆积。

5.2 监控磁盘 IO：iostat 是比 Kafka Metrics 更早的预警器

Kafka 的瓶颈常在磁盘。用iostat看真实压力：

# 每 5 秒刷新一次，重点关注 await, %util, r/s, w/s iostat -x -d /dev/nvme0n1 5

• await> 20ms：单次 IO 响应过慢，可能是磁盘故障或 IOPS 超限；
• %util> 90%：磁盘持续满负荷，需扩容或优化写入模式；
• w/s（每秒写次数）对比磁盘标称 IOPS：SSD 通常 30000+，若接近上限，说明写入过载。

我们曾在一个集群发现await稳定在 45ms，检查磁盘 SMART 信息，发现Media_Wearout_Indicator已低于阈值，果断更换硬盘。

5.3 验证副本同步：kafka-topics.sh --describe是每日必查

每天执行：

kafka-topics.sh --bootstrap-server kafka1:9092 --describe | \ awk '/Isr:/ && $NF != $(NF-1) {print $2,$4,$NF,$(NF-1)}'

这条命令找出所有Isr（同步副本）与Replicas（分配副本）不一致的 Partition。正常情况应无输出。若有输出，说明有副本同步滞后，需立即排查：

• 对应 broker 是否 CPU/IO 过载？
• 网络是否丢包？ping -c 10 <broker-ip>看丢包率；
• replica.fetch.response.max.bytes是否过小，导致大消息拉取失败？

5.4 检查 Consumer Lag：kafka-consumer-groups.sh揭露真实水位

Consumer Lag（消费延迟）是业务健康的晴雨表。每天定时检查关键 Group：

kafka-consumer-groups.sh --bootstrap-server kafka1:9092 \ --group payment-processor --describe | \ awk '$5 != "-" {sum += $5} END {print "Total Lag:", sum}'

• LAG列为 0：完美；
• LAG持续增长：下游处理慢或 Consumer 实例不足；
• LAG突然归零：可能是 Consumer 重启后从头消费（auto.offset.reset=earliest生效），或是 offset 被手动重置。

实战技巧：用--state参数看 Group 状态，Stable表示正常，PreparingRebalance或CompletingRebalance时间过长（> 30s），说明网络或配置有问题。

5.5 审计 Topic 策略：避免“野 Topic”拖垮集群

新 Topic 往往不按规范创建。每天扫描：

kafka-topics.sh --bootstrap-server kafka1:9092 --list | \ while read topic; do kafka-topics.sh --bootstrap-server kafka1:9092 --describe --topic "$topic" 2>/dev/null | \ awk -v t="$topic" '$1==t && $3<3 {print t,"replication.factor=" $3 " < 3"}' done

强制所有 Topicreplication.factor >= 3。曾有团队用脚本自动创建 Topic，replication.factor写死为 1，结果一个 broker 故障，所有相关业务中断。

5.6 验证 ZooKeeper 健康：mntr命令是无声的哨兵

ZooKeeper 的mntr命令返回关键指标：

echo mntr | nc zk1 2181 | grep -E "(zk_avg_latency|zk_max_latency|zk_num_alive_connections|zk_outstanding_requests)"

• zk_avg_latency> 10ms：ZooKeeper 响应慢，检查磁盘和网络；
• zk_outstanding_requests> 10：请求积压，可能 ZooKeeper 负载过高；
• zk_num_alive_connections持续增长：可能有 Consumer 未正确关闭连接，导致句柄泄漏。

5.7 压测与基线建立：用kafka-producer-perf-test.sh定义你的 SLO

上线第三天，必须做一次基线压测，定义你的集群能力：

# 模拟 100 个 Producer，每秒 1 万条，消息 1KB，持续 5 分钟 kafka-producer-perf-test.sh \ --topic perf-test \ --num-records 3000000 \ --record-size 1024 \ --throughput 10000 \ --producer-props bootstrap.servers=kafka1:9092 acks=all \ --print-metrics

记录关键指标：

• Records sent per second：实际吞吐；
• Average latency ms：平均延迟；
• Max latency ms：P99 延迟；
• 95th percentile latency ms：业务可接受延迟。

这个基线将成为后续扩容、故障分析的黄金标准。比如，当线上 P99 延迟从 20ms 升到 150ms，你就知道：不是业务突增，而是底层出了问题。

最后分享一个血泪教训：某次我们跳过基线压测，直接上线。一周后大促，流量翻倍，Kafka 延迟飙升，紧急扩容才发现——新 broker 的磁盘 IOPS 只有旧集群的 1/3，因为采购时没核对 SSD 型号。从此，基线压测成了我们上线 checklist 的第一条。