流华追梦的专栏

接上一篇《（二）Kafka 安全之使用 SSL 的加密和身份验证》，本文从 2.4 小节开始。

接上一篇《（一）Kafka 安全之使用 SASL 进行身份验证 —— JAAS 配置、SASL 配置》，本文从第四节开始。

SASL 是用来认证 C/S 模式也就是服务器与客户端的一种认证机制，全称 Simple Authentication and Security Layer。这就是一种凭据认证方式。通俗的话来讲就是让服务器知道连接进来的客户端的身份是谁。比如凭借阅证到图书馆借书，而每个借阅证都有独立的 ID，通过 ID 定位谁是谁，而不是特别关心谁拿到了借阅证，只需要正确的借阅证即可。所以 SASL 就是服务器存储了客户端的身份证书和如何校验密码是否正确，而且仅在于身份认证过程，认证完毕后即可进行相关的服务操作。

接上一篇《（一）Kafka 安全之使用 SSL 的加密和身份验证》，本文从 2.2 小节开始。

SSL（Secure Sockets Layer）是一种网络协议，提供了一种在客户端和服务器之间建立安全连接的方法。启用 SSL 后，Kafka 集群中的所有数据传输，包括生产者、消费者与 Broker 之间的消息交互都会被加密，确保敏感信息在网络传输过程中不被窃听或篡改。

在配置 Kafka 监听器时，需要注意配置的一致性和正确性。确保 Kafka 集群和消费者端的监听器配置相匹配，避免因配置错误导致的连接问题和数据传输故障。通过正确配置 Kafka 的监听器类型、协议选择和安全性配置，可以实现消息传输和消费端访问的灵活和安全。根据应用需求和安全要求，选择合适的监听器配置，确保 Kafka 集群的可靠性和数据的安全性传输。

Kafka 分层存储通常是通过配置 Kafka 的日志保留策略来实现的，而不是直接通过代码来实现的。Kafka 支持基于时间和基于大小的日志保留策略。Kafka 数据主要是以流式方式使用尾部读取来消耗的。尾部读取利用操作系统的页面缓存来提供数据，而不是磁盘读取。较旧的数据通常是为了回填或故障恢复而从磁盘中读取的，而且这种情况并不常见。KIP-405在分层存储方法中，Kafka 集群配置有两层存储——本地和远程。本地层与当前的 Kafka 相同，后者使用 Kafka Broker 上的本地磁盘来存储日志段。

Kafka 在 3.X 版本后内置了 KRaft 用来替代 ZooKeeper 管理集群，但是在升级的过程中发现，许多升级的文档都是只有新部署安装 KRaft 版本，而没有涉及到数据迁移相关的资料，这样如果直接变更的话，会导致 Kakfa 中的数据全部丢失，这在客户的生产环境中是不可接受的，所以本文把官网的迁移方案作了一下翻译。

目前，Kafka 在使用的过程当中，会出现一些问题。由于重度依赖 Zookeeper 集群，当Zookeeper 集群性能发生抖动时，Kafka 的性能也会收到很大的影响。因此，在 Kafka 发展的过程当中，为了解决这个问题，提供 KRaft 模式，来取消 Kafka 对 Zookeeper 的依赖。

ZooKeeper 是一个分布式的协调服务，主要用于维护集群的元数据信息和配置信息。Kafka 集群依赖于 ZooKeeper 来存储和管理 Kafka 的元数据信息和配置信息。注：以上这些都低版本 Kafka 依赖 ZooKeeper 实现的，在高版本 Kafka 中，已经摆脱了对 ZooKeeper 的强依赖。

接上一篇《（二）Kafka 监控之 Streams 监控（Streams Monitoring）》，本文从 2.7 小节开始。

​接上一篇《（一）Kafka 监控之 Streams 监控（Streams Monitoring）》，本文从 2.5 小节开始。

Kafka Streams 提供了丰富的性能调优和监控工具，以确保应用程序在高负载下稳定运行。通过配置合适的参数和监控指标，可以优化应用程序的性能并提高整体吞吐量。详细的性能调优和监控策略将有助于应对不同规模和复杂度的流处理任务。

Kafka Connect 运行在自己的进程中，独立于 Kafka Broker。它是分布式的、可伸缩的、容错的，就像 Kafka 本身一样。使用 Kafka Connect 不需要编程，因为它只由 JSON 配置驱动。这使得它可以被广泛的用户使用。除了接收和输出数据，Kafka Connect 还可以在数据通过时执行轻量级的转换。

对于 Kafka 消费者来说，监控它们的消费进度非常的重要，或者说是监控它们消费的滞后程度。这个滞后程度有个专门的名称：消费者 Lag 或 Consumer Lag。所谓滞后程度，就是指消费者当前落后于生产者的程度。通常来说，Lag 的单位是消息数，而且我们一般是在 Topic 这个级别上讨论 Lag 的，但实际上，Kafka 监控 Lag 的层级是在分区上的。如果要计算 Topic 级别的，你需要手动汇总所有主题分区的 Lag，将它们累加起来，合并成最终的 Lag 值。

