kafka基础知识梳理

Kafka基础知识

背景

在大数据中，使用了大量的数据。 关于大数据，主要有两个主要挑战。第一个挑战是如何收集大量数据，第二个挑战是分析收集的数据。 为了克服这些挑战，需要使用消息传递系统。

Kafka专为分布式高吞吐量系统而设计。 Kafka倾向于非常好地取代传统的信息中间服务者。 与其他消息传递系统相比，Kafka具有更好的吞吐量，内置分区，复制和固有容错功能，因此非常适合大型消息处理应用程序。

什么是消息系统？

消息系统负责将数据从一个应用程序传输到另一个应用程序，因此应用程序可以专注于数据，但不必担心如何共享数据。 分布式消息传递基于可靠消息队列的概念。 消息在客户端应用程序和消息传递系统之间异步排队。 有两种类型的消息传递模式可用：一种是点对点的，另一种是发布 - 订阅(pub-sub)消息传递系统。 大多数消息传递模式遵循pub-sub。

点对点消息系统

在点对点系统中，消息被保存在一个队列中。 一个或多个消费者可以消费队列中的消息，但是特定的消息只能由最多一个消费者消费。 一旦消费者在队列中读取消息，消息就从该队列中消失。 这个系统的典型例子是一个订单处理系统，其中每个订单将由一个订单处理器处理，但是多订单处理器也可以同时工作。 下图描述了结构。

发布-订阅消息系统

在发布-订阅系统中，消息被保存在一个主题中。 与点对点系统不同，消费者可以订阅一个或多个主题并使用该主题中的所有消息。 在发布-订阅系统中，消息生产者称为发布者，消息消费者称为订阅者。 一个真实的例子是Dish TV，它发布体育，电影，音乐等不同的频道，任何人都可以订阅他们自己的一套频道，并在他们的订阅频道可用时获得内容。

kafka简介

Apache Kafka是一个分布式的发布 - 订阅消息传递系统和一个强大的队列，可以处理大量的数据，并使您能够将消息从一个端点传递到另一个端点。 Kafka适合离线和在线消息消费。 Kafka消息被保存在磁盘上并在集群内复制以防止数据丢失。 Kafka建立在ZooKeeper同步服务之上。 它与Apache Storm和Spark完美集成，用于实时流数据分析。

优点：

• 可靠性：kafka是分布式，分区，复制和容错。

• 可扩展性：Kafka消息系统无需停机即可轻松扩展。

• 耐用性：Kafka使用分布式提交日志，这意味着消息尽可能快地保留在磁盘上，因此它是持久的。

• 性能 ：Kafka对于发布和订阅消息都有很高的吞吐量。它保持稳定的性能，即使存储了许多TB数据量(级)的消息。

主要功能

根据官网的介绍，ApacheKafka®是一个分布式流媒体平台，它主要有3种功能：

• 发布和订阅消息流，这个功能类似于消息队列，这也是kafka归类为消息队列框架的原因。

• 以容错的方式记录消息流，kafka以文件的方式来存储消息流。

• 可以在消息发布的时候进行处理。

使用场景

• 构建实时的流数据管道，可靠地获取系统和应用程序之间的数据。

• 构建实时的流数据处理程序，对数据流进行变换或处理。

名词解释

在上图中，主题(topic)被配置为三个分区。 分区1(Partition 1)具有两个偏移因子0和1。分区2(Partition 2)具有四个偏移因子0,1,2和3，分区3(Partition 3)具有一个偏移因子0。replica的id与托管它的服务器的id相同。

假设，如果该主题的复制因子设置为3，则Kafka将为每个分区创建3个相同的副本，并将它们放入群集中以使其可用于其所有操作。 为了平衡集群中的负载，每个代理存储一个或多个这些分区。 多个生产者和消费者可以同时发布和检索消息。

