Kafka系统

一、Kafka系统架构

Kafka 是一个分布式的基于发布/订阅模式的消息队列(Message Queue)，主要应用于 大数据实时处理领域。官网（https://kafka.apachecn.org/）
Kafka集群的运维架构
https://www.processon.com/diagraming/644519413e18672947a5cdb4

Producer：消息生产者，就是向kafka broker发消息的客户端。
Consumer： 消息消费者，是kafka broker获取消息的客户端。
Consumer Group（CG）： 消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费组，即消费者组是逻辑上的一个订阅者。
Broker：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
Topic：主题，可以理解为一个队列，生产者和消费者面向的都是一个topic。
Partition： 分区，为了实现扩展性，一个非常大的topic可以分不到多个broker（服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。
Replica： 副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。
Leader： 每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。
Follower： 每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的leader。
ZooKeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。

二、Kafka重点概念

Consumer Group（CG）： 消费者组

如果没有消费者组（Consumer Group），以下是一些可能的情况和影响：

1. 消息积压：在没有消费者组的情况下，每个消费者都将独立地消费所有分区中的消息。这意味着每个消费者都将尝试消费所有的消息，无论其它消费者是否已经消费过。这可能导致消息的重复消费和积压，因为没有机制来确保消息只被消费一次。
2. 负载不均衡：没有消费者组时，每个消费者独立消费所有分区的消息。如果分区数较多或消费者数较少，可能导致某些消费者负载较重，而其他消费者负载较轻的情况。这会导致负载不均衡，可能导致性能下降或某些消费者无法及时处理消息。
3. 缺乏容错能力：没有消费者组时，如果某个消费者出现故障或停机，将没有其他消费者能够接管其消费的分区。这可能导致该分区上的消息无法及时处理，直到故障消费者恢复或新的消费者加入。
4. 无法进行扩展：没有消费者组时，无法通过简单地增加消费者来扩展系统的处理能力。每个消费者都会尝试消费所有分区的消息，增加消费者数量并不会提高系统的并发处理能力。

因此，使用消费者组是Kafka中实现可伸缩性、负载均衡和容错能力的重要机制。消费者组将消费者组织在一起，协调和分配分区给消费者，确保消息的有序消费和负载均衡。通过使用消费者组，可以提高Kafka系统的性能、可用性和可扩展性。

当使用消费者组（Consumer Group）时，Kafka的行为和特性将会有以下影响：

1. 分区分配：Kafka将根据消费者组的配置和策略来进行分区的分配。每个消费者组中的消费者将被分配到特定的分区，以确保每个分区只被一个消费者所消费。这种分区分配机制确保了消息的有序性和负载均衡，避免了重复消费和部分消费的问题。
2. 并发消费：消费者组中的每个消费者可以并行地消费分配给它们的分区中的消息。这意味着，对于具有多个分区的主题，消费者组可以同时处理多个分区中的消息，提高了整体的消费速率和吞吐量。
3. 动态扩展：使用消费者组，可以很容易地扩展消费者数量。新加入的消费者将被自动分配到可用的分区上，并与其他消费者共同处理消息。这使得系统具有更好的伸缩性和容错能力，可以根据实际需求进行弹性扩展。
4. 会话管理和偏移量提交：消费者组会跟踪每个消费者的消费进度，并将偏移量（offset）存储在内部主题中。这样，当消费者停机或重新加入时，它们可以从上次提交的偏移量处继续消费，而无需重复处理已经消费的消息。消费者组的偏移量管理提供了消息消费的灵活性和可靠性。

通过使用消费者组，Kafka实现了高可用、负载均衡、故障容错和动态扩展等重要功能。消费者组的使用使得多个消费者可以协同工作，共同处理大量的消息流，并提供了更可靠和高效的消息处理机制。

Kafka 不再依赖 ZooKeeper？

Kafka 引入 ZooKeeper 是为了实现分布式消息传递系统的可靠性和高可用性。ZooKeeper 是一个分布式的协调服务，提供了一个分布式系统中的集中式管理和协调功能。在 Kafka 中，ZooKeeper 被用作元数据的存储和管理、Brokers 的选举和故障恢复、消费者的组管理等。

以下是 Kafka 引入 ZooKeeper 的几个主要原因：

1.元数据存储和管理：Kafka 使用 ZooKeeper 来存储和管理与集群相关的元数据信息，如主题（topics）、分区（partitions）的分布、副本（replicas）的位置等。这些元数据的存储和访问需要一种分布式的协调服务，ZooKeeper 提供了可靠的存储和访问机制。

2.Brokers 选举和故障恢复：Kafka 集群中的每个 Broker 都可以成为一个 Leader，负责处理特定分区的读写请求。当一个 Leader Broker 发生故障或下线时，ZooKeeper 被用来进行新的 Leader 的选举，并通知其他 Broker 切换到新的 Leader。这样可以确保集群的高可用性和故障恢复。

3.消费者组管理：Kafka 的消费者可以组成一个消费者组来并行地消费消息。ZooKeeper 被用来存储和管理消费者组的偏移量（offset），即每个消费者在分区中读取的位置信息。消费者组的协调和偏移量的管理需要一个集中的协调服务，ZooKeeper 提供了这样的功能。

需要注意的是，Kafka 社区正在逐渐将对 ZooKeeper 的依赖降低，计划以 Kafka 内部的元数据存储系统来替代 ZooKeeper。从 Kafka 2.8 版本开始，引入了一项功能称为 KRaft，它是一种内部元数据存储系统，用于替代 ZooKeeper 的角色。这样可以简化 Kafka 的部署和维护，并减少对外部依赖的需求。然而，目前仍然建议使用 ZooKeeper 来支持较早版本的 Kafka。

