Linger

这是一篇关于 Kafka 实践的文章，内容来自 DataWorks Summit/Hadoop Summit（Hadoop Summit）上的一篇分享，里面讲述了很多关于 Kafka 配置、监控、优化的内容，绝对是在实践中总结出的精华，有很大的借鉴参考意义，本文主要是根据 PPT 的内容进行翻译及适当补充。 Kafka 的架构这里就不多做介绍了，直接步入正题。 Kafka 基本配置及性能优化 这里主要是 Kafka 集群基本配置的相关内容。 硬件要求 Kafka 集群基本硬件的保证 OS 调优 OS page cache：应当可以缓存所有活跃的 Segment（Kafka 中最基本的数据存储单位）； fd 限制：100k+； 禁用 swapping：简单来说，swap 作用是当内存的使用达到一个临界值时就会将内存中的数据移动到 swap 交换空间，但是此时，内存可能还有很多空余资源，swap 走的是磁盘 IO，对于内存读写很在意的系统，最好禁止使用 swap 分区； TCP 调优 JVM 配置 JDK 8 并且使用 G1 垃圾收集器 至少要分配 6-8 GB 的堆内存 Kafka 磁盘存储 使用多块磁盘，并配置为 Kafka 专用的磁盘； JBOD vs RAID10； JBOD（Just a Bunch of Disks，简单来说它表示一个没有控制软件提供协调控制的磁盘集合

上一篇 说了一个案例是为了说明如何去考量一个Kafka集群的部署，算是一个参考吧，毕竟大家在不同的公司工作肯定也会有自己的一套实施方案。 这次我们再回到原理性的问题，这次会延续 第一篇 的风格，带领大家把图一步一步画出来。 Kafka的Producer原理 首先我们得先有个集群吧，然后集群中有若干台服务器，每个服务器我们管它叫Broker，其实就是一个个Kafka进程。 如果大家还记得 第一篇 的内容，就不难猜出来，接下来肯定会有一个controller和多个follower，还有个ZooKeeper集群，一开始我们的Broker都会注册到我们的ZooKeeper集群上面。 然后controller也会监听ZooKeeper集群的变化，在集群产生变化时更改自己的元数据信息。并且follower也会去它们的老大controller那里去同步元数据信息，所以一个Kafka集群中所有服务器上的元数据信息都是一致的。 上述准备完成后，我们正式开始我们生产者的内容。 名词1——ProducerRecord 生产者需要往集群发送消息前，要先把每一条消息封装成ProducerRecord对象，这是生产者内部完成的。之后会经历一个序列化的过程。之前好几篇专栏也是有提到过了，需要经过网络传输的数据都是二进制的一些字节数据，需要进行序列化才能传输。 此时就会有一个问题

本文介绍如何在springboot项目中集成kafka收发message。 1、先解决依赖 springboot相关的依赖我们就不提了，和kafka相关的只依赖一个spring-kafka集成包 <dependency> <groupId>org.springframework.kafka</groupId> <artifactId>spring-kafka</artifactId> <version>1.1.1.RELEASE</version> </dependency> 这里我们先把配置文件展示一下 #============== kafka =================== kafka.consumer.zookeeper.connect=10.93.21.21:2181 kafka.consumer.servers=10.93.21.21:9092 kafka.consumer.enable.auto.commit=true kafka.consumer.session.timeout=6000 kafka.consumer.auto.commit.interval=100 kafka.consumer.auto.offset.reset=latest kafka.consumer.topic=test kafka.consumer.group.id=test

