goMars的学习随记

Kafka调优概述调优是为了满足系统常见的非功能性需求。在众多的非功能性需求中，性能绝对是我们最关心的那一个。不同的系统对性能有不同的诉求，比如对于数据库用户而言，性能意味着请求的响应时间，用户总是希望查询或更新请求能够被更快地处理完并返回。对 Kafka 而言，性能一般是指吞吐量和延时 吞吐量：也就是 TPS，是指 Broker 端进程或 Client 端应用程序每秒能处理的字节数或消息数，这个值自然是越大越好 延时：它表示从 Producer 端发送消息到 Broker 端持久化完成之间的时间间隔，也就是从Producer 发送消息到 Consumer 成功消费该消息的总时长，和 TPS 相反，我们通常希望延时越短越好 为了达到高吞吐低时延，将从以下4个方面进行调优： 应用程序层：它是指优化 Kafka 客户端应用程序代码。比如，使用合理的数据结构、缓存计算开销大的运算结果，抑或是复用构造成本高的对象实例等。这一层的优化效果最为明显，通常也是比较简单的 框架层：它指的是合理设置 Kafka 集群的各种参数。毕竟，直接修改 Kafka 源码进行调优并不容易，但根据实际场景恰当地 ...

Kafka保证消息有序性概述在消息队列里面，有序消息是指消费者消费某个 topic 消息的顺序，和生产者生产消息的顺序一模一样，它也叫做顺序消息。前面你应该注意到了，Kafka 并不能保证不同分区之间的顺序，所以需要特殊手段来实现有序消息。 一般消息有序性指的是某个 topic 内的消息有序，而不是跨 topic 的有序消息； 跨 topic 的有序消息： 这种场景在事件驱动的架构中更加常见。在复杂的事件驱动架构下，我们可能会倾向于使用不同的 topic 来代表不同的事件，那么就会遇到要求在不同的 topics 下消息依旧需要保持有序的问题。 这一类的问题是不能依赖于消息队列来解决的。要想支持这种跨 topic 的有序消息，一定要引入一个协调者，这个协调者负责把消息重组为有序消息。比如说，如果 msg2 先到了，但是 msg1 还没出来，那么这个协调者要有办法让 msg2 的消费者 B 停下来，暂时不消费 msg2。而在 msg1 来了之后，唤醒消费者 A 消费 msg1，并且在消费完 msg1 之后要再唤醒消费者 B 处理 msg2。 实现思路消息发送单分区要保证消息有 ...

Kafka-Kraft模式概述Kafka-Kraft模式（Kafka Raft）是Apache Kafka的一种新的运行模式，旨在替代传统的ZooKeeper模式。Kraft模式将Kafka的元数据管理从ZooKeeper移除，转而使用Raft协议在Kafka自身内部管理元数据。这种变化简化了Kafka的部署和管理，提高了系统的一致性和可靠性。 架构变化： 左图为 Kafka现有架构，元数据在 zookeeper 中，运行时动态选举 controller，由controller进行Kafka集群管理。 右图为kraft模式架构（实验性)，不再依赖zookeeper集群，而是用三台controller节点代替zookeeper，元数据保存在controller中，由controller直接进行Kafka集群管理。 优点： 简化部署：不再需要单独部署和维护ZooKeeper集群，降低了运维复杂性和成本。 一致性和可靠性：Raft协议提供了强一致性保证，确保元数据在多个节点之间的一致复制，提高了系统的可靠性。 高可用性：通过控制节点的多数共识机制，在少数节点故障的情况下仍能保证集群的 ...

Kafka监控概述Kafka监控对于确保Kafka集群的健康运行和高性能至关重要；但在监控 Kafka 时，如果我们只监控Broker 的话，就难免以偏概全。单个 Broker 启动的进程虽然属于 Kafka 应用，但它也是一个普通的 Java 进程，更是一个操作系统进程。因此，我觉得有必要从 Kafka 主机、JVM和 Kafka 集群本身这三个维度进行监控 监控维度Kafka 主机主机级别的监控是揭示线上问题的第一步，主要包括以下几个方面： 机器负载（Load）：查看主机的负载情况，load average 的值可以揭示系统的整体负载状态。 CPU 使用率：监控 CPU 的使用率，可以使用 top 命令查看单个进程的 CPU 占用情况。 内存使用率：包括空闲内存（Free Memory）和已使用内存（Used Memory），这些指标帮助了解系统内存的使用情况。 磁盘 I/O 使用率：包括读使用率和写使用率，用于监控磁盘的读写性能。 网络 I/O 使用率：监控网络接口的使用情况，了解网络流量和性能。 TCP 连接数：查看系统中打开的 TCP 连接数量，判断网络连接的繁忙程度。 打 ...

