1.一次Kafka集群宕机的问题排查记录
2.Kafka消费者源码：重平衡（1）-初始化与FIND_COORDINATOR
3.浅析源码 golang kafka sarama包(一)如何生产消息以及通过docker部署kafka集群with kraft
4.kafka源码阅读之MacBook Pro M1搭建Kafka2.7版本源码运行环境
5.EMQX-简介、安装部署、基础功能、python代码测试
6.kafka源码Topic的创建源码分析(附视频)
一次Kafka集群宕机的问题排查记录
大家好，我是方木
某机房ELK集群索引出现延迟，上班后接到报警，qq飞车易语言源码开始排查问题。
机房Kafka集群服务和zookeeper服务分离，早7点，某个索引停止索引，推测logstash indexer生成日志异常，重启索引点logstash indexer，未恢复。查看Kafka服务器上分片数据，Broker 0的物理log文件最后修改时间停留在早7点，疑似Kafka问题。
监控显示Broker 0网卡入出带宽几乎降至0，而Broker 1和Broker 2虽有下降，但未至0，解释了部分索引仍正常现象。查看日志，Broker 0出现日志异常，Broker 1和Broker 2报java.io.IOException，推测Kafka集群间状态异常，导致Broker 0被集群剔除。
通过Kafka源码分析，确认异常情况发生在断开连接时。重启Broker 0 Kafka服务，大部分索引恢复，后续分别重启Broker 1和Broker 2，所有索引恢复正常。
事后发现部分服务器性能指标异常。几年前曾因logstash shipper bug导致类似问题，通过升级版本解决。本次close wait升高，疑为网络波动或Kafka版本问题。如果问题频繁出现，考虑升级kafka版本。
Kafka消费者源码：重平衡（1）-初始化与FIND_COORDINATOR
在Kafka 2.5.2的消费者组中，重平衡是关键，它定义了消费者如何根据订阅关系调整对Topic分区的分配。当消费者数量、订阅的Topic或GroupCoordinator所在的Broker发生变更时，会触发重平衡。
消费者组状态由GroupState类管理，共有五个状态：Empty（无成员）、PreparingRebalance（加入中）、netbsd 源码分析CompletingRebalance（等待分配）、Stable（已平衡）和Dead（元数据已删除）。状态间的转换基于预先定义的前置状态。例如，从Empty到PreparingRebalance，预示着重平衡的开始。
重平衡过程分为几个步骤，首先是消费者和Broker之间的协调。服务端启动时，GroupCoordinator组件即已就绪，而Consumer通过ConsumerCoordinator与之通信。在启动时，消费者首先会通过FindCoordinatorRequest找到GroupCoordinator，通过最小负载节点发送请求，然后服务端确定哪个Broker负责协调，如groupId的hash值对consumer_offsets分区数取模确定。
一旦找到GroupCoordinator，消费者会发送JoinGroupRequest。后续步骤如SYNC_GROUP和HEARTBEAT确保消费者与协调器保持同步。这部分详细内容在后续的文章中会进一步探讨。
浅析源码 golang kafka sarama包(一)如何生产消息以及通过docker部署kafka集群with kraft
本文将深入探讨Golang中使用sarama包进行Kafka消息生产的过程，以及如何通过Docker部署Kafka集群采用Kraft模式。首先，我们关注数据的生产部分。
在部署Kafka集群时，我们将选择Kraft而非Zookeeper，通过docker-compose实现。集群中，理解LISTENERS的含义至关重要，主要有几个类型：
Sarama在每个topic和partition下，会为数据传输创建独立的goroutine。生产者操作的起点是创建简单生产者的方法，接着维护局部处理器并根据topic创建topicProducer。
在newBrokerProducer中，run()方法和bridge的匿名函数是关键。它们反映了goroutine间的巧妙桥接，通过channel在不同线程间传递信息，体现了goroutine使用的精髓。
真正发送消息的过程发生在AsyncProduce方法中，这是数据在三层协程中传输的环节，虽然深度适中，但需要仔细理解。
sarama的架构清晰，但数据传输的核心操作隐藏在第三层goroutine中。输出变量的使用也有讲究：当output = p.bridge，它作为连接内外协程的jwplayer 源码编译桥梁；output = nil则关闭channel，output = bridge时允许写入。
kafka源码阅读之MacBook Pro M1搭建Kafka2.7版本源码运行环境
在探索Kafka源码的过程中，决定搭建本地环境进行实际运行，以辅助理解和注释。由于日常开发中常使用Kafka 2.7版本，选择了在MacBook Pro M1笔记本上搭建此版本的源码环境。搭建过程中，记录了遇到的障碍，方便未来再次搭建时不必从头开始。 搭建Kafka 2.7源码环境需要准备以下基础环境：一、Zulu JDK1.8
在MacBook Pro M1笔记本上，基本都已安装JDK，版本不同而已。使用的是Zulu JDK1.8版本，通过下载.dmg格式的一键安装，环境自动配置，安装路径通常在 /Library/Java/JavaVirtualMachines。二、Scala 2..1
并未在系统里安装Scala，而是直接利用IDEA。按照Preferences -> Plugins -> Scala安装。选择IDEA的不同Scala JDK版本。三、安装Gradle6.6
通过官网gradle.org/releases/下载Gradle6.6版本。如国内下载速度较慢，可直接从百度网盘下载安装包。安装完成后，解压并放置在目录/Users/helloword/software/gradle-6.6，通过mac终端执行指令配置环境。四、Zookeeper3.4.6安装
直接从百度网盘下载zookeeper-3.4.6.tar.gz包，解压后放置在三台机器的/app目录下。在每个目录中创建data子目录，并建立myid文件，按照特定数字填写。在zoo.cfg文件中进行配置并复制至其他机器。五、Kafka2.7源码部署
从官网下载Kafka 2.7源码，或从百度网盘获取。解压至目录/Users/helloword/software/kafka/kafka-2.7.0-src，并通过Gradle构建环境。在mac终端执行指令，生成gradle-wrapper.jar，配置依赖。将源码导入IDEA，加载Gradle构建的qt designer源码项目。六、源码运行
确保源码运行打印日志，需将log4j.properties复制到core的 resources目录，并在build.gradle中添加log4配置。修改config/server.properties配置，包括zookeeper路径和broker的ip。配置server、consumer、producer三个进程，确保Kafka服务、消费者和生产者能够正常工作。 整个Kafka 2.7版本源码的本地搭建步骤完成。后续计划撰写系列文章总结阅读源码的经验。关注公众号写代码的朱季谦，获取更多分类归纳的博客。EMQX-简介、安装部署、基础功能、python代码测试
MQTT属于是物联网的通信协议，在MQTT协议中有两大角色：客户端（发布者/订阅者），服务端（Mqtt broker）；针对客户端和服务端需要有遵循该协议的的具体实现，EMQ/EMQX就是MQTT Broker的一种实现。
EMQX是基于 Erlang/OTP 平台开发的 MQTT 消息服务器，是开源社区中最流行的 MQTT 消息服务器。EMQ X 是开源百万级分布式 MQTT 消息服务器（MQTT Messaging Broker），用于支持各种接入标准 MQTT协议的设备，实现从设备端到服务器端的消息传递，以及从服务器端到设备端的设备控制消息转发。从而实现物联网设备的数据采集，和对设备的操作和控制。
到目前为止，比较流行的 MQTT Broker 有几个：使用 C 语言实现的 MQTT Broker，使用 Erlang 语言开发的 MQTT Broker，使用 Node.JS 开发的 MQTT Broker，同样使用 Erlang 开发的 MQTT Broker。从支持 MQTT5.0、稳定性、扩展性、集群能力等方面考虑，EMQX 的表现应该是最好的。
与别的MQTT服务器相比EMQ X 主要有以下的特点：经过+版本的迭代，EMQ X 目前为开源社区中最流行的 MQTT 消息中间件，在各种客户严格的生产环境上经受了严苛的考验；支持丰富的物联网协议，包括 MQTT、MQTT-SN、CoAP、jboss 源码在哪 LwM2M、LoRaWAN 和 WebSocket等；优化的架构设计，支持超大规模的设备连接。企业版单机能支持百万的 MQTT 连接；集群能支持千万级别的 MQTT 连接；易于安装和使用；灵活的扩展性，支持企业的一些定制场景；中国本地的技术支持服务，通过微信、QQ等线上渠道快速响应客户需求；基于 Apache 2.0 协议许可，完全开源。EMQ X 的代码都放在 Github 中，用户可以查看所有源代码；EMQ X 3.0 支持 MQTT 5.0 协议，是开源社区中第一个支持 5.0协议规范的消息服务器，并且完全兼容 MQTT V3.1 和 V3.1.1 协议。除了 MQTT 协议之外，EMQ X 还支持别的一些物联网协议；单机支持百万连接，集群支持千万级连接；毫秒级消息转发。EMQ X 中应用了多种技术以实现上述功能；利用 Erlang/OTP 平台的软实时、高并发和容错（电信领域久经考验的语言）；全异步架构；连接、会话、路由、集群的分层设计；消息平面和控制平面的分离等；扩展模块和插件，EMQ X 提供了灵活的扩展机制，可以实现私有协议、认证鉴权、数据持久化、桥接发和管理控制台等的扩展；桥接：EMQ X 可以跟别的消息系统进行对接，比如 EMQ X Enterprise 版本中可以支持将消息转发到 Kafka、RabbitMQ 或者别的 EMQ 节点等；共享订阅：共享订阅支持通过负载均衡的方式在多个订阅者之间来分发 MQTT 消息。比如针对物联网等 数据采集场景，会有比较多的设备在发送数据，通过共享订阅的方式可以在订阅端设置多个订阅者来实现这几个订阅者之间的工作负载均衡。
典型的物联网平台包括设备硬件、数据采集、数据存储、分析、Web / 移动应用等。EMQX 位于数据采集这一层，分别与硬件和数据存储、分析进行交互，是物联网平台的核心：前端的硬件通过 MQTT 协议与位于数据采集层的 EMQX 交互，通过 EMQX 将数据采集后，通过 EMQX 提供的数据接口，将数据保存到后台的持久化平台中（各种关系型数据库和 NOSQL 数据库），或者流式数据处理框架等，上层应用通过这些数据分析后得到的结果呈现给最终用户。
EMQX 公司主要提供三个产品，可在官网首页产品导航查看每一种产品；主要体现在支持的连接数量、产品功能和商业服务等方面的区别。
完整的 MQTT V3.1/V3.1.1 及 V5.0 协议规范支持；QoS0, QoS1, QoS2 消息支持；持久会话与离线消息支持；Retained 消息支持；Last Will 消息支持；TCP/SSL 连接支持；MQTT/WebSocket/SSL 支持；HTTP 消息发布接口支持；$SYS/# 系统主题支持；客户端在线状态查询与订阅支持；客户端 ID 或 IP 地址认证支持；用户名密码认证支持；LDAP 认证；Redis、MySQL、PostgreSQL、MongoDB、HTTP 认证集成；浏览器 Cookie 认证；基于客户端 ID、IP 地址、用户名的访问控制 (ACL)；多服务器节点集群 (Cluster)；支持 manual、mcast、dns、etcd、k8s 等多种集群发现方式；网络分区自动愈合；消息速率限制；连接速率限制；按分区配置节点；多服务器节点桥接 (Bridge)；MQTT Broker 桥接支持；Stomp 协议支持；MQTT-SN 协议支持；CoAP 协议支持；Stomp/SockJS 支持；延时 Publish ($delay/topic)；Flapping 检测；黑名单支持；共享订阅 ($share/:group/topic)；TLS/PSK 支持；规则引擎；空动作 (调试)；消息重新发布；桥接数据到 MQTT Broker；检查 (调试)；发送数据到 Web 服务。
EMQ X 目前支持的操作系统：Centos6、Centos7、OpenSUSE tumbleweed、Debian 8、Debian 9、Debian 、Ubuntu .、Ubuntu .、Ubuntu .、macOS .、macOS .、macOS .、Windows Server 。产品部署建议 Linux 服务器，不推荐 Windows 服务器。安装的方式有很多种，可供自由选择：Shell脚本安装、包管理器安装、二进制包安装、ZIP压缩包安装、Homebrew安装、Docker运行安装、Helm安装、源码编译安装。
Dashboard界面查看基本信息。
身份认证是大多数应用的重要组成部分，MQTT 协议支持用户名密码认证，启用身份认证能有效阻止非法客户端的连接。EMQ X 中的认证指的是当一个客户端连接到 EMQ X 的时候，通过服务器端的配置来控制客户端连接服务器的权限。EMQ X 的认证支持包括两个层面：MQTT 协议本身在 CONNECT 报文中指定用户名和密码，EMQ X 以插件形式支持基于 Username、ClientID、HTTP、JWT、LDAP 及各类数据库如 MongoDB、MySQL、PostgreSQL、Redis 等多种形式的认证；在传输层上，TLS 可以保证使用客户端证书的客户端到服务器的身份验证，并确保服务器向客户端验证服务器证书。也支持基于 PSK 的 TLS/DTLS 认证。
EMQ X 支持使用内置数据源（文件、内置数据库）、JWT、外部主流数据库和自定义 HTTP API 作为身份认证数据源。连接数据源、进行认证逻辑通过插件实现的，每个插件对应一种认证方式，使用前需要启用相应的插件。客户端连接时插件通过检查其 username/clientid 和 password 是否与指定数据源的信息一致来实现对客户端的身份认证。（v5.0以上默认集成）EMQ X 支持的认证方式：内置数据源、外部数据库、其他。认证结果：认证成功、认证失败、忽略认证（ignore）。
EMQ X 默认配置中启用了匿名认证，任何客户端都能接入 EMQ X。没有启用认证插件或认证插件没有显式允许/拒绝（ignore）连接请求时，EMQ X 将根据匿名认证启用情况决定是否允许客户端连接。
可以订阅多个主题。
安装 paho-mqtt：导入 Paho MQTT 客户端。
通过TCP连接：设置 broker、port、topic、client_id，连接 MQTT Broker。
通过SSL/TLS连接：设置 broker、port、topic、client_id，连接 MQTT Broker，使用 CA certificate，设置用户名密码。
订阅主题：设置 on_message 回调函数，当收到消息时执行。
取消订阅：通过以下代码取消订阅，此时应指定取消订阅的主题。
发布消息：通过以下代码发布消息，设置消息内容、主题，调用 publish 方法。
接收消息：通过以下代码指定客户端对消息事件进行监听，并在收到消息后执行回调函数，将接收到的消息及其主题打印到控制台。
断开连接：如客户端希望主动断开连接，可以通过如下代码实现。
完整代码：导入 random、time、paho.mqtt.client as mqtt_client，设置 broker、port、topic、client_id，连接 MQTT Broker，设置 on_connect 回调函数，设置 publish 回调函数，运行客户端。
kafka源码Topic的创建源码分析(附视频)
关于Kafka Topic创建的源码分析，可以从kafka-topic.sh脚本的入口开始，它执行了kafka.admin.TopicCommand类。在创建Topic时，主要涉及AdminClientTopicService对象的创建和AdminClientClient创建Topics方法的调用，其中Controller负责处理客户端的CreateTopics请求。
服务端的处理逻辑在KafkaRequestHandler.run()方法中，通过apis.handle(request)调用对应接口，如KafkaApis.handleCreateTopicsRequest，这个方法会触发adminManager.createTopics()，创建主题并监控其完成状态。创建的Topic配置和分区副本信息会被写入Zookeeper，如Topic配置和Topic的分区副本分配。
当Controller监听到/brokers/topics/Topic名称的变更后，会触发Broker在磁盘上创建相关Log文件。如果Controller在创建过程中失败，如Controller挂掉，待重新选举后，创建过程会继续，直到Log文件被创建并同步到zk中。
创建Topic时，zk上会创建特定节点，包括主题配置和分区信息。手动添加或删除/brokers/topics/节点将影响Topic的创建和管理。完整参数可通过sh bin/kafka-topic -help查看。
源码解析kafka删除topic
本文以kafka0.8.2.2为例，解析如何删除一个topic以及其背后的关键技术和源码实现过程。
删除一个topic涉及两个关键点：配置删除参数以及执行删除操作。
首先，配置参数`delete.topic.enable`为`True`，这是Broker级别的配置，用于指示kafka是否允许执行topic删除操作。
其次，执行命令`bin/kafka-topics.sh --zookeeper zk_host:port/chroot --delete --topic my_topic_name`，此命令指示kafka删除指定的topic。
若未配置`delete.topic.enable`为`True`，topic仅被标记为删除状态，而非立即清除。此时，通常的做法是手动删除Zookeeper中的topic信息和日志，但这仅会清除Zookeeper的数据，并不会真正清除kafkaBroker内存中的topic数据。因此，最佳做法是配置`delete.topic.enable`为`True`，然后重启kafka。
接下来，我们介绍几个关键类和它们在删除topic过程中的作用。
1. **PartitionStateMachine**：该类代表分区的状态机，决定分区的当前状态及其转移。状态包括：NonExistentPartition、NewPartition、OnlinePartition、OfflinePartition。
2. **ReplicaManager**：负责管理当前机器的所有副本，处理读写、删除等具体操作。读写操作流程包括获取partition对象，再获取Replica对象，接着获取Log对象，并通过其管理的Segment对象将数据写入、读出。
3. **ReplicaStateMachine**：副本的状态机，决定副本的当前状态和状态之间的转移。状态包括：NewReplica、OnlineReplica、OfflineReplica、ReplicaDeletionStarted、ReplicaDeletionSuccessful、ReplicaDeletionIneligible、NonExistentReplica。
4. **TopicDeletionManager**：管理topic删除的状态机，包括发布删除命令、监听并开始删除topic、以及执行删除操作。
在删除topic的过程中，分为四个阶段：客户端执行删除命令、未配置`delete.topic.enable`的流水、配置了`delete.topic.enable`的流水、以及手动删除Zookeeper上topic信息和磁盘数据。
客户端执行删除命令时，会在"/admin/delete_topics"目录下创建topicName节点。
未配置`delete.topic.enable`时，topic删除流程涉及监听topic删除命令、判断`delete.topic.enable`状态、标记topic为不可删除、以及队列删除topic任务。
配置了`delete.topic.enable`时，额外步骤包括停止删除topic、检查特定条件、更新删除topic集合、激活删除线程、执行删除操作，如解除分区变动监听、清除内存数据结构、删除副本数据、删除Zookeeper节点信息等。
关于手动删除Zookeeper上topic信息和磁盘数据，通常做法是删除Zookeeper的topic相关信息及磁盘数据，但这可能导致部分内存数据未清除。是否会有隐患，需要进一步测试。
总结而言，kafka的topic删除流程基于Zookeeper实现，通过配置参数、执行命令、管理状态机以及清理相关数据，以实现topic的有序删除。正确配置`delete.topic.enable`并执行删除操作是确保topic完全清除的关键步骤。