最近，遇到某个集群的生产端发送延迟特别高，而且吞吐量上不去，检查集群负载却很低，且集群机器配置非常好，网络带宽也很大，于是使用 Kafka 压测脚本进行了压测。 昨天凌晨，在生产环境进行实战调优，经过不断参数改动，现将生产者相关参数设置为以下配置： linger.ms=50 batch.size=524288 compression.type=lz4 acks=1（用户要求消息至少要发送到分区 leader） max.request.size=5242880 buffer.memory=268435456 在生产环境的一台服务器上，使用以上参数对集群进行生产发送性能压测： 从上图可以看到，使用平均 4k 大小的消息体对集群进行压测， 单个 Producer 平均吞吐量达到 2000MB/s，50w/s+ ！ 作为对比，我还是使用同一台服务器，将调优参数去掉，再压一遍： 可以看到，最高的吞吐量也不过 500M/s，最低已经来到 2M/s 了。 虽然说实际客户端环境比压测环境复杂很多，但是使用压测工具已经能够证明，该集群的负载目前现在还远远没有达到瓶颈，且生产端还有待优化。 以上参数调优思想是： 1、buffer.memory=268435456 由于发送端发送频率非常快，加上由于 Spark 客户端频繁断开连接导致生产端 Sender 线程发送延迟增高，这就会造成客户端发送速率 >

在双十一过程中投入同样的硬件资源，Kafka 搭建的日志集群单个Topic可以达到几百万的TPS；而使用RocketMQ组件的核心业务集群，集群TPS只能达到几十万TPS，这样的现象激发了我对两者性能方面的思考。 温馨提示： TPS只是众多性能指标中的一个，我们在做技术选型方面要从多方面考虑，本文并不打算就消息中间件选型方面投入太多笔墨，重点想尝试剖析两者在性能方面的设计思想。 01 文件布局 1.1 Kafka 文件布局 Kafka 文件在宏观上的布局如下图所示： 正如上图所示，Kafka 文件布局的主要特征如下： 文件的组织以 topic + 分区进行组织，每一个 topic 可以创建多个分区，每一个分区包含单独的文件夹，并且是多副本机制。即 topic 的每一个分区会有 Leader 与 Follow，并且 Kafka 内部有机制保证 topic 的某一个分区的 Leader 与 follow 不会存在在同一台机器，并且每一台 broker 会尽量均衡的承担各个分区的 Leader，当然在运行过程中如果不均衡，可以执行命令进行手动重平衡。Leader 节点承担一个分区的读写，follow 节点只负责数据备份。 Kafka 的负载均衡主要依靠分区 Leader 节点的分布情况 。 分区的 Leader 节点负责读写，而从节点负责数据同步

1、 Socket的工作流程 Socket实质上提供了进程通信的端点。进程通信之前，双方首先必须各自创建一个端点，否则是没有办法建立联系并相互通信的。正如打电话之前，双方必须各自拥有一台电话机一样。 对于一个功能齐全的Socket，都要包含以下结构，其工作流程包含以下四个基本步骤： （1） 创建Socket （2） 打开连接到Socket的输入/输出流 （3） 按照一定的协议对Socket进行读/写操作 （4） 关闭Socket 2、 java中的Socket java中的socket通信主要通过两个已经封装好的类ServerSocket和Socket socket通常开发的是客户端，用来让客户端通过端口号和IP地址连接到远程服务器。而ServerSocket实现的则是一个服务器应用，ServerSocket会一直等待客户端的请求，一旦获得了一个连接请求，就创建一个socket示例来与客户端进行通信。ServerSocket会绑定一个固定的端口，知晓此端口和远程服务器的客服端可以通过IP地址和端口号来与远程客户端通信，而服务端的端口则是随机的，在socket的应用中，我们并不关心客户端的端口号。 3、 实现 Java中的socket在底层实现时最终是通过调用系统的socket来实现的，下面是java中的socket类的继承关系

记一次 Kafka Producer 性能调优实战 https://objcoding.com/2020/09/18/kafka-producer-performance-optimization/ 最近，遇到某个集群的生产端发送延迟特别高，而且吞吐量上不去，检查集群负载却很低，且集群机器配置非常好，网络带宽也很大，于是使用 Kafka 压测脚本进行了压测。 昨天凌晨，在生产环境进行实战调优，经过不断参数改动，现将生产者相关参数设置为以下配置： linger.ms=50 batch.size=524288 compression.type=lz4 acks=1（用户要求消息至少要发送到分区 leader） max.request.size=5242880 buffer.memory=268435456 在生产环境的一台服务器上，使用以上参数对集群进行生产发送性能压测： 从上图可以看到，使用平均 4k 大小的消息体对集群进行压测， 单个 Producer 平均吞吐量达到 2000MB/s，50w/s+ ！ 作为对比，我还是使用同一台服务器，将调优参数去掉，再压一遍： 可以看到，最高的吞吐量也不过 500M/s，最低已经来到 2M/s 了。 虽然说实际客户端环境比压测环境复杂很多，但是使用压测工具已经能够证明，该集群的负载目前现在还远远没有达到瓶颈，且生产端还有待优化。