• Topics ：消息以topic为类别记录，Kafka将消息种子(Feed)分门别类，每一类的消息称之为一个主题(Topic)，数据存储在主题中。主题分为多个分区。 对于每个主题，Kafka都保留一个分区的最小范围。 每个这样的分区都以不可变的有序顺序包含消息。 分区被实现为一组相同大小的段文件。

• Partition ：主题可能有很多分区，所以它可以处理任意数量的数据。

• Partition offset ： 每个分区消息都有一个称为偏移量的唯一序列标识。

• Replicas of partition：副本只是分区的备份。 副本从不读取或写入数据。 它们用于防止数据丢失。

• Brokers：以集群的方式运行，可以由一个或多个服务组成，每个服务叫做一个Broker；消费者可以订阅一个或多个主题(topic)，并从Broker拉数据，从而消费这些已发布的消息。每个消息（也叫作record记录，也被称为消息）是由一个key，一个value和时间戳构成。

  • 经纪人(Brokers)是简单的系统，负责维护公布的数据。 每个代理可能每个主题有零个或多个分区。 假设，如果一个主题和N个代理中有N个分区，则每个代理将有一个分区。

  • 假设某个主题中有N个分区并且N个代理(n + m)多于N个，则第一个N代理将拥有一个分区，下一个M代理将不会拥有该特定主题的任何分区。

  • 假设某个主题中有N个分区且N个代理(n-m)少于N个代理，则每个代理将拥有一个或多个分区共享。 由于经纪人之间的负载分配不均衡，不推荐这种情况。

• Kafka Cluster ：Kafka拥有多个经纪人称为Kafka集群。 Kafka集群可以在无需停机的情况下进行扩展。 这些集群用于管理消息数据的持久性和复制。

• Producers：生产者(Producer)是一个或多个Kafka主题的发布者。 生产者向Kafka经纪人发送数据。 每当生产者向经纪人发布消息时，经纪人只需将消息附加到最后一个段文件。 实际上，该消息将被附加到分区。 生产者也可以将消息发送到他们选择的分区。

• Consumers ：消费者从经纪人那里读取数据。 消费者通过从经纪人处获取数据来订阅一个或多个主题并消费发布的消息。

• Leader：Leader是负责所有分区读写的节点。 每个分区都有一台服务器充当领导者。

• Follower：遵循领导者(Leader)指示的节点称为追随者(Follower)。 如果领导失败，其中一个追随者将自动成为新领导。 追随者扮演正常的消费者角色，拉动消息并更新自己的数据存储。

核心API介绍

• 应用程序使用producer API发布消息到1个或多个topic中。

• 应用程序使用consumer API来订阅一个或多个topic，并处理产生的消息。

• 应用程序使用streams API充当一个流处理器，从1个或多个topic消费输入流，并产生一个输出流到1个或多个topic，有效地将输入流转换到输出流。

• connector API允许构建或运行可重复使用的生产者或消费者，将topic链接到现有的应用程序或数据系统。

kafka基本原理

通常来讲，消息模型可以分为两种：队列和发布-订阅式。队列的处理方式是一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。在发布-订阅模型中，消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。Kafka为这两种模型提供了单一的消费者抽象模型： 消费者组(consumer group)。消费者用一个消费者组名标记自己。

一个发布在Topic上消息被分发给此消费者组中的一个消费者。假如所有的消费者都在一个组中，那么这就变成了队列模型。假如所有的消费者都在不同的组中，那就完全变成了发布-订阅模型。更通用的， 我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者，一个组内多个消费者可以用来扩展性能和容错。

并且，kafka能够保证生产者发送到一个特定的Topic的分区上，消息将会按照它们发送的顺序依次加入，也就是说，如果一个消息M1和M2使用相同的producer发送，M1先发送，那么M1将比M2的offset低，并且优先的出现在日志中。消费者收到的消息也是此顺序。如果一个Topic配置了复制因子（replication facto）为N，那么可以允许N-1服务器宕机而不丢失任何已经提交（committed）的消息。此特性说明kafka有比传统的消息系统更强的顺序保证。但是，相同的消费者组中不能有比分区更多的消费者，否则多出的消费者一直处于空等待，不会收到消息。