Kafka的请求处理机制概述Kafka的请求处理机制是通过“请求/响应”的方式完成的，无论是客户端还是Broker端，它们之间的交互都是通过网络发送请求和接收响应来实现的。Kafka定义了一组协议来处理各种请求，例如PRODUCE请求用于生产消息、FETCH请求用于消费消息、METADATA请求用于请求Kafka集群的元数据信息 常用方法： 顺序处理请求与单独线程处理请求 处理请求的两种简单方法是顺序处理和每个请求使用单独线程处理。顺序处理的实现较为简单，但吞吐量较差，因为每个请求都必须等待前一个请求处理完毕。单独线程处理每个请求则完全异步，虽然避免了阻塞，但线程创建的开销很大，在高频请求场景下难以承受(24丨请求是怎么被处理的？)。 Reactor模式 Kafka使用Reactor模式处理请求，这是一种事件驱动架构，特别适用于多个客户端并发请求的场景。Reactor模式通过一个请求分发线程（Dispatcher）将不同请求分发到多个工作线程处理。Acceptor线程用于请求分发，不涉及具体逻辑处理，因此非常轻量级，具有很高的吞吐量 Kafka的Reactor架构 网络线程 ...

SpringBoot集成KafkaApache Kafka 是一个分布式流处理平台，广泛应用于实时数据处理、日志聚合、流式分析等场景。Spring Boot 提供了简便的方式来集成 Kafka，使得我们可以快速构建 Kafka 生产者和消费者应用。 基本使用 导入依赖： 1234<dependency> <groupId>org.springframework.kafka</groupId> <artifactId>spring-kafka</artifactId></dependency> 编写配置文件： 12345678910spring: kafka: bootstrap-servers: ip1:9092 consumer: group-id: test key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apac ...

消费者概述Kafka消费者是Kafka系统中用于读取并处理Kafka主题（topic）中的消息的组件。Kafka的消费者在消费消息时会从特定的主题和分区中读取数据，然后进行处理。 消费模式：由于推模式很难考虑到每个客户端不同的消费速率，导致消费者无法消费消息而宕机，因此kafka采用的是poll的模式，该模式有个缺点，如果服务端没有消息，消费端就会一直空轮询。 为了避免过多不必要的空轮询，kafka做了改进，如果没消息服务端就会暂时保持该请求，在一段时间内有消息再回应给客户端。 工作流程：Kafka消费者订阅主题后，从指定分区拉取消息，处理并提交消费进度（偏移量）以记录已消费的位置，并在消费者组内通过再均衡机制实现负载均衡和故障恢复，确保每个分区的消息仅被一个组内消费者消费。 消费者组（Consumer Group）：消费者组是Kafka中用于管理和协调多个消费者共同消费一个或多个主题的机制，通过添加多个消费者的消费组，并行处理数据提高消息消费速度 特点： 唯一的组ID：每个消费者组都有一个唯一的组ID，用于标识这个组。 水平扩展：同一消费者组内的多个消费者可以并行消费同一主 ...

BrokerKafka Broker 是 Kafka 集群中的一个节点，负责接收、存储和转发消息。Kafka Broker 是 Kafka 系统的核心组件，负责管理主题、分区和消费者组等关键功能。 节点的服役和退役Broker节点的服役和退役是Kafka集群运维中的重要操作 服役新节点 启动一台新的KafKa服务端（加入原有的Zookeeper集群） 查看原有的 分区信息：kafka-topics.sh --bootstrap-server ip1:9092 --topic test --describe 会发现根本没有新加入的节点 进行分区重新负载均衡操作： 创建一个要负载均衡的主题：vim topics-to-move.json 1234567{ "topics": [ {"topic": "test"} ], "version": 1} 生成负载均衡计划（将新的broker加入，这里只是让我们查看方案）：kafka-reassign-partitio ...

生产者Kafka 生产者（Producer）是 Apache Kafka 中负责将数据（消息）发送到 Kafka 主题（Topics）的一种客户端。生产者通常运行在数据生成端，能够高效地将大规模数据流传输到 Kafka 中，以供消费者（Consumers）处理和分析。 发送消息流程： RecordAccumulator： 在jvm的内存中开辟了一块缓存空间，是多个双端队列（方便内存的回收），用于将多条消息合并成一个批次，然后由sender线程发送给kafka集群。 生产者最后还会处理发送结果：生产者处理 Broker 返回的响应。如果消息成功发送，生产者会收到成功确认，结束请求、清理队列。如果发送失败，生产者可以重试或根据配置处理错误。 生产者重要参数总结： 参数名称 描述 bootstrap.servers 生产者连接集群所有的 broker 地址清单。例如 ip1:9092, ip2:9092, ip3:9092，可以设置 1 个或者多个，中间用逗号隔开。注意这里并非需要所有的 broker 地址，因为生产者从给定的 broker 里查找到其他 broker 信息 ...

Guava限流器概述Guava 是由 Google 开源的一个 Java 工具库，其中包含了很多实用工具类。RateLimiter 是 Guava 提供的一个限流器，用于限制代码的执行速率。它基于令牌桶算法实现，适用于控制请求速率、限制并发等场景 RateLimiter 提供了两种限流模式： 平滑突发限流（SmoothBursty）：适用于允许短时间内的突发请求，然后平滑地限制速率 平滑预热限流（SmoothWarmingUp）：适用于系统需要一段时间预热后达到稳定速率的场景 具体实现引入依赖 在 Maven 的 pom.xml 文件中引入 Guava 依赖： 12345<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>30.1-jre</version></dependency> 配置限流器 在 Spring Boot 应用中，可以使用 Ra ...