下面介绍Kafka的一些重要概念，让大家对Kafka有一个整体的了解和感悟。后面会详细分析各个概念的作用和更深层次的原理。Producer：消息生产者，向KafkaBroker发送消息的客户端。?Consumer：消息消费者，从KafkaBroker获取消息的客户端。?ConsumerGroup：ConsumerGroup（CG），消费组中的每个消费者负责消费来自不同分区的数据，以提高消费能力。一个partition只能被group中的一个consumer消费，consumergroup之间互不影响。所有的消费者都属于一个消费者组，即一个消费者组是一个逻辑上的订阅者。?Broker：Kafka机器是一个Broker。一个集群由多个Broker组成。一个Broker可以容纳多个Topic。?Topic：可以理解为一个队列。主题对消息进行分类。生产者和消费者面对同一个话题。?Partition：为了实现可扩展性和提高并发性，可以将一个非常大的topic分布到多个Broker（服务器）上，一个topic可以划分为多个partition，每个partition是一个有序队列。?Replica：复制，以实现备份功能，保证当集群中某个节点发生故障时，该节点上的Partition数据不会丢失，Kafka仍能继续工作。Kafka提供了复制机制。每个partition的一个Topic有几个副本，一个Leader和几个Follower。?Leader：每个分区的多个副本的“主”副本，生产者发送数据的对象，消费者消费数据的对象都是Leader。?Follower：每个分区的多个副本的“从”副本，实时从Leader同步数据，并与Leader数据保持同步。当Leader失效时，一个Follower也会成为新的Leader。?Offset：consumer消费的位置信息，监听数据消费到哪里，当consumer挂掉再恢复时，可以从消费位置继续消费。?ZooKeeper：Kafka集群能够正常工作，需要依赖ZooKeeper，ZooKeeper帮助Kafka存储和管理集群信息。1.消息和批处理Kafka中的数据单元称为消息。如果您很了解数据库，您可以将它们视为类似于数据库中的行或记录。就Kafka而言，一条消息只是一个字节数组，因此它包含的数据对Kafka没有特定的格式或意义。消息可以有一个可选的元数据位，称为密钥。键也是一个字节数组，和消息一样，对Kafka没有特定的意义。当消息以更受控的方式写入分区时，将使用该密钥。最简单的解决方案是生成键的一致哈希，然后通过取哈希模的结果（主题中的分区总数）来选择该消息的分区号。这可确保具有相同密钥的消息始终写入同一分区。为了效率，消息是分批写入Kafka的。批处理只是一组消息，所有消息都针对相同的主题和分区生成。每条消息在网络上的单独往返会导致过多的开销，通过将消息收集到一个批次中可以减少这种开销。当然，这是延迟和吞吐量之间的权衡：批次越大，单位时间内可以处理的消息越多，但单个消息传播所需的时间也越长。批次通常也被压缩，以牺牲一些处理能力为代价提供更高效的数据传输和存储。1.1消息是Kafka中最小的数据单元，类似于“数据库”中的一条记录；消息由字节数组组成。Kafka没有具体的格式和定义，但是在客户端提供的消息定义中有一组可选的数据单元：publicfinalclassProducerRecord{privatefinalStringtopic;//消息主题privatefinalIntegerpartition;//消息分区私有finalKkey;//消息密钥私有最终V值；//messagevalue}在上面的字段中，只需要消息主题，它标识了这条消息的类别。2.2Batch与我们常说的批处理思想中的batch概念一致；从根本上说，就是降耗增效。如果每个生产者都生成一条消息，我们把它写入网络，会带来很大的开销，所以消息是分批投递的；当然，批处理会带来延迟，所以需要在延迟和吞吐量之间做出权衡，Kafka提供了参数来为开发者优化这个平衡点。单个批次中的消息越多，延迟就越大。同时，消息将被压缩以提高数据传输和存储能力。当然，压缩会消耗更多的CPU。batch中的消息属于同一个topic的同一个partition，可以保证一次发送一批消息时网络开销最小。2.Schemas虽然消息是Kafka本身的不透明字节数组，但是还是建议在消息内容中加入额外的结构或者schemas以便于理解。消息传递架构有多种选择，具体取决于您的应用程序的个别需求。JavascriptObjectNotation(JSON)和可扩展标记语言(XML)等简单系统易于使用和阅读。但是，它们缺乏强大的类型处理和模式版本之间的兼容性等功能。许多Kafka开发人员喜欢使用ApacheAvro，这是一个最初为Hadoop开发的序列化框架。Avro提供了一种紧凑的序列化格式；模式与消息有效负载分离，不需要在更改时生成代码；强大的数据类型和模式演进，具有向后和向前兼容性。一致的数据格式在Kafka中很重要，因为它允许写入和读取消息分开。当这些任务紧密耦合时，订阅消息的应用程序必须更新以处理新数据格式，同时处理旧格式。只有这样，发布消息的应用程序才能更新为使用新格式。通过使用定义良好的模式并将它们存储在公共存储库中，无需协调即可理解Kafka中的消息。3.主题和分区Kafka中的消息是按主题分类的（主题就像数据库中的表），主题可以分为若干个分区（分表技术）。分区本质上是一个提交日志文件。当有新的消息时，消息会以追加的方式（写文件的形式）写入分区，然后按照先进先出的顺序读取。3.1主题是消息的分类标识，类似于文件系统中的文件夹。3.2分区是主题的队列。同一主题将包含多个分区。每个分区都是一个提交记录，消息将附加到分区中。分区保证顺序，按照先进先出的顺序消费。Kafka为每个分区维护一个offset，offset记录当前分区的消费记录，offset保存在分布式协同服务器ZooKeeper上。分区在Kafka中具有重要意义。Kafka通过分区实现topic的数据冗余和横向扩展；多个分区可以分布在不同的Kafka服务器机器上，使得主题可以跨多个服务器存在，保证分布式能力；消息中提到了消息的密钥。当消息没有配置键时，生产者会均衡地将消息写入各个分区。当我们需要将特定消息写入固定分区时，可以通过消息的key和partitioner来实现。partitioner会把key生成一个hash值，映射到各个partition上。为了分散大量消息的负载，要求topic分区的数量大于当前Kafka中broker服务器的数量，以保证所有broker都能分担消息的压力。在实际生产中，我们可以增加分区来扩展话题，但是不能减少分区。选择partition数量是经验问题，需要考虑多个因素：topic需要多少吞吐量，单个partition的最大吞吐量是多少每个broker上的partition数量，需要考虑disk和网络带宽在单个分区上不应该有太多的分区。毕竟分区越多，内存越大，重新选举的时间也就越长。需要注意的是，如果使用消息的key来控制消息写入partition，在添加topic时需要谨慎，因为这会带来rehash的问题。4、生产者和消费者Kafka客户端是系统用户，有两种基本类型：生产者和消费者。还有高级客户端API——用于数据集成的KafkaConnectAPI和用于流处理的KafkaStreams。高级客户端使用生产者和消费者作为构建块，并在顶部提供更高级别的功能。4.1生产者生产者创造新的信息。在其他发布/订阅系统中，这些可能被称为发布者或作者。通常，消息是针对特定主题生成的。默认情况下，生产者不关心将特定消息写入哪个分区，并且会在主题的所有分区之间均匀地平衡消息。在某些情况下，生产者会将消息定向到特定分区。这通常是使用消息密钥和分区程序完成的，分区程序将生成密钥的哈希并将其映射到特定分区。这确保了使用给定密钥生成的所有消息都将写入同一分区。生产者还可以使用遵循其他业务规则的自定义分区程序将消息映射到分区。4.2Consumer消费者阅读消息。在其他发布/订阅系统中，这些客户端可能被称为订阅者或读者。消费者订阅一个或多个主题并按照消息生成的顺序阅读消息。消费者通过跟踪消息的偏移量来跟踪它已经消费了哪些消息。偏移量是元数据-一个不断增加的整数值-Kafka在生成每条消息时添加到它。给定分区中的每条消息都有一个唯一的偏移量。通过在Zookeeper或Kafka本身中存储每个分区的最后一条消费消息的偏移量，可以在不丢失其位置的情况下停止和重新启动消费者。消费者负责消费者组的一部分工作，该消费者组是一个主题的一个或多个分区，它们一起工作以进行消费。该组确保每个分区仅由一个成员使用。在一个组中有三个消费者使用主题。其中两个消费者各在一个分区上工作，而第三个消费者在两个分区上工作。消费者到分区的映射通常称为消费者到分区的所有权。不同的消费者组可以读取同一个主题，但同一个组内的不同消费者不能读取同一个分区。通过这种方式，消费者可以横向扩展以消费具有大量消息的主题。此外，如果单个消费者失败，该组的其余成员将重新平衡消费分区以接管丢失的成员。5.保留消息保留消息是Kafka的一个重要特性。Kafka代理有两种默认的消息保留策略。保持一段固定的时间。比如保存7天，直到消息的字节数达到一定大小，比如1GB。当达到上限时，旧消息将过期并被删除。所以在任何时候，可用消息的总量都不会超过配置参数指定的大小。6.多个集群随着Kafka部署的增长，拥有多个集群通常是有益的。解决这个问题有几个原因：?数据类型分离?安全要求的隔离?多个数据中心（灾难恢复）特别是在处理多个数据中心时，通常需要在它们之间复制消息。这样，在线应用程序就可以访问两个站点上的用户活动。例如，如果用户更改其个人资料中的公共信息，则无论显示搜索结果的数据中心如何，都需要显示该更改。或者，可以从许多站点收集监控数据，并将其收集到分析和警报系统所在的单个中央位置。Kafka集群中的复制机制仅设计用于单个集群内，而不是多个集群之间。为此，Kafka项目包含一个名为MirrorMaker的工具。MirrorMaker的核心是Kafka消费者和生产者，它们通过队列链接在一??起。消息从一个Kafka集群中消耗并为另一个集群生成。使用MirrorMaker架构，来自两个本地集群的消息被聚合成一个聚合集群，然后被复制到其他数据中心。应用程序的简单性质掩盖了它创建复杂数据管道的能力。如果本文对您有帮助，欢迎关注点赞`，您的支持是我坚持创作的动力。转载请注明出处！
