搞大数据这行，基本绕不开 Kafka 这关。无论是日志采集、实时数仓，还是 Flink/Spark 的数据入口，Kafka 集群都是整个数据管道里最核心的“运输大脑”。但很多朋友一上来就急着装个单机版，跑了 demo 就觉得会了，结果一到真实环境就翻车。最典型的就是 topic 创建失败、生产者连不上 broker、消费组跨节点分发不对这些坑。
这篇东西，就是给你梳理一套真正能落地的大数据环境 Kafka 集群搭建方案。我会从集群设计、节点规划、核心配置讲起，把主子配置的“为什么”拆开讲，再带上启动验证、生产消费测试和常见故障排查。这篇内容不挑人群——无论是刚入行的大数据开发、要做实时架构的技术负责人，还是准备面试被问“Kafka 集群怎么搭”的求职者，都能在里面找到可以直接用的东西。
1. 动手之前，先想清楚集群到底在解决什么问题
1.1 从单机到集群，你撞上的第一堵墙
很多人最开始学 Kafka 的时候，在本机解压、改两行配置、启动 ZK，表面一切顺利。但等你真往日志采集、实时同步这种生产场景里一放，单机的坑立刻暴露出来：磁盘写满了怎么办？broker 挂了消息是不是就全丢了？topic 分区数一上来吞吐量断崖式下跌？
这不是 Kafka 本身的问题，而是单机模式的物理天花板。Kafka 集群的根基，就是把多台机器的磁盘、内存、CPU 聚合成一个逻辑上的“大管道”，同时通过副本机制保证一台机器挂了，数据还能从别的副本继续读。你可以把单机式的 Kafka 理解为一个小卖部，货架就那么大，老板就一个人；而集群更像是连锁超市，有多个仓库，某个仓失火了，别的仓还能顶上继续供货。
从运维层面看，集群还承担了“水平扩展”的角色。数据量大了不需要换更贵的服务器，直接加 broker 节点就能分担分区流量。所以你在规划之前，一定要想清楚自己的真实场景是侧重吞吐容量、数据可靠性，还是两者都要，这对后面的副本因子、分区设计、节点规模影响很大。
1.2 数据在集群里是怎么流转的
简单过一遍核心概念，后面配置才看得懂。
Kafka 集群由多个 broker 组成，每个 broker 就是一台运行 Kafka 进程的服务器。数据写入到“主题（topic）”，这个主题会被切分成若干个“分区（partition）”，每个分区有多个“副本（replica）”。副本里有一个 leader，其余是 follower。生产者和消费者只跟 leader 副本交互，follower 负责把 leader 的数据同步过来，一旦 leader 所在的 broker 宕机，会从 follower 中快速选举出一个新的 leader 继续对外服务。
一个 topic 的多分区设计，本质上解决的是并行度问题。如果数据全挤在一个分区里，生产和消费都只能串行处理；分区数多了，集群可以把不同分区调度到不同 broker 上，多条数据流就能并行跑，吞吐量自然上去。这也是为什么“集群”和“分区”是一对天生的搭档：有分区还不够，得多个节点托底，分区调度才有意义。
1.3 搭建前必须定下来的三件事
第一件是版本。很多教程还在教 ZooKeeper 模式，但实际上从 Kafka 2.8 开始引入了 KRaft 模式，到 Kafka 3.x 这代已经可以在生产环境里不必再依赖 ZK，新版本如 3.5、3.6 的 KRaft 成熟度已经比较高了。我的建议是新项目直接上 KRaft 模式，存量系统如果还在 ZK 模式也不用急着切换，等大版本升级一起过渡。
第二件是节点数量与资源评估。常规生产环境至少三台 broker 起步，才能保证 leader 选举的高可用。每台机器的配置建议至少 16GB 内存、4 核以上 CPU，磁盘要看数据的保留周期和单日增量来算，比如日增 500GB、保留 3 天就得预留 2TB 左右的存储余量。这里的核心逻辑是给日志预留足够空间，磁盘满导致的 broker 崩溃是最常见的事故元凶之一。
第三件是副本因子设计。如果三台 broker，我一般推荐 topic 的副本因子设置为 3，这样一台机器宕机，还有两个副本兜底，生产者和消费者不感知；两副本虽然省磁盘，但一旦其中一个副本所在的节点坏掉，就会出现“单副本”状态，可靠性大打折扣。磁盘成本翻倍，但换来的数据安全在多数业务场景下是值得的。
2. 环境准备：依赖、版本和节点规划
2.1 操作系统与 JDK 版本
Kafka 是纯 Java 实现的服务，对 JDK 版本有明确要求。如果你是 Kafka 3.x，建议用 JDK 11 或 17；如果是 Kafka 2.x 老版本，JDK 8 也能跑。我自己常用 CentOS 7.9/Rocky Linux 8 这类系统，JDK 直接用 OpenJDK 11，生产环境跑了几年没出过因 JDK 导致的 Kafka 问题。
注意：安装 Kafka 前，先在每台机器上执行
java -version确认 JDK 版本。别拿到一台机器就开干，遇到过很多次因为某台节点的 JDK 版本不一致，启动后表现各种诡异的。
JDK 装好后，建议大家统一设置 JAVA_HOME 环境变量，最好写进/etc/profile，因为后面启动脚本找 Java 时会优先使用这个变量。
2.2 三节点规划示例
假设我们用三台服务器，内网 IP 分别为：
| 节点 | 主机名 | 角色 | 内网 IP |
|---|---|---|---|
| 节点1 | kafka-1 | broker + controller | 192.168.10.11 |
| 节点2 | kafka-2 | broker + controller | 192.168.10.12 |
| 节点3 | kafka-3 | broker + controller | 192.168.10.13 |
主机名一定要改好，而且三台机器的/etc/hosts要互相解析，否则后续 broker 之间通过主机名握手会超时失败。防火墙层面，如果你用 KRaft 模式，需要放行 9092（客户端端口）和 9093（controller 通信端口），如果用 ZooKeeper 模式还需要放行 2181。
还有一个经常被忽略的网络细节：broker 之间、客户端与 broker 之间的网络要保证尽量低延迟，不能跨公网通信。Kafka 对网络的稳定性要求不低，丢包率高的时候副本同步会一直跟不上，ISR 收缩，leader 频繁切换，整个集群性能都会出问题。
2.3 架构选型：一定要用 ZooKeeper 吗
关于 ZK 和 KRaft 的对比，直接说结论：
| 对比项 | ZooKeeper 模式 | KRaft 模式 |
|---|---|---|
| 元数据存储 | 外部 ZooKeeper | Kafka 内部自行管理 |
| 组件数量 | 需要额外部署 ZK 集群 | 不需要，部署更轻量 |
| 元数据迁移 | 依赖 ZK 同步 | 内部协议同步，延迟更低 |
| 运维复杂度 | 高，多一个集群要维护 | 低，管控简单 |
| 生产可用度 | 成熟 | 新版本（3.5+）生产可用 |
ZooKeeper 时代的 Kafka，你想要高可用必须先保证 ZK 本身是集群。但 ZK 集群的选主逻辑、JVM 参数、故障恢复其实又是一套独立的运维体系，很多人搭 Kafka 集群最后栽在了 ZK 上。KRaft 模式把元数据管理收回到 Kafka 自身，controller 节点直接从 broker 里选出来，部署和运维都简单很多。
如果你是非生产环境或者新建生产集群，我强烈建议直接 KRaft 模式。如果你是面试场景被别人问“Kafka 集群怎么搭”，两种模式你都得能聊清楚，但实操层面就按这套走。
3. 核心配置文件逐项拆解
3.1 以 KRaft 模式为例的 server.properties
Kafka 安装包解压后，主要关注三个目录下的文件：bin（脚本）、config（配置）、libs（依赖）。KRaft 模式下不需要再部署 ZK，一切核心配置都在config/server.properties里。下面是我在一套三节点集群上用的配置模板：
# 每个节点的唯一 ID，必须不重复 process.roles=broker,controller node.id=1 # controller 通信端口（9093）与客户端端口（9092） listeners=PLAINTEXT://:9092,CONTROLLER://:9093 inter.broker.listener.name=PLAINTEXT advertised.listeners=PLAINTEXT://192.168.10.11:9092 controller.listener.names=CONTROLLER listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT # controller 集群成员，格式 node.id@host:port controller.quorum.voters=1@192.168.10.11:9093,2@192.168.10.12:9093,3@192.168.10.13:9093 # 数据目录 log.dirs=/data/kafka-logs # 分区与副本默认配置 num.partitions=3 default.replication.factor=2 offsets.topic.replication.factor=2 transaction.state.log.replication.factor=2 transaction.state.log.min.isr=1 # 日志保留策略 log.retention.hours=72 log.segment.bytes=1073741824几个关键参数要给读者拆开讲。node.id是每个 broker 在集群内的唯一标识，这个 ID 会被写入到数据目录的 meta.properties 文件，改错会导致节点无法加入集群。controller.quorum.voters是 KRaft 模式下 controller 节点的成员列表，它写的是“谁有资格参与选主”，三节点都配成一样的。
最容易被忽略的是advertised.listeners。这个参数决定了 broker 会把哪个地址告诉给客户端。如果你配的是 localhost，生产者在别的机器上拿到这个地址后就会连接 localhost:9092，结果就是一直报 “Connection refused” 或者是 “Error while fetching metadata with correlation id”。所以生产环境一定要写对外可访问的 IP 或者域名，不要用默认的 localhost。
3.2 ZK 模式需要改哪些配置
如果出于历史原因，你仍然要搭 ZK 模式的集群，配置差别其实不大，主要区别是process.roles、controller.quorum.voters这些参数替换成一行：
zookeeper.connect=192.168.10.11:2181,192.168.10.12:2181,192.168.10.13:2181listeners和advertised.listeners的配置思路和 KRaft 模式一样。另外，ZK 模式下还需要额外部署一套 ZK 集群（建议 3 节点），并在 ZK 的配置文件zoo.cfg里配置：
dataDir=/data/zookeeper server.1=192.168.10.11:2888:3888 server.2=192.168.10.12:2888:3888 server.3=192.168.10.13:2888:3888然后每台机器的数据目录里创建一个myid文件，内容分别写 1、2、3。这套玩法本身不难，但它增加了很多维护动作，比如 ZK 的选举端口 3888 和同步端口 2888 都要暴露，扩容时还要小心处理新旧节点成员关系。这也是为什么我一直鼓励新建集群直接 KRaft。
3.3 log.dirs 与数据盘规划
很多教程只会告诉你要设log.dirs，但不会告诉你到底该怎么设。我踩过坑之后强烈建议：如果机器上有独立的数据盘，一定要把日志目录放在独立盘上，不要跟系统盘放在一起。
原因很好理解：Kafka 的日志文件是顺序写场景，但一个 topic 持续写入就能把磁盘 IO 拉满。系统盘混用的话，操作系统本身也有日志读写，两边的 IO 会互相影响。极端情况下数据盘 IO 满了，Kafka 的写延迟会急剧上升，还可能导致副本同步超时。
具体操作上，先挂载数据盘，比如/data，然后在/data下创建kafka-logs目录，配置里指定：
log.dirs=/data1/kafka-logs,/data2/kafka-logs如果你有两块数据盘，可以都写进去，Kafka 会自动决定分区日志分布在这两个目录中。多目录没有故障切换效果，但能把 IO 压力分散到不同盘符，这也是提升集群吞吐量的一个土办法。
4. 集群启动、验证与常用运维命令
4.1 首次格式化的关键步骤
KRaft 模式下，启动之前必须先做一次存储目录的格式化，这一步会生成 cluster.id。很多人不格式化直接启动，报错 “Storage directory exists and is not empty” 之类的问题，原因就在这里。
具体操作：
# 在每台节点上执行，生成格式化的存储目录 bin/kafka-storage.sh random-uuid # 生成 cluster id bin/kafka-storage.sh format -t <cluster-id> -c config/server.properties建议做法是：先在一台节点上用kafka-storage.sh random-uuid生成一个 Cluster ID，比如t5YbJ0NwS5GGlm8E4Q0gWA，然后在三台节点上分别执行 format 命令，并且-t后面都用同一个 cluster ID。这样整个集群的元数据才能统一。
注意：format 命令必须在数据目录为空时执行。如果数据目录里已经有上次失败的残留文件，先清理干净再格式化，否则启动时可能报错或加载到脏数据。
格式化完成后，按顺序启动。如果是三节点混合模式（broker+controller），哪个节点先启动问题不大，controller 节点之间会自动完成选主。
bin/kafka-server-start.sh -daemon config/server.properties启动后看日志：
tail -f logs/server.log当你看到Kafka Server started这行日志，说明这个 broker 已经加入集群了。
4.2 别急着发消息：用 kafka-topics.sh 验证集群成员
集群启动后，第一件事不是去生产消息，而是验证所有 broker 是否都被正确识别。
# 查看集群所有主题列表 bin/kafka-topics.sh --bootstrap-server 192.168.10.11:9092,192.168.10.12:9092,192.168.10.13:9092 --list # 创建一个测试主题，3分区、3副本 bin/kafka-topics.sh --bootstrap-server 192.168.10.11:9092,192.168.10.12:9092,192.168.10.13:9092 --create --topic test-topic --partitions 3 --replication-factor 3 # 查看测试主题的分区与副本详情 bin/kafka-topics.sh --bootstrap-server 192.168.10.11:9092,192.168.10.12:9092,192.168.10.13:9092 --describe --topic test-topic--describe输出很关键。它展示了每个分区的 Leader、复本节点、ISR 节点。正常情况下三副本，ISR 里应该有 3 个节点。如果 ISR 里只有 1 个或 2 个节点，说明副本同步有问题，得查网络、磁盘、或者副本线程是否异常，不要急着往下走。
还有一点提醒：创建 topic 时指定的replication-factor不能大于 broker 数量。三台 broker 的集群你指定副本因子为 5，系统会直接报错 “Replication factor: 5 larger than available brokers: 3”。
4.3 生产消费连通性测试
集群和 topic 都正常后，用控制台生产者、消费者做一次端到端验证：
# 终端一：启动生产者输入消息 bin/kafka-console-producer.sh --bootstrap-server 192.168.10.11:9092,192.168.10.12:9092,192.168.10.13:9092 --topic test-topic # 终端二：启动消费者接收消息 bin/kafka-console-consumer.sh --bootstrap-server 192.168.10.11:9092,192.168.10.12:9092,192.168.10.13:9092 --topic test-topic --from-beginning生产者终端输入hello kafka，消费者终端能收到，这趟数据链路就算通了一半。为什么说一半？因为这里用的 bootstrap-server 是多个 IP，你要再单独测试一下只填其中一个 IP 的时候，客户端能不能自动发现整个集群。如果指定单节点成功，说明advertised.listeners配对了，broker 能正确把其他节点的地址告诉客户端。
4.4 可视化工具帮你看清集群状态
集群节点多了以后，纯命令行操作越来越不方便，建议装一个可视化界面。我比较常用的是 Kafka UI 和 CMAK（Kafka Manager 的社区分支）。Kafka UI 是 Java 写的，界面更现代化，可以看到 broker 状态、topic 分区、消费组的 lag 情况。CMAK 是老牌的，功能稳定但界面相对复古。
工具本身部署不难，下载对应发行包改下配置就行。需要注意：很多工具需要配置连接集群的 bootstrap-server 地址，比如 Kafka UI 的application.yml：
kafka: clusters: - name: kafka-cluster bootstrapServers: 192.168.10.11:9092,192.168.10.12:9092,192.168.10.13:9092装上这个之后，日常巡检消费组堆积情况就能在页面上一眼看完，不用再挨个敲命令。
5. 运行期调优：别让集群“能用”变成“好用”
5.1 生产端三个关键参数：acks、linger.ms、batch.size
集群跑起来只是第一步，真正让人头疼的是吞吐和时延怎么平衡。先说生产端最核心的三个参数。
acks表示生产者要求多少副本确认写入。acks=0是发完就不管，性能最高但易丢消息；acks=1表示 leader 写入就返回，绝大多数业务默认选择；acks=all表示所有 ISR 副本都写入才返回，数据最安全，但延迟会高一些。
| 参数 | 推荐值 | 使用场景 |
|---|---|---|
| acks | all | 对数据可靠性要求高的场景（金融、订单） |
| acks | 1 | 大部分日志传输、网关异步数据上报 |
| acks | 0 | 允许丢数据、追求极致吞吐的日志采集 |
linger.ms是生产者把消息在内存里攒多久再批量发送。很多人误以为设得越大延迟越高，事实是该参数给了批量发送的机会，能有效提升吞吐。调优经验：在线业务延迟敏感，设 5ms 左右；离线批处理场景，可以设 20~50ms 来攒批。
batch.size控制了批大小，默认 16KB。如果单条消息很小，而又频繁发送，可以适当调大到 32KB 或 64KB。这里有一个权衡：batch 太大会增加内存压力，太小又起不到批量效果。我在实践中一般先监控生产者端的 batch 是否经常“没攒满就发出”，如果单条消息多，就会调大 batch.size。
5.2 缓冲与压缩：别忽略 buffer.memory 和 compression.type
生产端还有两个大项目容易被忽略。
buffer.memory控制生产者可用于缓冲消息的内存大小，默认 32MB。如果写入峰值非常高而分区数又不够，缓冲区很容易很快占满，导致发送线程阻塞或直接报BufferExhaustedException。在数据量大的场景，我通常调大到 64MB 或 128MB，自行确认机器内存足够。
compression.type推荐设置为lz4或zstd。压缩能显著降低网络带宽占用和磁盘存储量，代价是消耗一点 CPU。在 Kafka 集群里，CPU 一般不是第一瓶颈，但 IO 和网络经常是。所以压缩几乎稳赚。用 lz4 还是 zstd？zstd 的压缩比更高但稍费 CPU；如果你的消息体多是 JSON 文本，用 zstd 效果非常明显；如果是二进制数据，lz4 更省 CPU。
5.3 消费端问题：消息延迟高，卡在了谁身上
热词里有一条“kafka 消息延迟高”，这也是生产环境最常见的问题。消息延迟不一定全是 Kafka 集群的问题，很多时候是消费端处理不过来。
排查思路分三段看：先看生产端有没有堆积延迟，再看 broker 端处理是否正常，最后主攻消费端。
消费端最常见的坑是单条消息处理很慢但分区数又少，导致整个消费组都卡在一条消息上。解决方向有两个：一是增加 topic 的分区数，二是优化消费者组的并发模型。如果你已经用 Spring Kafka，可以调大concurrency，让每个 listener 线程对应不同的分区；如果手动消费，要检查处理逻辑里是否有外部接口调用太重，可以把耗时的操作异步化。
还有一个常见原因是max.poll.interval.ms设置太短。消费者在两次 poll 之间处理消息如果超过这个时间，broker 会认为消费者挂掉，触发 rebalance，反而造成消费停止。实测下来，如果单条消息处理要十几秒，最好把这个参数调到 5 分钟以上。
5.4 磁盘与日志保留策略：别让磁盘悄悄打满
日志保留策略直接关系到集群的成长性。默认的log.retention.hours=168（7 天），但这个值不适合所有场景。如果你只是做实时传输，落地数据 72 小时就够了；如果需要回放和离线纠错，可以保留到 7 天甚至更久。
Kafka 的保留不是按记录条数，而是按日志段（segment）来做清理。log.segment.bytes默认 1GB，每个 segment 满了就滚动出一个新文件，清理的最小粒度就是这个 segment 文件。理论上如果想更精细地控制删除节奏，可以适当调小这个值到 512MB，segment 滚动更频繁，但清理时释放空间更快。不过 segment 太小会增加文件数量，对索引查询也有影响，别为了清理把 segment 往死里压。
日志清理策略里还有一个重要参数是log.cleanup.policy。默认是delete，即删除过期数据；如果你用 Kafka 做某些有业务状态的存储，可以配置为compact，只保留每个 key 的最新值。这两种策略按需选择，重点是要明确业务诉求，别一上来就 delete。
6. 常见问题速查与排查实录
6.1 “Error while fetching metadata with correlation id...”元凶排查
这条报错在 Docker 环境更常见，很多朋友把 Kafka 容器起了，然后生产者也连不上，看到满屏的错误信息就慌。这句报错的本质是：客户端向 bootstrap-server 请求元数据失败，或者拿到了无效的 broker 地址。
按我排查的经验，原因优先级排列如下：
- advertised.listeners 配置错误。最典型的就是容器内部的 broker 地址和宿主机地址没对应起来，客户端拿到了容器 IP，自然连不上。
- bootstrap-server 指定的地址本身不通。先确认你填的 IP 和端口，用
telnet 192.168.10.11 9092测一下。 - 防火墙或安全组规则拦截。Kafka 服务端口并未对外开放，客户端跨主机访问失败。
解决套路是：先在报错的那台机器上，手动探测到每个 broker 的 TCP 连接是否通；再在 broker 所在机器上，用kafka-broker-api-versions.sh --bootstrap-server localhost:9092验证 broker 本地接口是否正常；最后检查 advertised.listeners 是否与客户端能访问的地址一致。
6.2 ISR 收缩，副本长期不同步
ISR 全称是 in-sync replicas，代表当前保持同步的副本集合。如果你在--describe里看到副本数量是 3，但 ISR 数量只有 1，那说明另外两个副本追不上 leader 了。
最常见原因是磁盘 IO 过高或网络延迟抖动太大。解决思路：先看top/iostat确认负载，再用kafka-log-dirs.sh检查目录磁盘空间和 log 段分布。磁盘只剩几个 GB 的时候，清理日志（删 topic/调小 retention）能很快缓解。
另一种可能是某个 broker 上的副本线程被卡死。这种时候通常重启该 broker 能恢复，但光重启不治本，你得想清楚为什么这个节点长期“拖后腿”。如果是因为机器配置跟其他节点差距太大，建议要么换同配置机器，要么把高负载 topic 的分区往其他节点迁移。
6.3 节点宕机后集群发生了什么
Kafka 集群高可用是设计目标，但高可用不等于无感知。比如三副本的 topic，某台机器宕机后，broker 上 leader 副本会快速转移到其他节点，生产者在短暂重连后恢复，消费者组触发 rebalance，整个过程一般几十秒内完成。
但这有一个前提：至少有一个同步副本还在。如果宕机的节点恰好是唯一持有最新数据的副本，那其他副本会从高水位之后截断数据，这时候就可能丢消息。所以我们在生产上最好配置min.insync.replicas配合acks=all，比如三副本设置 min.insync.replicas=2，这样只有两个以上副本确认了写入才返回成功，单副本失效后集群会大道拒绝写入而不是悄悄丢失数据。
日常运维建议做一次故障演练：随机停掉一台 broker，观察生产者、消费者日志是否能自动恢复，检查消费 lag 是否回追。真到自己不小心把节点搞挂了，流程熟悉了就不会手足无措。
6.4 延迟 30 分钟消费，这类需求怎么实现
热词里有“kafka 如何延迟30分钟消费”，这是个有意思的场景，常在订单超时、延迟任务里遇到。实现方式一般有三种：
一种是在生产端加时间戳字段，消费端取出来判断当前时间减去事件时间，如果没到预定的时限就做定时重试，到点再处理。这种方式逻辑简单，但要自己管理延迟队列。
另一种是使用 Kafka 提供的 ConsumerRebalanceListener 结合暂停/恢复分区消费，消费端把消息放进延迟队列（如时间轮/DB），定时轮询到时间再处理。
还有一种更工程化的做法：把延迟消息写进一个内部 topic，业务方定时拉取并转投到真正处理消息的 topic。具体方案因团队而异，但我个人体会是，不要让 Kafka 本身承载过强的调度语义，Kafka 只做可靠传输，延迟逻辑放到应用层或专业调度器里更灵活。
写在最后：搭集群这件事，最大的坑是“想得太少”
搭建 Kafka 集群，技术流程其实并不复杂，解压、改配置、格式化、启动，每一步都有清晰的文档。真正决定集群是否有生产价值的，是你搭之前对节点规划、副本因子、保留策略这些问题的思考深度。我见过很多团队兄弟，集群是搭起来了，但副本因子选的 1，数据备份根本不存在；也有人分区数设了 32，实际消费端并行度却只有 2，白白浪费了资源。
我的习惯是：每搭一套新集群，先花半小时在纸上写清楚架构假设——未来一年数据增量多大？允许丢多少消息？消费端并发能支撑多少？想清楚了再动手。集群搭完之后，一定要做一次故障演练，尤其要把 broker 重启、磁盘写满、分区迁移这几条路走一遍。演练时出的小问题，总比业务高峰期真实故障要温柔得多。
最后分享一个小技巧：如果你不确定集群会怎么发展，尽量把advertised.listeners统一配置成内部域名而不是 IP。域名方案在集群扩容、机器迁移时会省掉你重新改客户端配置的麻烦。骨架拉好了，后面往里面加节点、加 topic 都只是例行操作，真正考验功力的，永远是“设计”和“排障”这两件事。