目录 一、原理简述 二、Producer 原理 三、Producer 端参数详解 四、Kafka Server 基本原理 五、KafkaServer 主分区与副本数据同步原理 六、KafkaServer 零拷贝原理 七、KafkaServer Leader 选举 八、KafkaConsumer 原理 九、KafkaConsumer 参数详解 十、性能优化方案 一、原理简述 【1】 Producer 将消息进行分组分别发送到对应 leader 节点； 【2】 Leader 将消息写入本地 log ； 【3】 Followers 从 Leader pull 最新消息，写入 log 后向 Leader 发送 ack 确认； 【4】 Leader 收到所有 ISR 中的 Follower 节点的 ACK 后，增加 HW ，标记消息已确认全部备份完成，最后返回给 Producer 消息已提交成功； 【5】消费端从对应 Leader 节点 poll 最新消息并消费，消费完成后将最新的 offset 位置提交至 Topic 为 _consumer_offsets 的主节点中保存。 二、Producer 原理 初始化 KafkaProducer，会创建一个后台线程 KafkaThread ，会循环的判断缓存中的数据是否需要提交。同时会发送消息，主要指定 Topic和 Value，不建议指定

1. 简介 Kafka 是 LinkedIn 使用 Scala 编写具有高水平扩展和高吞吐量的分布式消息系统。 Kafka 对消息保存时根据 Topic 进行归类，发送消息者称为 producer，消息接收者称为 consumer，此外 Kafka 集群有多个 Kafka 实例组成，每个实例（server）称为 broker。 无论是 Kafka 集群，还是 producer 和 consumer 都依赖于 zookeeper 来保证系统可用性，为集群保存一些 meta 信息。 2. 主流 MQ 对比 数据吞吐量：Kafka > RabbitMQ > ActiveMQ 数据准确性：RabbitMQ > ActiveMQ > Kafka ActiveMQ RabbitMQ Kafka 所属社区/公司 Apache Mozilla Public License Apache/LinkedIn 开发语言 Java Erlang Scala 支持的协议 OpenWire、STOMP、REST、XMPP、AMQP AMQP 仿 AMQP 事务 支持 不支持 0.11 开始支持 集群 支持（不擅长） 支持（不擅长） 支持 负载均衡 支持 支持 支持 动态扩容 不支持 不支持 支持（zk） 3. Kafka 主要特性 Kafka 是一个流处理平台，流平台需如下特性： 可发布和订阅流数据

TCP 首部中的 RST 比特是用于 "复位" 的。一般来说，无论何时一个报文段发往基准的连接（referenced connection）出现错误，TCP 都会发出一个复位报文段（"基准的连接" 指由目的 IP 地址和目的端口号以及源 IP 地址和源端口号指明的连接）。 1. 到不存在的端口的连接请求 产生复位的一种常见情况是当连接请求达到时，目的端口没有进程正在监听。对于 UDP，当一个数据报到达目的端口时，该端口没有在使用，它将产生一个 ICMP 端口不可达的信息。而 TCP 则使用复位。 如下示例，客户端向目的端口 1935 发送连接请求的起始包 "SYN"，但是端口为 1935 的服务器并没有启动，此时 TCP 回复客户端 RST 报文。 C: SYN -> S(1935) S(1935): RST -> C 2. 异常终止一个连接 终止一个连接的正常方式是一方发送 FIN，有时这也称为有序释放（orderly release），因为在所有排队数据都已发送之后才发送 FIN，正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是 FIN 来中途释放一个连接，有时称这为异常释放（abortive relase）。 异常终止一个连接对应用程序来说有两个优点： 丢弃任何待发送数据并立即发送复位报文段； RST 的接收方会区分另一端执行的是异常关闭还是正常关闭