文章目录CentOS7安装部署KafkawithKRaft一、前言1.简介2.架构3.环境二、正文1.部署服务器2.基础环境1）主机名2）Hosts文件3）关闭防火墙4）JDK安装部署3.单机部署1）下载软件包2）修改配置文件3）格式化存储目录4）单机启动5）测试6）自启动4.集群部署1）下载软件包2）修改配置文件3）拷贝Kafka4）修改配置文件5）格式化存储目录6）集群启动7）测试8）自启动5.Kafka管控平台1）脚本安装2）Kafka启动JMX3）手动启动4）配置Kafka集群三、其它1.常用命令CentOS7安装部署KafkawithKRaft一、前言1.简介ApacheKafka是
1.Kafka简介Kafka本质上是一个MQ（MessageQueue），使用消息队列的优点：解耦：允许独立的扩展或修改队列两边的处理过程。可恢复性：即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。缓冲：有助于解决生产消息和消费消息的处理速度不一致的情况。灵活性和峰值处理能力：不会因为突发的超负荷的请求而完全崩溃，消息队列能够使关键组件顶住突发的访问压力。异步通信：消息队列允许用户把消息放入队列但不立即处理它。先介绍消息队列的优点： 消息队列：消息队列的异步处理主要应用于短信通知、终端状态推送、App推送、用户注册等。同步处理： 我们同步处理的话，我们执行下一个步骤需要
背景Flink版本1.12.2Kafka客户端2.4.1在公司的Flink平台运行了一个读Kafka计算DAU的流程序，由于公司Kafka的缩容，直接导致了该程序一直在重启，重启了一个小时都还没恢复（具体的所容操作是下掉了四台kafkabroker，而当时flink配置了12台kafkabroker），当时具体的现场如下：JobManaer上的日志如下：2023-10-0710:02:52.975INFOorg.apache.flink.runtime.executiongraph.ExecutionGraph-Source:TableSourceScan(table=[[default_ca
在Springboot中接收kafka消息整体描述版本对应具体接入1.pom引用2.kafka参数配置3.添加Conditional注解4.添加listener总结整体描述之前写过一篇使用docker搭建kafka服务的文章，使用centos搭建kafka服务器Docker，本文主要简单将一下在springboot框架下，接收kafka服务器发过来的消息。版本对应由于使用springboot，管理版本时和springboot绑定的，我目前用的是springboot2.7，kafka的版本是2.1，这个版本也没啥影响，因为kafka服务器是向下兼容的，也就是说你的kafka服务器的版本是3.1，
说明：当前kafka的版本为2.8.11，SpringBoot的版本为2.7.6。第一步：在pom.xml中引入下述依赖 org.springframework.kafka spring-kafka 2.8.11第二步：在yml配置文件进行如下配置spring:kafka:#kafka服务的地址bootstrap-servers:127.0.0.1:9092producer:#key-value序列化key-serializer:org.apache.kafka.common.serialization.StringSerializervalue-serializer:org.apache.k
一、命令行设置（以Hadoop的topic为例）进入Zookeeper客户端查看kafka存储的信息，/kafka/brokers/topics/hadoop/partitions/1/stateget/kafka/brokers/topics/hadoop/partitions/1/state查看到{"controller_epoch":33,"leader":-1,"version":1,"leader_epoch":25,"isr":[3]} leader为-1，固分区的leader为none修改/kafka/brokers/topics/hadoop/partitions/1/sta
一、前言数据重复这个问题其实也是挺正常，全链路都有可能会导致数据重复。通常，消息消费时候都会设置一定重试次数来避免网络波动造成的影响，同时带来副作用是可能出现消息重复。整理下消息重复的几个场景：生产端： 遇到异常，基本解决措施都是 重试 。场景一：leader分区不可用了，抛 LeaderNotAvailableException 异常，等待选出新 leader 分区。场景二：Controller 所在 Broker 挂了，抛 NotControllerException 异常，等待 Controller 重新选举。场景三：网络异常、断网、网络分区、丢包等，抛 NetworkException
一、代理商Broker在之前我们已经为大家介绍了生产者向消息队列中投递消息，消费者从消息队列中拉取数据。在kafka消息队列中有一个非常重要的概念就是代理Broker，大家可以想象生活中的商品代理商是做什么的？进货、存货、销货。kafka的代理Broker也承担着同样的作用：接收消息、保存消息、为消费者提供消息。具体到kafka架构层面，我们可以认为一个Broker代理就是一个kafka的服务实例。kafka可以启动多个服务实例，组成一个具有多个Broker代理的服务集群。通常一个集群内的Broker越多，kafka集群的整体吞吐能力就越强。这个也好理解，现实生活中一个产品的代理商越多，销售能
现象凌晨，当运维刚躺下，就被业务研发的电话叫醒，"哥们！kafka服务又异常了？影响到业务了，快看看"，业务研发给出的异常日志如下：基本分析集群检查：立即确认kafka集群以及涉及到topic健康状态。集群状态正常，收发消息正常，压力负载正常；topic读写正常。变更操作：近期未做关于kafka的任何变更操作，排查变更影响。确定影响范围：个例问题。问题规模限定在当前业务主机。抓包分析基本确定异常和集群无关后，接下来就是要排查网络相关的问题，网络和系统（内核参数设定）是息息相关的，网络问题是复杂而神秘的，后期会根据场景给大家分享，今天，我们主要分析网络链路问题使用tcpdump抓包（客户端抓包）
一、Kafka消息发送失败的常见原因及解决方案 1.1、网络故障 网络故障是Kafka消息发送失败的最常见原因之一。当网络出现故障时，Kafka就无法将消息发送到目标主题或分区。 解决方法： -检查网络连接是否正常。 -增加Kafka生产者的重试次数和超时时间。 1.2、分区副本不可用 如果Kafka生产者将消息发送到一个不可用的分区副本，那么消息发送就会失败。这种情况通常发生在分区副本出现故障或正在进行分区重分配时。 解决方法： -检查分区副本是否正常。 -增加Kafka生产者的重试次数和超时时间。 1.3、主题不存在 如果Kafka生产者尝试将消息发送到一个不存在的
