1. 先搞清楚Kafka的骨架Producer与Consumer在整套体系里的位置很多人一聊Kafka就甩出高吞吐分布式消息队列这些标签但真到自己动手搭集群、写生产者消费者代码的时候往往被一堆概念卡住Topic、Partition、Offset、Consumer Group、Rebalance……每个词都认识连起来就不知道谁管谁了。我的建议是别急着敲代码先花半天把Kafka的定位看明白。Kafka本质上是一个分布式的、分区的、多副本的提交日志Commit Log系统。一条消息从业务系统产生到最终被另一个系统处理中间要经过三个角色Producer生产者负责把消息发到Broker、BrokerKafka服务节点负责存储和转发、Consumer消费者负责从Broker拉取消息并处理。这套模型和传统RabbitMQ那种消息即任务、消费完即删除的思路完全不同——Kafka的消息是按照日志的方式存的消费完之后默认并不会被删掉而是靠消费者自己维护一个叫Offset位移的指针读到哪儿就记到哪儿。这个设计带来的第一个好处就是消费方可以随时回溯。比如你前一天写了个有bug的消费逻辑把消息处理错了第二天修完代码把Offset重置到前一天就能重新消费一遍。这在数据同步、数仓入湖这种场景里简直是救命功能。另一个关键设计是Partition分区。每个Topic会被拆成若干个分区分区是Kafka并行处理的最小单位。Producer发消息时可以显式指定分区也可以让Kafka按key哈希或轮询策略自动分配Consumer这边一个分区在同一个消费组内只能被一个消费者实例持有。换句话说分区的数量决定了这个Topic的最大并行度——你开了10个消费者但Topic只有一个分区那同一时刻只有一个消费者在工作其余9个都在空转。这里要澄清一个常见误解很多人以为Consumer从Broker拉消息和Producer往Broker推消息是对等的两个方向其实Kafka全部走的是拉模型Consumer主动去Broker拉数据Broker永远不会主动往Consumer推。这样做的好处是消费者可以根据自己的处理能力控制拉取节奏不会出现消息把消费者压垮的情况代价是实时性比推模型要差一点需要通过轮询频率来弥补。下面我用一张简表把这几个核心概念的关系梳理一下后面所有实战操作都建立在这套模型之上概念作用类比解释Topic消息的逻辑分类类似数据库里的表PartitionTopic的物理分片类似表的分库分表分片Offset消息在分区内的序号类似书签记录读到哪一页Consumer Group多个消费者的逻辑分组类似一个团队分工合作处理任务Rebalance消费组成员变化时的重新分配类似团队里有人离职/入职重新分活2. Producer发消息不只是send一下就完事Producer是消息链路的第一关也是问题最容易埋雷的地方。客户端API看起的确实很简单一个producer.send(new ProducerRecord(topic, value))就发出去了。但这条消息能不能到Broker、到了Broker之后能不能被正确分区、遇到网络抖动会不会丢、重复发送会不会造成数据重复——这些全是埋在send背后的细节。2.1 acks参数你要的可靠性是哪种档位acks是Producer最重要的可靠性开关取值有三档acks0Producer发出去就不管了不等待Broker确认。吞吐最高但消息必丢风险极大只适合丢几条无所谓、追求极速的日志打点场景。acks1只要Leader副本写成功就算成功不等Follower同步。这是默认值性能和可靠性平衡得比较好。但有个隐患Leader刚写完还没来得及同步就宕机这条消息就丢了。acksall或-1所有ISR副本都写成功才返回成功。最安全但延迟会升高而且如果配合min.insync.replicas使用还能在极端情况下直接拒绝写入来防止消息丢失。我实测下来核心交易链路我都是acksall加min.insync.replicas2配合3副本的集群配置单台Broker宕机不影响写入成功。而日志、埋点这种允许丢一点的数据用acks1就够了。2.2 分区策略决定消息会不会乱序的关键同一个分区内Kafka能保证消息顺序跨分区顺序就没法保证了。所以如果你的业务要求同一条订单的创建消息必须先于支付消息被消费那这两条消息必须落到同一个分区。最简单的做法是发送时指定同一个key比如订单ID让Kafka对key取哈希然后映射到固定的分区。Kafka默认的分区器是DefaultPartitioner有key就走哈希没key就用sticky策略——先选一个分区凑满一批再换下一个避免频繁切换分区导致消息散乱。踩过的坑是key不能是那种分布极不均匀的值。比如你把地理位置或用户所在大区当key某个大区的用户量特别大就可能导致某个分区消息量暴涨其他分区空闲直接拉垮消费吞吐。所以选key前先评估一下分布情况宁可用订单ID这种天然均匀的字段。2.3 重试、幂等与事务防止重试导致重复的套路网络抖动是常态Producer发消息不可能每次都一次成功。retries参数控制重试次数retry.backoff.ms控制重试间隔。但这里有坑Leader已经写入成功但响应回包在网络中丢了Producer这边会认为发送失败然后重试这时候Broker上就会出现两条一模一样的消息——顺序没变但数据重复了。解决办法是开启幂等enable.idempotencetrue。开启后Producer会为每条消息加上序列号Broker端对相同序列号的消息做去重。我现在的生产配置一律开启幂等性能损耗可以忽略不计但换来了重试不重复这个保证。如果你还需要跨分区的原子性——比如订单表和扣库存消息要么都成功要么都失败——那就得上事务消息。initTransactions之后开启事务发送多条不同Topic的消息最后提交或中止。这个功能我平时用得少因为事务会显著拉低吞吐只在真正需要强一致的时候才开。2.4 吞吐调优的三件套batch.size、linger.ms、buffer.memory很多人刚接触Kafka的时候都会问为什么我消息发得这么慢看监控才发现瓶颈其实在Producer本地的攒批策略上。三个参数决定攒批效率batch.size每个批次的最大字节数默认16KB。我压测的时候发现消息体平均2KB、batch设置32KB时吞吐最高太小批次频繁发送浪费网络round-trip太大又会在高并发下造成内存压力。linger.ms批次最大等待时间默认0。设成5~20ms可以让Producer多积累几条消息再发吞吐翻倍很常见。代价就是这条消息的延迟增加了这几毫秒看你是要极低延迟还是高吞吐。buffer.memoryProducer端发送缓冲区的总大小默认32MB。如果你的send()调用速度超过Broker处理速度缓冲区满了之后send()会阻塞配合max.block.ms默认60秒超时后抛异常。我遇到过一次因为Buffer太小导致发送线程频繁阻塞的问题后来调到64MB就稳了。2.5 Producer端必须处理的三种异常代码里不能只写send()不管回调。实际运行中常见的异常有三种你得有个处置预案第一种是TimeoutException发送超时。看是Broker负载过高还是网络抖动导致的加大delivery.timeout.ms只能缓解不能根治重点排查Broker端的磁盘IO和网络带宽。第二种是KafkaException: ExpiredProducerBatch批次超期被丢弃。这个通常是因为Producer到Broker之间链路太慢攒批之后迟迟发不出去批次生命周期到了就丢了。我刚才说开幂等调linger就是为这种场景设计的组合拳。第三种是RecordTooLargeException单条消息超过message.max.bytesBroker端默认1MB。这个最好一开始就约定好消息体的上限不然线上发了条大消息直接报错是最头疼的。提示抓Producer异常不要只依赖send方法的同步try-catchKafka的send()是异步的真正报错会出现在回调方法里。我见过太多生产事故错误日志打了一堆但业务代码完全无感知就是因为回调里没做异常处理。3. Consumer消费真正的难点在怎么分、怎么保证顺序Consumer端的认知门槛比Producer高一个台阶。因为Producer的逻辑是直白的发送确认只要参数配合理就行Consumer要处理的分区分配、消费进度管理、Rebalance、重复消费每一样都藏着线上事故的隐患。3.1 消费组与分区分配同一个Topic多个消费者怎么协作Kafka的消费模型是Consumer Group。组内每个消费者负责一个或多个分区组与组之间互不干扰。这就实现了一个Topic既能被多个业务系统独立消费发布订阅模式又能被一个业务系统的多个实例分摊负载点对点模式。组内分配由GroupCoordinator相当于消费组的管理员负责默认分配策略是RangeAssignor和RoundRobinAssignor合作者模式CooperativeStickyAssignor是当前推荐的选择。记住一个限制一个分区在同一个消费组内同一时刻只能分配给一个Consumer实例。如果你启动了5个消费者但Topic只有4个分区那第5个消费者一定处于闲置状态其他4个消费者各持一个分区。所以分区数定多少直接决定了你的消费集群能横向扩到多大。3.2 Offset提交自动提交就是在给自己埋雷Offset是Consumer读进度的标记提交Offset就是告诉Broker我这条消息已经处理完了下次从这里继续读。默认的enable.auto.committrue看起来方便但有个要命的坑如果消息还在处理中提交间隔就到了auto.commit.interval.ms默认5秒Kafka会把当前提交的位点往前移。这时候如果消费者宕机再重启就会丢一段已经提交但还没处理完的消息。严格来说这叫至少一次语义下的重复消费风险但在自动提交模式下割裂拉取-处理-提交三个阶段导致的丢数据问题更隐蔽也更常见。我的做法是一律enable.auto.commitfalse改成手动提交。处理完业务逻辑之后用consumer.commitSync()同步提交或者用commitAsync()异步提交加回调处理重试。这里还要注意提交位移的时机。很多人代码写成poll到一批消息后先commit再处理这种做法在极端情况下会出问题如果处理到一半进程挂了这批消息会被重复消费。反过来先处理再提交则可能出现处理完了但没提交就崩溃导致的重复消费。二者都是至少一次语义的体现你只能选一个方向去接受。我一般选先处理再提交——宁可重复消费几次也不能丢消息。配合幂等消费逻辑重复消费的代价完全可控。3.3 多线程消费与消息顺序分区是顺序性的最小单位这是热搜词里大家问得最多的问题Kafka消费端多线程如何保证消息顺序性。我先给结论Kafka只能保证单分区内的消息顺序跨分区不保证。因此多线程消费要保序核心策略是让需要保序的消息只落在一个线程里处理。有几个可用方案方案一单分区单消费线程。这是最朴素的保序方案原理就是分区顺序消费顺序。代价是单分区的消费并发度上限是1吞吐受限。适合消息量不大但顺序要求极高的场景。方案二分区级别的串行化。多个消费者各持有不同分区每个消费者内部依然单线程处理整体上实现了分区内保序、分区之间并行。实际效果就是分区数就是最大并行度。我线上最常见的就是这种模式分区数开大一点比如24消费者实例按分区数部署既保证了单个分区的顺序又获得了足够的吞吐。方案三消费端按key路由到内存队列。消费者拉取消息后不立即处理而是根据消息key比如订单ID哈希后分发到多个内存队列每个队列一个处理线程。这样同一个key的消息永远落在同一个队列、同一个线程上。这套方案需要自己处理队列的并发控制复杂度高一些真正需要一个分区的消息再拆成多线程的场景才用得上。不管哪种方案我都要提醒一句顺序性是有范围的。如果你把不同分区的消息合并到一个线程池去处理顺序就被打破了如果你把一个分区交给多个线程并行处理而不做二次路由顺序也没法保证。很多排查了半天Kafka消息乱序的朋友最后发现不是Kafka的问题是自己消费线程池用错了。3.4 Rebalance消费抖动的大坑Rebalance是消费组成员变化消费者退出、加入、分区数变化、消费超时时Kafka重新分配分区归属的过程。Rebalance期间整个消费组会停止消费对高实时性业务来说就是一次卡顿。常见的Rebalance触发条件有消费者实例崩溃或主动关闭消费者超过session.timeout.ms默认45秒没有发送心跳被判定为下线消费者处理消息耗时超过了max.poll.interval.ms默认300秒下一次poll迟迟不来被判定为处理能力不足而踢出组第二个和第三个是线上最常见的。很多同学把消费逻辑写在poll返回之后慢慢处理一个消息处理一两分钟结果正好超过max.poll.interval.ms被Coordinator踢出消费组然后触发Rebalance。等处理完回来又被踢……就是这种循环。解决办法有两个方向要么加快消息处理速度缩小max.poll.records每批少拉点多poll几次要么把耗时的处理逻辑放到异步线程池里消费线程只负责拉消息和投递给线程池然后立刻去poll下一批。4. 线上常见的三类问题延迟高、顺序乱、连接报错这部分是把热搜里几个高频问题串在一起说。消息延迟高、消费端多线程顺序乱、InvalidReceiveException这三类问题几乎每个用Kafka超过半年的团队都会遇到。4.1 消息延迟高的排查链路消息延迟直观表现是生产者发出去消费者半天才收到。我从三个维度排查第一步看Producer端是否有攒批等待。linger.ms设得太大比如1000ms消息会在Producer本地坐等凑批延迟自然高。如果你做的是实时性敏感的业务linger.ms建议控制在5ms以内或者直接保持默认的0。第二步看Consumer端的poll循环。消费者本身是通过循环consumer.poll(Duration)来拉消息的。如果两次poll之间间隔太长比如处理逻辑是同步阻塞的拉取的频率就下降了消息就积压了。优化手段就是我前面说的把重活儿从消费主线程搬走。还有一个常见的隐藏问题fetch.max.bytes和max.partition.fetch.bytes配得太小一次poll只能拉很少消息本来一轮能拉1MB的结果只拉了100KB也会造成延迟。我一般会把max.partition.fetch.bytes从默认1MB提高到5MB以上减少poll次数。第三步看Broker端有没有积压或I/O瓶颈。如果生产者的发送速率远超消费者的消费速率消息就会在Kafka里积压消费延迟自然增长。这时候要查Consumer的records_lag_max指标——这个指标可以直接从Kafka的JMX端口或消费组API拿到。积压严重的话加消费者实例数量和增加分区数是两个方向但注意实例数超过分区数之后就白搭了扩容前先看看分区数是瓶颈还是实例数是瓶颈。4.2 顺序乱绝大多数是自己代码的问题我在前面讲了多线程保序的方案这里补充一个排查思路。当你发现消费到的消息顺序不对时先别急着怀疑Kafka集群按这三个步骤来确认生产端是否保证了顺序。同一业务的多条消息有没有发到同一个分区如果发到了不同分区消费顺序错乱就是必然的。确认单一分区内部是否乱序。如果同一个分区的消息顺序都乱了那十有八九是消费者端用了多个线程处理同一个分区的消息。查一下你的消费线程模型是不是开启了concurrency之后多线程去拉同一个消息批次那个批次里的消息被拆到多线程处理顺序自然无法保证。确认是否因为重复消费导致顺序错觉。还有一种情况比较隐蔽消息A先被处理完并提交然后一条旧消息B因为offset重置或者自动提交异常在A之后被重新消费。明明分区存储顺序没坏是消费进度回退导致的假性乱序。这种问题根源在offset管理上查一下是不是用了auto.offset.resetearliest的配置在消费组offset丢失时会回退到最早的消息。4.3 InvalidReceiveException连接层的最常见报错org.apache.kafka.common.network.InvalidReceiveException: Invalid receive (size xxxxxxxx larger than 104857600)这个词近期问的人特别多。这个报错字面意思是Broker认为自己收到的网络请求包大小超过了限制默认上限100MB于是断开了连接。我第一次遇到这个报错第一反应是有人发了大消息。但排查到最后发现根本不是消息大小的问题而是客户端用明文9092端口去连接了开启了SSL的Listener或者反过来用SSL配置连了明文端口。安全配置不匹配时双方协商的协议版本不一致Broker收到的就是一堆乱码解析出来的包大小自然是个天文数字。所以排查这个报错的顺序是确认客户端的bootstrap.servers指向的端口和Broker端listeners、advertised.listeners配置的协议是否一致。一个端口监听的是SSL一个端口监听的是明文客户端连错了端口就会出现这个乱码包。确认客户端的security.protocol是否设置正确。如果Broker要求SSL但客户端写成了PLAINTEXT或者反过来都会触发连接异常。检查客户端发送的消息是否真的超大。如果确实有单条消息很大同时message.max.bytes和replica.fetch.max.bytes也调大了那客户端侧也要调整max.request.sizeProducer、fetch.max.bytesConsumer以及Broker的socket.request.max.bytes这几个参数要同时放大任何一个漏了都会导致请求被拒或连接异常。还有一种偶发情况某个客户端版本太老发送的请求格式和Broker不兼容Broker解析请求头失败也会报InvalidReceiveException。升级客户端版本到和服务端同代或相差不超过两个小版本基本能消除这类问题。5. 部署、集群与可视化从能跑到好管热搜词里大量出现kafka集群安装3节点集群部署可视化工具这部分我就把这些需求集中讲掉。Kafka安装本身不复杂真正复杂的是版本选择和参数配置——这也是很多人遇到的坑所在。5.1 版本选型与3节点集群部署要点我强烈建议Kafka客户端版本必须和服务端版本保持同一大版本至少也要小版本接近。Kafka 2.8之前的版本依赖Zookeeper2.8开始引入了KRaft模式内置Raft协议去Zookeeper依赖3.5之后的版本KRaft已成熟4.0版本则彻底移除了Zookeeper支持。新的部署建议直接用KRaft模式少维护一个Zookeeper集群少一半崩溃面。3节点KRaft集群的搭建要点三台机器分别配置node.id1/2/3controller.quorum.voters1host1:9093,2host2:9093,3host3:9093listenersPLAINTEXT://0.0.0.0:9092advertised.listenersPLAINTEXT://对应节点IP:9092这是客户端连接的关键IP写错会导致连不上log.dirs用独立磁盘或数据盘不要和系统盘混用这块盘建议用SSDKafka是磁盘I/O密集型的机械盘跑Consumer流量经常是瓶颈num.partitions默认值建议先改好比如默认8个分区后续创建Topic时可以省略分区数参数也不用反复补充default.replication.factor3Kafka默认单副本非常危险尤其生产环境一定要改成3启动顺序是先在每台节点上格式化存储目录kafka-storage.sh format -t cluster-id再按照controller和broker角色启动对应的进程。KRaft模式下controller和broker可以部署在同一批节点上3节点同时扮演两个角色完全够用。5.2 磁盘与吞吐读写最大值的硬件关系Kafka读写最大值与硬件关系是热搜里的另一个高频搜索。我直接给一组参考数据在3节点、每节点8核16G、SSD磁盘、千兆网卡的实验环境里单Producer单Topic的吞吐大约在几十MB/s的量级换上万兆网卡和NVMe SSD单机吞吐可以到数百MB/s。瓶颈通常不在Kafka软件本身而在网卡带宽、磁盘顺序写性能、页缓存大小三处。分区数对吞吐的影响是线性的前提是Broker数量足够一个分区能跑到的吞吐大约在5~20MB/s具体看消息体大小。所以如果你的单Topic需要更高的吞吐直接加分区数但不能无限加每个分区都会对应Broker端的一个文件句柄和消费者端的一次线程开销分区数超过Broker的承受能力之后反而会拖慢。这里要注意一个花钱买性能的细节Kafka的读写性能强依赖操作系统页缓存。生产者写入的数据先落页缓存由操作系统异步刷盘消费者读取时优先读页缓存命中率高的话磁盘IO消耗极小。所以给Kafka所在机器配足够大的内存而不是一味上更多磁盘往往是最划算的性能提升手段。5.3 可视化工具和管理客户端命令行脚本能解决99%的日常问题但看监控、查积压、管理Topic还是得用可视化工具。我用过的工具排个序Offset Explorer原Kafka Tool桌面端神器看topic消息、消费组offset、积压量都方便适合单机或小集群排查问题。Kafka UI开源Web端支持多集群、消息查看、消费者管理我目前主力用它部署一个容器就能管好几套环境。Kafka Eagle国产工具监控功能全报警策略丰富适合生产环境就是界面和配置略重。CMAK原Kafka Manager老牌工具主要做集群管理不擅长消息查询。除此以外线上排查时一定要把Broker的JMX指标接进PrometheusGrafana。需要重点盯的指标就三个BytesInPerSec、BytesOutPerSec进出流量速率、UnderReplicatedPartitions副本不同步的分区数这个持续大于0说明集群存在故障、RequestHandlerAvgIdlePercent请求处理线程的空闲率这个值长时间低于30%说明Broker过载。5.4 AdminClient除了收发消息还能做管理操作很多人忽略了Kafka自带的AdminClient API这个工具能让你在不需要手敲命令行的情况下完成绝大部分管理操作创建Topic、查看分区详情、查询消费组状态、查看offset、修改配置等。我的实用套路是写一个脚本通过AdminClient批量检查所有消费组的lagtry (AdminClient admin AdminClient.create(props)) { // 列出所有消费组并查询各组的最新offset和log-end-offset算出积压量 ListConsumerGroupsResult groups admin.listConsumerGroups(); groups.all().get().forEach(group - { MapTopicPartition, OffsetAndMetadata offsets admin .listConsumerGroupOffsets(group.groupId()).all().get(); // 再配合 listOffsets 拿到每个分区的 log-end-offset // 两者相减就是实时的消费积压值 }); }除了查积压我还常用AdminClient做分区扩容新增分区和查看Broker配置。当线上突然出现消息积压我的第一反应往往是用AdminClient快速确认是哪个消费组慢了、积压量有多大再决定要不要紧急加消费者实例。6. 选型不纠结Kafka、RabbitMQ、RocketMQ到底怎么挑这个对比是热搜里的常青话题也是面试必考题。我用实战的视角说结论三者都是成熟的消息中间件但设计哲学完全不同选型不是比谁更强而是比谁更符合你的场景。Kafka的定位是分布式提交日志设计目标是高吞吐、持久化、可回溯。消息堆积能力极强靠磁盘消费者可以自由控制Offset。缺点是功能面窄没有死信队列、没有延迟队列、没有灵活的路由规则事务消息的复杂度也比较高。适合数据管道、日志收集、系统间数据同步、流式计算这类数据量大、消费模式简单的场景。RabbitMQ的定位是消息代理设计目标是灵活路由、低延迟、丰富的消息模式。基于AMQP协议有Exchange交换机机制可以非常精细地控制消息怎么路由支持死信队列、优先级队列、延迟消息通过插件这些开箱即用的功能内存模式下单条消息延迟可以做到微秒级。缺点是高吞吐量不如Kafka消息堆积能力依赖磁盘但性能和稳定性不如Kafka的日志模型。适合业务系统内的异步解耦、任务分发、RPC调用、定时任务触达等复杂路由场景。RocketMQ的定位介于二者之间。它有Kafka的分布式日志存储模型做基础又在这个基础上补了事务消息、定时消息、死信队列、消息轨迹等业务友好的特性。一方面吞吐量比RabbitMQ强不少另一方面功能丰富度比Kafka好很多。社区活跃度和阿里背景让它在金融、电商这类对消息可靠性要求极高的行业里很受青睐。缺点是与Kafka相比生态略小与RabbitMQ相比路由灵活性又略逊一筹。对比项KafkaRabbitMQRocketMQ吞吐量最高一般高消息延迟毫秒级微秒级毫秒级路由灵活性弱只有Topic强Exchange/Binding中TopicTag死信队列无需自行实现有有延迟消息不支持插件支持支持定时/延迟事务消息支持但较重弱强运维复杂度中等低中高最适合场景数据管道、日志、流处理业务解耦、复杂路由金融交易、可靠消息选型的时候我给一个简单粗暴的判断路径如果你的应用是要把一份数据稳定地搬给多个下游选Kafka如果你的应用是业务系统内部异步调用需要各种路由规则和消息模式选RabbitMQ如果你的场景在两者之间比如既要求高吞吐又要事务和延迟消息选RocketMQ。这个话题我多说一句很多团队选型踩坑不是选的中间件不对而是把中间件用错了地方。拿Kafka去推业务消息结果发现没有死信队列各种异常消息没法自动隔离最后自己手动拼了个deadletter topic方案拿RabbitMQ去灌日志数据结果堆积量一大内存和磁盘都扛不住。这种问题我在多个项目里都见过。7. 一些想留给你的实操习惯文章写到这里该说的技术点基本都覆盖了。最后聊几个我这些年用Kafka攒下来的习惯特别实在比背任何参数都管用第一任何Kafka生产环境都配一个消息巡检脚本。前五分钟看一下Producer的发送成功率、Consumer的Lag指标、UnderReplicatedPartitions的数量手里有数据比什么都强。AdminClient配合Prometheus指标能让你在故障发生的萌芽期就发现问题。第二Consumer端的幂等处理逻辑永远要写。不管用Kafka还是别的消息中间件至少一次语义决定了重复消费是不可避免的与其事后补数据不如在设计阶段就考虑好数据库操作用唯一键约束、Redis用SETNX、外部接口调用先做本地查重。把幂等当作默认要求而不是性能不够了再优化的备选项。第三版本升级要谨慎再谨慎。Kafka的版本兼容性不像HTTP协议那么从容跨大版本升级比如从2.x升到3.x要特别小心协议变化和默认值调整。我见过因为升级后默认group.initial.rebalance.delay.ms变化导致消费组启动变慢的事故。升级前先把官方迁移文档通读一遍升级后观察至少一周的指标波动再下结论。第四分区数不是越大越好。理论上有多少个分区就能有多少并行度但每个分区都要消耗Broker的文件句柄、Consumer的线程、Rebalance的时间。分区数万级别的时候一次Rebalance耗时可能以分钟计。我一般按目标吞吐/单分区承载吞吐再乘个1.5的余量来规划分区数而不是拍脑袋定个96或128。用Kafka做中间件最忌讳的就是想当然。它有它的脾气延迟是毫秒级的但不是零延迟顺序保证只在分区内成立别指望跨分区有序消息可以回溯但Offset你得自己管好。把这些边界条件都搞明白再用它你才会真正感到顺手的强大。希望这篇里的实战经验能帮你少踩几个我已经踩过的坑。