kafka基本机制

消息传输流程

Producer即生产者，向Kafka集群发送消息，在发送消息之前，会对消息进行分类，即Topic，上图展示了两个producer发送了分类为topic1的消息，另外一个发送了topic2的消息。

Topic即主题，通过对消息指定主题可以将消息分类，消费者可以只关注自己需要的Topic中的消息。

Consumer即消费者，消费者通过与kafka集群建立长连接的方式，不断地从集群中拉取消息，然后可以对这些消息进行处理。

从上图中就可以看出同一个Topic下的消费者和生产者的数量并不是对应的。

kafka服务器消息存储策略

谈到kafka的存储，就不得不提到分区，即partitions，创建一个topic时，同时可以指定分区数目，分区数越多，其吞吐量也越大，但是需要的资源也越多，同时也会导致更高的不可用性，kafka在接收到生产者发送的消息之后，会根据均衡策略将消息存储到不同的分区中。

在每个分区中，消息以顺序存储，最晚接收的的消息会最后被消费。

与生产者的交互

生产者在向kafka集群发送消息的时候，可以通过指定分区来发送到指定的分区中。也可以通过指定均衡策略来将消息发送到不同的分区中，如果不指定，就会采用默认的随机均衡策略，将消息随机的存储到不同的分区中。

与消费者的交互

在消费者消费消息时，kafka使用offset来记录当前消费的位置

　　在kafka的设计中，可以有多个不同的group来同时消费同一个topic下的消息，如图，我们有两个不同的group同时消费，他们的的消费的记录位置offset各不相同，不互相干扰。

　　对于一个group而言，消费者的数量不应该大于分区的数量，因为在一个group中，每个分区至多只能绑定一个消费者，即一个消费者可以消费多个分区，一个分区只能给一个消费者消费。消费者和分区是1：n的关系。

　　因此，若一个group中的消费者数量大于分区数量的话，多余的消费者将不会收到任何消息。

kafka集群体系结构

下表描述了上图中显示的每个组件。

• Broker：Kafka集群通常由多个代理组成，以保持负载平衡。 Kafka经纪人是无状态的，所以他们使用ZooKeeper维护他们的集群状态。 一个Kafka代理实例可以处理每秒数十万次的读写操作，每个Broker都可以处理TB消息，而不会影响性能。 Kafka经纪人的领导人选举可以由ZooKeeper完成。

• ZooKeeper： ZooKeeper用于管理和协调Kafka经纪人。 ZooKeeper服务主要用于通知生产者和消费者关于Kafka系统中任何新经纪人的存在或Kafka系统中经纪人的失败。 根据Zookeeper收到的有关经纪人存在或失败的通知，生产者和消费者就会做出决定，并开始与其他经纪人协调他们的任务。

• Producers：生产者将数据推送给经纪人。 新代理启动后，所有生产者都会搜索它并自动向该新代理发送消息。 Kafka生产者不会等待经纪人的确认，并且可以像经纪人能够处理的那样快地发送消息。

• Consumers：由于Kafka代理是无状态的，这意味着消费者必须通过使用分区偏移量来维护消耗了多少消息。 如果消费者确认特定的消息偏移量，则意味着消费者已经消费了所有先前的消息。 消费者向代理发出一个异步拉取请求，以准备消耗字节缓冲区。 消费者可以简单地通过提供偏移值来倒回或跳到分区中的任何点。 消费者补偿值由ZooKeeper通知。

参考资料

• 易百教程Kafka简介：https://www.yiibai.com/kafka/apache_kafka_introduction.html

• kafka实战：https://www.cnblogs.com/hei12138/p/7805475.html

• kafka 基础知识梳理：https://www.cnblogs.com/yangxiaoyi/p/7359236.html