对于大数据集群来说，监控功能是非常必要的，通过日志判断故障低效，我们需要完整的指标来帮我们管理 Kafka 集群。本文将描述 Broker 的公共指标。

Kafka 流控制与监控指标对于确保 Kafka 集群的稳定性和性能至关重要。本文将详细阐述 Kafka 的流控制机制和监控指标，包括 Kafka 生产者、消费者、Connect 和 Streams 的性能指标等。通过了解这些概念并根据实际需求调整配置参数，您可以更好地管理 Kafka 集群并确保其高效运行。

和任何一个分布式系统一样，Kafka 的存储和网络使用情况也是我们需要关注和监控的指标，只有对存储和网络状态进行充分的监控才能及时发现问题并规避风险。

众所周知，Kafka 的集中式设计具有很强的耐用性和容错性。此外，由于 Kafka 是一个分布式系统，因此 Topic 在多个节点之间进行分区和复制。此外，Kafka 可以成为数据集成的极具吸引力的选择，具有有意义的性能监控和对问题的及时警报。基本上，当对 Kafka 问题进行故障排除时，应用程序管理器会向需要采取纠正措施的人收集所有性能指标和警报。

磁盘容量是一个值得讨论的话题，需要多大的磁盘容量取决于需要保留的消息数量。如果服务器每天会收到 1TB 消息，并且保留7天，那么就需要 7TB 的存储空间，而且还要为其他文件提供至少10%的额外空间。除此之外，还需要提供缓冲区，用于应付消息流量的增长和波动。在决定扩展 Kafka 集群规模时，存储容量是一个需要考虑的因素。通过让 Topic 拥有多个分区，集群的总流量可以被均衡到整个集群，而且如果单个 Broker 无法支撑全部容量，可以让其他Broker 提供可用的容量。

生产者客户端的性能直接受到服务端磁盘吞吐量的影响。生产者生成的消息必须被提交到服务器保存，大多数客户端在发送消息之后会一直等待，直到至少有一个服务器确认消息已经成功提交为止。也就是说，磁盘写入速度越快，生成消息的延迟就越低。在考虑硬盘类型对磁盘吞吐量的影响时，是选择传统的机械硬盘（HDD）还是固态硬盘（SSD），我们可以很容易地做出决定。固态硬盘的查找和访问速度都很快，提供了最好的性能。机械硬盘便宜，单块硬盘容量也更大。

Kafka 是 I/O 密集型而非计算密集型的框架，所以对 CPU 的需求是各个指标里最宽松的，消耗CPU 的点主要在于消息的压缩和解压缩。一个 Kafka Broker 节点往往要承载许多个 Topic Partition 并与许多个 Producer/Consumer 交互，所以并行度（核心/线程数）要比单核性能（频率）更重要。一般来讲单节点 8C/16T，主频 2GHz 以上（按 Broadwell 架构计）就可以满足小型生产环境，负载比较重的集群可以配到 12C/24T 甚至 16C/32T。

许多体系结构具有跨多个数据中心部署的事件流，这些数据中心跨越事件流平台、数据中心或地理区域的边界。在这些情况下，一个事件流平台中的客户端应用程序访问另一个平台中生成的事件可能很有用。不应强制所有客户端从源事件流平台读取，这可能会导致高延迟和数据出口成本。相反，使用一次读取多次的方法，可以将数据复制到本地数据中心，在那里客户端可以快速而廉价地完成所有处理。

Kafka 推荐配置即是指 Kafka 生产者、消费者以及 Broker 三者的重要配置，只要这些重要配置设置正确了，那么使用起来便不会有大的问题。比如，生产者的重要配置有 acks、compression、batch.size 等，消费者的重要配置有 fetch.size 等。

接上一篇《（一）Kafka 多租户架构》，本篇第二节从 2.4 小节开始。

Kafka 租户模式是一种多租户架构模式，用于在单个 Kafka 集群中支持多个不同的租户。这种模式可以提供更好的资源隔离和租户管理，同时减少硬件成本和管理复杂性。

许多组织使用 Apache Kafka 构建跨越多个地理分布的数据中心的数据管道，用于从高可用性和灾难恢复到数据聚合和法规遵从性的各种用例。从单集群部署到多集群部署的过程可能会令人望而生畏，因为您需要处理网络配置、安全模型和操作挑战。对 Kafka 的地理复制支持已经取得了长足的进步，开源和商业解决方案都支持各种复制拓扑和灾难恢复策略。

接一篇《（一）Kafka 地理复制之配置地理复制》，第二节从 2.4 小节开始。目标群集中复制的 Topic（有时称为远程 Topic）将根据复制策略进行重命名。MirrorMaker 使用此策略来确保来自不同集群的事件（也称为记录、消息）不会写入同一 Topic 分区。bar-topic。

