背景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生产者尝试将消息发送到一个不存在的
目录：Kafka封装包接入1.Kafka工作原理2.SpringKafka介绍3.kafka封装包的设计及使用Kafka封装包接入1.Kafaka工作原理1).kafka的定义：消息队列的两种模式：1).点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。2).发布/订阅模式（一对多，数据生产后，推送给所有订阅者）发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者
Kafka中的leader选举算法Raft一、简介1.定义2.Leader选举算法二、分布式一致性协议Raft1.Raft强一致性协议基础2.Raft应用场景三、Kafka选举算法的需求1.Leader的定义和意义2.Leader选举的需求和挑战3.现有Leader选举算法四、Kafka中的leader选举算法实现1.Kafka中使用的leader选举算法2.选举机制详解选举过程描述身份的授予和交接3.算法的优化项五、Raft在Kafka中的应用1.Kafka和Raft的集成架构设计2.Leader选举对Kafka系统健康的保证六、比较分析：Raft与Paxos1.Paxos算法的基本原理2.