从Kafka 2.8 版本开始，Kafka 引入了一项名为 KRaft 的功能，用于替代 ZooKeeper 的角色。这引发了一个常见问题：为什么 Kafka 不再依赖 ZooKeeper？

以下是一些原因：

1.简化部署和维护：使用 ZooKeeper 需要额外安装、配置和管理一个独立的分布式协调服务。这增加了整个系统的复杂性和维护成本。通过引入 KRaft，Kafka 可以在内部处理元数据存储和管理，从而简化了部署和维护过程。

2.减少依赖和单点故障：使用 ZooKeeper 作为外部的协调服务存在单点故障的风险。如果 ZooKeeper 发生故障或出现性能问题，可能会对整个 Kafka 集群产生影响。通过使用内部的元数据存储系统，Kafka 可以减少对外部依赖的需求，并提供更好的容错性。

3.更好的一致性和性能：KRaft 使用复制日志的方式来实现元数据的存储和管理。这种方式可以提供更高的一致性和可靠性，因为每个 Kafka Broker 都维护了完整的元数据副本。此外，KRaft 还具有更高的性能，因为它可以直接在 Broker 内部进行元数据操作，而无需通过网络访问外部的协调服务。

需要注意的是，尽管 Kafka 引入了 KRaft，但这个过程是逐步进行的，旨在平滑地迁移现有的 Kafka 部署。目前仍然支持使用 ZooKeeper 的方式运行 Kafka，特别是对于较早版本的 Kafka，建议继续使用 ZooKeeper。

三、Kafka集群容灾

Kafka集群容灾概念：

是指在Kafka集群中，为了避免因单点故障而导致整个集群不可用，采取一系列措施保障集群的高可用性和数据的可靠性。

Kafka集群容灾目的：

确保Kafka集群在出现故障或异常情况时仍然能够继续提供服务，以保证数据的可靠性和一致性。展开来说，Kafka集群容灾的目的包括
1.提高集群的可用性：通过实现多副本机制，保证数据的冗余和备份，避免单点故障，提高集群的可用性。
2.保证数据的可靠性：通过保证数据的一致性和完整性，避免数据丢失或损坏，确保数据的可靠性。
3.实现故障自动切换：通过实现副本间的自动同步和数据复制，可以实现故障自动切换，避免对业务的影响。
4.提高系统的稳定性：通过实现监控和警报机制，可以及时发现和处理潜在的故障情况，保证系统的稳定性。
综上所述，Kafka集群容灾的主要目的是提高集群的可用性、保证数据的可靠性、实现故障自动切换、提高系统的稳定性，从而确保业务的连续性和数据的安全性。

Kafka集群容灾机制：

1.副本复制：Kafka使用副本复制机制来保证数据的容灾和高可用性。每个主题的分区可以配置为多个副本，其中一个副本被指定为领导者（leader），其他副本为追随者（follower）。领导者负责处理客户端的读写请求，而追随者则通过复制领导者的数据来提供冗余和故障恢复能力。如果领导者失败，一个追随者将会被选举为新的领导者。
2.ISR（In-Sync Replicas）机制：Kafka中的副本分为同步副本（ISR）和落后副本（Out-of-Sync Replica）。同步副本是指已经追上领导者的副本，它们保证了消息的一致性和可用性。落后副本是指还未追上领导者的副本，它们需要追赶同步副本的进度。ISR机制确保只有同步副本才能被选为领导者，保证了数据的一致性和可靠性。
3.多数据中心复制：Kafka支持跨数据中心的数据复制，实现了地理分布式的容灾和故障恢复。通过设置多个数据中心，将主题的分区复制到不同的数据中心，以确保在一个数据中心发生故障时，另一个数据中心可以继续提供服务。
4.消费者偏移量提交：Kafka消费者可以将消费偏移量（offset）提交到内部的Kafka主题中。这样，即使消费者发生故障或重启，它们可以根据上次提交的偏移量继续消费消息，确保消费者的位置信息不会丢失。
5.监控和警报：Kafka提供了监控和警报机制，可以实时监控集群的健康状态和性能指标。通过监控和警报，可以及时发现和处理潜在的故障情况，保证系统的可用性和稳定性。
这些容灾机制使得Kafka能够提供高度可靠的消息传递和持久性存储，适用于大规模和关键性的数据处理场景。管理员可以根据实际需求和业务要求配置和调整这些机制，以满足特定的容灾需求。

EFAK和SkyWalking来监控Kafka系统：

EFAK是开源可视化和管理软件。可以查询、可视化、监控kafka集群，是将 kafka 的集群数据转换为图形可视化的工具。
SkyWalking是一款开源的应用性能监控系统，可以用于监控Kafka的性能指标和调用链路，以帮助用户快速识别并解决Kafka性能问题。
具体而言，SkyWalking可以监控Kafka的以下性能指标：
1.生产者和消费者的请求吞吐量、延迟等指标
2.Broker节点的网络流量、磁盘使用率、连接数等指标
3.Topic和Partition级别的消息堆积情况和消费进度等指标
4.Kafka集群的状态和健康状况等指标

同时，SkyWalking还可以通过采集消息元数据，生成Kafka消息的调用链路，用于诊断和定位性能问题，例如：
1.生产者和消费者的消息发送、接收、处理过程
2.Broker节点的消息读取、写入、存储过程
3.Topic和Partition的消息路由、分发、复制过程
4.客户端和服务器之间的网络传输过程等
因此，在使用Kafka时，结合SkyWalking进行性能监控和调优可以有效提高系统的稳定性和可靠性，降低故障风险，提高用户体验。