使用 MirrorMaker，Kafka 管理员可以将 Topic、Topic 配置、消费者组及其偏移量和 ACL 从一个或多个源 Kafka 集群复制到一个或更多个目标 Kafka 群集，即跨集群环境。简而言之，MirrorMaker 使用连接器从源集群消费并生产到目标集群。这些从源集群到目标集群的定向流称为复制流。它们是用格式定义的 {source_cluster}->｛target_cluster｝，如后所述。管理员可以基于这些流创建复杂的复制拓扑。主动/主动高可用性部署：A->B，B->A。

Kafka 节点退役是指将一个节点永久地从集群中移除的过程。节点退役通常发生在节点故障、硬件损坏或集群扩容等情况下。节点退役的原理同样基于 Kafka 的分布式设计和复制机制。当一个节点需要退役时，需要将该节点上的所有分区的 Leader 副本迁移到其他节点上，并将该节点上的所有副本从集群中移除。

可以设置 Kafka 配额以限制网络带宽使用，Kafka 度量此吞吐量 (以字节/秒为单位)。如果发现超过 30 秒窗口的吞吐量超过已设置的配额，那么 Kafka 会计算足够的延迟，以使吞吐量在配额限制内。然后，Kafka Broker 将延迟信息作为标准 Kafka 协议响应的一部分发送给客户机。遵循协议合同的合作客户机在发出新请求之前等待此延迟；不合作客户机可能不遵守调速请求，但在这种情况下，Broker 在调速延迟过去之前不会读取该客户机的请求（这可能导致不合作客户机超时）。

Kafka 集群的服务发现是由 ZooKeeper 实现的，因此 Kafka 集群想添加新的 Broker 就非常容易。我们只需要为新的 Broker 设置一个唯一的 broker.id， 然后启动新增的 Kafka 就行。Kafka 集群会自动发现新增的 Broker 并同步原数据，包括当前集群有哪些 topics 以及 topics 的分区信息等。分区重新分配工具还可以用于选择性地将分区的副本移动到特定的 Broker 集。

Leader 负载均衡是指在分布式系统中，将负载均衡地分配给不同的 Leader 节点，以实现系统的高可用性和性能优化。在 Kafka 中，Leader 负载均衡是通过动态选举和重新分配分区的方式来实现的。Kafka 的分区是分布在多个 Broker（即 Kafka 节点）上的，每个分区都有一个 Leader 和若干个Follower。Leader 负责处理分区的读写请求，而 Follower 则复制 Leader 的数据以提供备份和故障恢复。

本节将回顾您在 Kafka 集群上执行的常见 Topic 的操作。本节中介绍的所有工具都可以在 Kafka 发行版的 bin/ 目录下使用，如果在没有参数的情况下运行，每个工具都会打印所有可能的命令行选项的详细信息。

Kafka 的消息格式是由消息的键和值组成的。每条消息都有一个可选的键和一个必选的值，它们都是字节数组。键和值可以是任意类型的数据，但在发送和接收消息时，它们需要被序列化为字节数组。在 Kafka 中，消息是以字节数组的形式进行传输和存储的。这种灵活的格式使得 Kafka 非常适合处理各种类型的数据，包括结构化数据、文本数据、二进制数据等。Kafka 的消息格式并不限制消息的内容，开发人员可以自由定义消息的格式和结构。这种灵活性使得 Kafka 可以适应各种不同的应用场景和数据类型。

Kafka 提供了消费者客户端参数 partition.assignment.strategy 来设置消费者与订阅主题之间的分区分配策略。默认情况下，此参数的值为 org.apache.kafka.clients.consumer.RangeAssignor，即采用 RangeAssignor 分配策略。除此之外，Kafka 还提供了另外两种分配策略：RoundRobinAssignor 和 StickyAssignor。

Kafka 客户端一般不会碰到大量连接请求，但是 Broker 会遇到，因为它不止收到提供者/消费者的连接请求，还需要收到集群中其他 Broker 的请求，所以对于服务端来说，面临的是高并发场景，客户端使用 NetworkClient 来管理连接就足够了，Server 是不行的，它采用 Reactor 模式实现网络层。

Kafka 强大的应用程序层的基础是用于访问存储的两个基本 API，即用于写入事件的生产者 API和用于读取事件的消费者 API。在这两个 API 之上构建了用于集成和处理的 API。

Kafka 配额对生产和使用请求实施限制，以控制客户机所使用的代理资源。Kafka 配额使管理员能够对单个生产者和使用者应用程序可使用的网络吞吐量实施限制。

Kafka 日志压缩类似于 Redis 持久化的 RDB 模式，假设 Kafka 崩溃，通过日志文件恢复最终状态时，Kafka 只需要关心最新状态，并不关心每一时刻的状态。Kafka 日志压缩主要是针对两种数据：1. Key 值相同的数据，压缩后只记录同 Key 值最新的一条数据；2. Key 不为空，Value 为空的消息，这种消息在日志压缩过程中会被设置为墓碑消息。