如果你的业务中需要处理海量日志、做实时数据管道，或者要给微服务之间解耦，那么分布式消息服务Kafka几乎是绕不开的选项。它不追求极致的单条消息延迟，而是用分布式架构和顺序写入的机制，扛住每秒几十万条的写入压力，我会从选型对比、集群搭建、问题排查三个维度，把Kafka的实战经验掰开揉碎讲清楚。参考2
Kafka什么时候用？和消息队列的对比
很多团队在选型时会纠结,Kafka到底适合什么场景，它和传统的RocketMQ、RabbitMQ有本质区别。
核心差异在哪里
Kafka的设计初衷是高吞吐的日志收集和数据管道，它把消息持久化到磁盘，利用操作系统的Page Cache加速读写，所以吞吐量远超其他消息队列。
- 死信队列与重试机制：RabbitMQ和RocketMQ自带完善的重试和死信队列，Kafka则需要手动实现重试逻辑，或者搭配流处理框架来处理。
- 数据持久化与回溯：Kafka的消息默认保留一段时间（比如7天），消费者可以随时从任意偏移量重新消费，这在日志分析和数据审计场景中极其重要，传统消息队列通常消费完就删除。
- 消费模式：Kafka采用拉模型（Pull），消费者主动拉取数据，可以批量处理，适合大数据吞吐，而RabbitMQ是推模型（Push），延迟更低，适合实时通知。
选型建议
适合用Kafka的场景：用户行为日志采集、监控指标聚合、大数据链路（如对接Spark/Flink）、事件溯源架构。
更适合用传统消息队列的场景：需要严格的事务消息、低延迟的订单处理、死信队列自动重试，一个电商系统的下单流程，如果对消息顺序和强一致性要求极高，业内专家更推荐RocketMQ。参考2
完整的Kafka集群搭建方案
很多新手被Kafka的配置吓到,其实把几个核心参数定下来，集群就能稳定跑起来。
版本选择与前置条件
Kafka依赖ZooKeeper（或Kafka 2.8之后引入的KRaft模式），2026年生产环境推荐使用Kafka 3.5+ 版本，已经稳定支持KRaft模式，可以省略ZooKeeper。
- 操作系统：CentOS 7+ 或 Ubuntu 20.04+，建议使用Linux，Windows只适合测试。
- JDK：JDK 11或17，Kafka的压缩和网络性能依赖JDK的新特性。
- 硬件：磁盘建议用SSD，尤其在高吞吐场景下，机械磁盘容易成为瓶颈。
关键配置项
配置文件的路径通常在 $KAFKA_HOME/config/server.properties，以下参数必须根据业务调整：
- log.dirs：日志存储路径，建议挂载独立数据盘，避免和系统盘抢I/O。
- num.partitions：默认分区数，推荐设置为3~6，分区数越多，并行消费能力越强，但也会增加Leader选举和文件句柄开销。
- default.replication.factor：副本系数，生产环境至少3，一个副本挂了，还有两个副本可用，保证数据不丢。
- log.retention.hours：消息保留时间，默认168小时（7天），如果做日志管道，可以缩短到72小时；如果做事件溯源，可能要延长到30天。
启动与验证
启动KRaft模式的Kafka集群（3节点示例）：
- 在每个节点上执行
./bin/kafka-storage.sh format -t <集群ID> -c ./config/kraft/server.properties
- 启动服务：
./bin/kafka-server-start.sh -daemon ./config/kraft/server.properties - 创建一个Topic测试：
./bin/kafka-topics.sh --create --topic test-topic --partitions 3 --replication-factor 3 --bootstrap-server localhost:9092 - 查看集群状态：
./bin/kafka-broker-api-versions.sh --bootstrap-server node1:9092,node2:9092,node3:9092
如果返回的信息里没有报错,就说明集群搭建成功了。Kafka好不好用，集群搭建这一步就决定了90%的稳定性。
常见Kafka生产问题排查
Kafka群里最常见的问题就是消息积压、消费延迟和数据丢失，下面直接给出排查思路和解决方案。
消息积压问题排查
消息积压的本质是消费速度跟不上生产速度，先用命令查看消费者组状态：
./bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group <group_id> --describe输出结果中的 LAG 列就是积压量，如果积压持续增长，可能是以下原因：参考2
- 消费者处理能力不足：检查消费者线程数，通常一个分区只能被一个消费者线程消费，如果分区数少，可以考虑增加分区数（但线上增加分区不能减少，需要提前规划）。
- 消费逻辑耗时过长：比如每条消息都要调用外部API或查询数据库，建议把消息先批量攒到内存里，再一次性写入目标系统。
- Rebalance频繁：如果消费者频繁加入或退出，会导致全组暂停消费，可以设置
session.timeout.ms为60秒，减少误判。
数据丢失问题
Kafka本身的数据可靠性很高,但配置不当就会丢数据。
- acks设置：生产者设置
acks=all，表示Leader和所有ISR副本都确认写入才算成功，这是最稳妥的方式。 - min.insync.replicas：配合acks=all，设置
min.insync.replicas=2，意思是至少有两个副本同步才算成功，这样即使一个副本挂了，消息也不会丢。 - unclean.leader.election.enable：必须设为false，如果设为true，当Leader挂了，一个落后很多的副本被选为Leader，会丢失大量已提交消息。
行业共识认为,采用acks=all + min.insync.replicas=2 + unclean.leader.election.enable=false 的组合，可以做到不丢数据，代价是写入吞吐量会略有下降。
关于Kafka的常见疑问
Kafka消息积压了如何快速恢复？
如果是临时积压，可以暂时扩容消费者组，增加消费者实例，但注意消费者数不能超过分区数，否则多余的消费者会闲置，如果积压太严重，可以跳过部分过期消息，或者直接重置消费者组的偏移量到最新位置。
Kafka数据会丢失吗？
在正确配置下，Kafka几乎不会丢失已提交的数据，但如果你使用默认配置（acks=1），或者磁盘损坏，数据可能丢失，生产环境必须开启副本机制，并定期做数据备份，比如把Topic数据导出到HDFS或对象存储。
Kafka适合存业务数据吗？
Kafka的设计初衷是消息管道和日志聚合，不是数据库，消息在达到保留时间后会被自动删除，所以不适合作为持久化存储，想要存储业务数据，应该把Kafka的数据下沉到数据库或数仓中，Kafka只负责传递。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/530970.html
