1. 为什么说Kafka不是“又一个消息队列”而是一套重新定义数据流动的基础设施你打开任何一家中型以上公司的技术栈图谱Kafka 几乎都稳居数据中枢位置——它不只在“发消息”更在持续吞吐、缓冲、重放、分发每一条业务事件用户点击、订单创建、库存变更、风控打标、实时推荐特征更新……这些原本散落在各服务日志里的“毛细血管级”数据流在 Kafka 里被统一建模为不可变、有序、可重放的时间序列事件流。这和 RabbitMQ 或 RocketMQ 的“队列-消费者”范式有本质区别后者关注“任务是否被处理”前者关注“数据是否被完整、一致、可控地流转”。我最早接触 Kafka 是在某高校实验室做模拟项目X时团队用传统 HTTP 接口同步订单状态结果促销活动一开下游库存服务直接雪崩。后来换成 Kafka把“下单成功”这个事件作为 Topic 发出去库存、物流、积分、风控四个系统各自订阅互不阻塞——哪怕库存服务宕机两小时重启后自动从上次 offset 拉取积压数据整个链路零丢失、零人工干预。那一刻我才真正理解Kafka 的核心价值从来不是“快”而是确定性——对数据位置的确定性offset、对分区顺序的确定性partition-level ordering、对消费进度的确定性commit 语义、对集群状态的确定性ZooKeeper/KRaft 协调。标题里写“Kafka私房菜”不是指教你怎么敲几行命令跑起来而是带你拆开它的“灶台”看清楚 Producer 怎么把数据切成块塞进 PartitionConsumer 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强制同用户事件落到同一 PartitionReplica 是冗余副本每个 Partition 有多个 Replica含 1 个 Leader N-1 个 FollowerLeader 处理所有读写Follower 异步/半同步拉取数据。这里藏着一个易错点min.insync.replicas2意味着写入必须等至少 2 个副本落盘才返回成功但如果只有 2 个副本且其中一个宕机Producer 就会卡住——所以生产环境replication.factor至少设为 3min.insync.replicas设为 2留出 1 个副本容错空间。实测过一个案例某公司把replication.factor设为 2集群运行半年无事直到一次磁盘故障导致一个 broker 离线所有写入瞬间失败。他们翻文档才发现acksallmin.insync.replicas2在双副本下等于“全有或全无”毫无弹性。后来改成三副本故障时自动降级为两副本写入业务完全无感。2.2 第二层Producer-Consumer-Group 模型——解决“一对多分发如何兼顾吞吐与语义准确”这一层决定了数据怎么“进”和怎么“出”也是最容易踩坑的地方。Producer 的核心参数不是bootstrap.servers而是这三个acks0发完即忘最快但可能丢、1Leader 写成功即返回平衡点、allISR 中所有副本写成功最安全但最慢retries和retry.backoff.ms网络抖动时自动重试但注意若enable.idempotencetrue开启幂等重试不会造成重复否则需业务层去重batch.size和linger.ms攒批发送。batch.size1638416KBlinger.ms20是常见组合实测在千兆网卡下吞吐提升 3~5 倍延迟增加不到 20ms。Consumer 的灵魂在 Group同一 Group 内多个 Consumer 实例自动分配 PartitionRebalance实现并行消费Offset 由 Group 维护不是单个 Consumer。所以你重启一个 Consumer 实例它会从 Group 记录的 offset 继续读而非从头开始关键陷阱auto.offset.resetearliest从头读和latest从最新读只在 Group 第一次启动或 offset 不存在时生效。一旦 Group 有提交记录这个参数就失效了——很多人误以为改了它就能“重放历史数据”结果发现毫无作用。我们曾在线上遇到一个诡异问题新上线的风控 Consumer Group 连续三天没收到任何数据。排查发现开发在测试环境用earliest启动过一次触发了 offset 提交线上环境复用同一 Group IDKafka 就默认从那个“测试 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 的 ISRIn-Sync Replicas列表当 Follower 落后太多replica.lag.time.max.ms10000默认值Controller 就把它踢出 ISRLeader 选举当 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.hours168。这意味着查找 offset123456789 的消息Kafka 先通过二分法在.index中定位到该 offset 所在的 segment再根据索引项找到.log中的字节偏移量最后读取——整个过程 O(log N)与数据总量无关。我们压测过10TB 数据盘随机查任意 offsetP99 延迟稳定在 3ms 内。但这也带来运维细节.index文件大小直接影响内存占用。默认index.interval.bytes4096如果消息极小如 100 字节索引密度就太高1TB 数据可能生成 2GB 索引文件。这时可调大index.interval.bytes到 8192 或 16384用少量定位精度换内存。3. ZooKeeper Kafka 集群部署不是“照着文档配”而是“带着故障预案配”部署 Kafka 集群不是终点而是运维长跑的起点。我见过太多团队把 Kafka 部署在虚拟机上三台机器共用一块 SSD结果一次磁盘 I/O 飙升整个集群假死。真正的部署必须从第一天就预设“哪里会坏”。3.1 硬件与系统层绕不开的五个硬约束Kafka 对硬件有明确偏好违背它等于自埋地雷约束项推荐配置违反后果实测案例磁盘类型SAS/SATA SSD禁用 HDDHDD 随机写 IOPS 200Kafka 写入卡顿某公司用旧服务器 HDD 部署压测 5000 msg/s 就出现Request timeout磁盘挂载参数noatime,nobarrier,deadlineatime更新引发额外 IObarrier降低写性能加noatime后相同负载下 IOWait 降低 35%JVM 堆内存≤ 6GB用 G1GC堆过大导致 GC 停顿超 1s心跳超时被踢出集群一台 broker 设 12G 堆GC 时频繁Marking Phase日志满屏Failed to send heartbeat文件描述符ulimit -n 100000默认 1024连接数超限直接拒绝新 Producer测试环境未调优200 个 Consumer 连接就报Too many open files网络带宽千兆网卡起步跨机房部署必用万兆单 broker 网络打满副本同步延迟飙升双机房 Kafka用千兆互联replica.fetch.wait.max.ms频繁触发特别提醒永远不要把 ZooKeeper 和 Kafka Broker 部署在同一台物理机上。ZooKeeper 对延迟极度敏感会话超时默认 40sKafka 的批量刷盘和 GC 会干扰 ZooKeeper 的心跳检测导致 ZooKeeper 频繁假死进而引发 Kafka 元数据混乱。3.2 ZooKeeper 集群部署三节点是底线五节点是甜点ZooKeeper 必须奇数节点防脑裂生产环境最低三节点推荐五节点容忍两节点故障。部署要点独立磁盘ZooKeeper 的dataDir和dataLogDir必须分盘dataLogDir事务日志务必放在高速 SSDJVM 参数-Xms2G -Xmx2G -XX:UseG1GC堆内存严禁超过 4G配置关键项tickTime2000 initLimit10 syncLimit5 autopurge.purgeInterval24tickTime是 ZooKeeper 心跳基本单位initLimit表示 follower 连接 leader 的最长时间单位 tickTimesyncLimit是 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% 的性能与稳定性问题参数名推荐值为什么这么设踩坑实录broker.id唯一整数手动生成避免 auto-generate 在重启时冲突某团队用autobroker 重启后 id 变ZooKeeper 认为是新节点旧元数据残留listenersPLAINTEXT://:9092内网SSL://:9093外网明确区分内外网访问通道混用导致 SSL 配置错误Consumer 连不上advertised.listeners写客户端实际访问的 IP端口Client 通过此地址连回 broker不是listeners写成localhostDocker 外部 Consumer 死活连不上num.network.threads3处理 socket 请求的线程数一般 2~3 足够设 10线程上下文切换反拖慢性能num.io.threads8SSD或16NVMe处理磁盘 IO 的线程数匹配磁盘并发能力HDD 上设 16IO 线程空转耗 CPUlog.dirs/data/kafka-logs独立 SSD日志目录必须独立于系统盘和/var/log共盘磁盘满导致 Kafka 拒绝写入default.replication.factor3新建 Topic 默认副本数设 1单点故障即丢数据min.insync.replicas2ISR 中最少副本数配合acksall设 1等于放弃强一致性log.retention.hours1687天或按业务定控制磁盘用量避免无限增长设-1永不过期3个月后磁盘爆满其中advertised.listeners是最高频错误点。举个真实例子某公司在 Kubernetes 部署 Kafkalisteners设PLAINTEXT://0.0.0.0:9092advertised.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 1Metadata 获取Producer 启动时先向任一 brokerbootstrap.servers中指定发送MetadataRequest获取集群元数据有哪些 broker、哪些 topic、每个 topic 的 partition 分布、每个 partition 的 leader 在哪。这个过程会缓存后续发送消息时直接查缓存避免每次请求都走网络。Step 2Key Hash 与 Partition 选择Producer 根据partitioner.class默认DefaultPartitioner计算分区若 Record 有 Key用hash(key) % numPartitions确定分区若无 Key用轮询RoundRobin或粘性Sticky策略。实操心得业务上要求“同用户事件有序”必须确保 Key 是用户 ID且不能为 null。我们曾发现一个 SDK 把 Key 设为 UUID导致同一用户事件分散在多个 Partition下游无法按时间聚合。Step 3RecordAccumulator 攒批消息进入RecordAccumulator内存缓冲区按topic,partition分桶。当满足以下任一条件批次RecordBatch被封装准备发送batch.size达到如 16KBlinger.ms超时如 20mssend.buffer.bytessocket 发送缓冲区满。Step 4NetworkClient 发送与重试NetworkClient将批次发往 Leader broker。若失败如网络超时、Leader 切换根据retries和retry.backoff.ms重试。若开启幂等enable.idempotencetrueProducer 会为每个PID,Epoch维护一个序列号broker 校验序列号防止重复。4.2 Broker 侧五道关卡守护数据可靠Gate 1Socket Server 接收SocketServer线程池接收请求放入RequestChannel队列由KafkaRequestHandlerPool中的ApiHandler线程处理。Gate 2Log Manager 写入LogManager找到对应 Partition 的 Log将消息追加到当前活跃的 LogSegment 的.log文件末尾。同时更新.index文件稀疏索引。Gate 3Replica Manager 同步ReplicaManager检测到新消息通知所有 Follower。Follower 通过FetchRequest主动拉取数据Leader 收到后更新其 ISR 列表。Gate 4Controller 监控与仲裁Controller持续监听 ZooKeeper 中/brokers/ids和/brokers/topics节点。当发现某 Follower 落后超过replica.lag.time.max.ms默认 10 秒将其踢出 ISR若 Leader 宕机则从 ISR 中选新 Leader。Gate 5Group Coordinator 管理消费每个 broker 内置GroupCoordinator负责管理 Consumer Group。当 Consumer 发送JoinGroupRequestCoordinator 分配 Partition发送SyncGroupRequest下发分配结果Consumer 提交 offset 时Coordinator 将其写入内部 topic__consumer_offsets。4.3 Consumer 侧三阶段实现“可控消费”Phase 1Group 协作RebalanceConsumer 启动时向 GroupCoordinator 发送JoinGroupRequestCoordinator 选出 Leader Consumer第一个加入的。Leader 拿到所有成员信息后执行分区分配策略Range、RoundRobin、Sticky再通过SyncGroupRequest将分配结果广播给所有成员。注意Rebalance 是重量级操作期间所有 Consumer 暂停消费。因此要避免频繁 Rebalance确保session.timeout.ms默认 10s大于max.poll.interval.ms默认 5 分钟且 Consumer 的poll()调用间隔不能超时。Phase 2数据拉取FetchConsumer 根据分配到的 Partition向对应 Leader broker 发送FetchRequest携带当前 offset。Broker 返回一批消息fetch.min.bytes控制最小返回量fetch.max.wait.ms控制最大等待时间。Phase 3Offset 提交CommitConsumer 处理完一批消息后调用commitSync()同步阻塞或commitAsync()异步。Offset 被提交到__consumer_offsetstopic由 GroupCoordinator 持久化。enable.auto.committrue时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重点关注G1YGCTYoung GC 次数每分钟 10 次说明 Eden 区太小G1FGCTFull GC 次数必须为 0出现即严重问题G1YGC和G1FGC的Time列Young GC 停顿应 100msFull GC 停顿 1s 就危险。若发现 Full GC立即导出堆 dumpjmap -dump:formatb,file/tmp/kafka-heap.hprof pid然后用 VisualVM 分析90% 的原因是ByteBuffer泄漏如 Producer 配置了过大的buffer.memory且消息发送慢或日志框架Log4j2的异步 Appender 队列堆积。5.2 监控磁盘 IOiostat 是比 Kafka Metrics 更早的预警器Kafka 的瓶颈常在磁盘。用iostat看真实压力# 每 5 秒刷新一次重点关注 await, %util, r/s, w/s iostat -x -d /dev/nvme0n1 5await 20ms单次 IO 响应过慢可能是磁盘故障或 IOPS 超限%util 90%磁盘持续满负荷需扩容或优化写入模式w/s每秒写次数对比磁盘标称 IOPSSSD 通常 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 Lagkafka-consumer-groups.sh揭露真实水位Consumer Lag消费延迟是业务健康的晴雨表。每天定时检查关键 Groupkafka-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.resetearliest生效或是 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 $1t $33 {print t,replication.factor $3 3} done强制所有 Topicreplication.factor 3。曾有团队用脚本自动创建 Topicreplication.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 10msZooKeeper 响应慢检查磁盘和网络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.serverskafka1:9092 acksall \ --print-metrics记录关键指标Records sent per second实际吞吐Average latency ms平均延迟Max latency msP99 延迟95th percentile latency ms业务可接受延迟。这个基线将成为后续扩容、故障分析的黄金标准。比如当线上 P99 延迟从 20ms 升到 150ms你就知道不是业务突增而是底层出了问题。最后分享一个血泪教训某次我们跳过基线压测直接上线。一周后大促流量翻倍Kafka 延迟飙升紧急扩容才发现——新 broker 的磁盘 IOPS 只有旧集群的 1/3因为采购时没核对 SSD 型号。从此基线压测成了我们上线 checklist 的第一条。