分布式消息系统：Kafka（一）简介

亦凉 2022-05-14 03:16 250阅读 0赞

# 1、简介 #

kafka是用于构建实时数据管道和数据流的应用程序。具有实时**横向扩展、高吞吐量、支持大量堆积具有容错性和速度快**等特点。它是一个高性能分布式消息系统。通常一个分布式流数据平台它具有三个特点：

1.  发布和订阅功能，类似于消息系统
2.  以容错的方式记录流
3.  处理流

Kafka通常用于构建在系统或应用之间的实时数据流管道、构建实时流应用程序用于转换和响应数据流。

## 1.1 简介 ##

kafka对消息保存时根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成，**每个实例server成为broker**。无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。  
![这里写图片描述][70]  
主要特点：

1.  同时为发布和订阅提供高吞吐量。据了解，**Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）**。
2.  可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及复制防止数据丢失。
3.  分布式系统，易于向外扩展。所有的生产者和消费者都会有多个，均为分布式的。无需停机即可扩展机器。
4.  消息被处理的状态是在消费端维护，而不是由服务器端维护。当失败时能自动平衡。
5.  支持在线和离线的场景。

## 1.2 基本概念 ##

**主题（topic）**：就是消息的分类，生产者将消息发送到特定主题，消费者订阅该主题或者主题的分区来进行消费。

**消息**：就是数据，一个固定长度的消息头和一个可变长度的消息体组成。

**分区和副本**：一个主题可以分成多个分区，每个分区由一系列有序、不可变的消息组成，是一个有序队列。每个分区在物理上对应一个文件夹，分区的命名规则为主题名称后接“-”连接符，之后再接分区编号，分区编号从0开始，表示第一个分区。如下图主题3有2个分区，编号0、1；  
![这里写图片描述][70 1]  
　　每个分区中只有一个副本对外提供服务，可以看到上图的Leader标示的那样。我们通过zookeeper查看，如下图：  
![这里写图片描述][70 2]  
字段的含义：

<table> 
 <thead> 
  <tr> 
   <th>Name</th> 
   <th align="center">Academy</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>controller_epoch</td> 
   <td align="center">用于记录控制器发送变更次数。每一个代理实例化的时候都会启动一个KafkaController，并将代理的brokerId注册到zookeeper上，控制器主要负责主题的创建、删除、分区和副本的变化以及代理的故障转移。该值初始值为0，每变化一次增加1，客户端向控制器发送请求要带上这个值，如果小于该值表示请求时过期的，如果大于则说明以及有了新的控制器，这个值是为了保证机器控制器的唯一性。</td> 
  </tr> 
  <tr> 
   <td>leader</td> 
   <td align="center">该主题的这个分区的当前Leader是谁，这里记录的是brokerId，也就是代理的ID。</td> 
  </tr> 
  <tr> 
   <td>version</td> 
   <td align="center">版本</td> 
  </tr> 
  <tr> 
   <td>leader_epoch</td> 
   <td align="center">分区Leader更新次数，这个是相对分区而言。</td> 
  </tr> 
  <tr> 
   <td>isr</td> 
   <td align="center">表示该分区有几个副本，这里显示一个列表，列表元素个数表示副本个数，元素值表示它的副本分布在哪些brokerId的代理上</td> 
  </tr> 
 </tbody> 
</table>

**Leader副本和Follower副本**：同一个分区的多个副本目的就是为了冗余提高可用性，所以就必须保证副本的一致性，那么Kafka会选择分区内的一个副本作为Leader副本，而其他副本作为Follower副本，只有Leader副本处理读写请求。Follower副本只是从Leader上复制数据。

**偏移量**：发布到分区的消息会追加到日志文件的尾部，每条消息在日志文件中的位置都会对应一个按序递增的偏移量。不过偏移量不表示消息在磁盘上的位置，而且kafka几乎不允许对消息进行随机读写，消费者可以指定偏移量的的起始位置进行消费。

**日志段**：日志又被划分为多个日志段，日志段是kafka日志对象分片的最小单位。与日志对象一样，日志段也是逻辑概念。一个日志段对应磁盘上一个具体日志文件和两个索引文件，日志以.log结尾，两个索引以.index和.timeindex结尾，表示消息偏移量索引文件和消息时间戳索引文件。

**代理**：其实就是Kafka服务，一个Kafka服务叫做一个实例，也就是一个代理。一个集群通常包含多台代理，每个代理有一个非负整数的id，且在整个集群中id值是唯一的。

**生产者**：也就是发送消息的客户端

**消费者和消费者组**：消费者通过拉的方式获取数据，每一个消费者都属于一个消费者组，我们可以为每个消费者指定一个组。如果不指定则属于默认消费者组test-consumer-group。同时每个消费者也有一个唯一id，如果没有指定则kafka会为其自动生成一个。同一个主题的消息只能被消费者组中的一个消费者消息，但不同消费者组中的消费者可以消费这条消息。

**ISR**：Kafka在Zookeeper中动态维护一个ISR，也就是保存同步的副本列表，该列表中保存的是与Leader副本保持消息同步的所有副本对应的代理节点id。如果一个Follower宕机或者其落后太多，则该Follower副本节点将从ISR列表中移除。

## 1.3 Topics/logs ##

一个Topic可以认为是一类消息，**每个topic将被分成多个partition(区),每个partition在存储层面是append log文件**。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（**偏移量**），offset为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。  
![这里写图片描述][70 3]  
![这里写图片描述][70 4]

## 1.４ 在kafka中为什么几乎不允许对消息进行“随机读写” ##

原因：每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字。kafka并没有提供其他额外的索引机制来存储offset。  
　　kafka和JMS（Java Message Service）实现(activeMQ)不同的是:即使消息被消费,消息仍然不会被立即删除。日志文件将会根据broker中的配置要求,保留一定的时间之后删除;比如log文件保留2天,那么两天后,文件会被清除,无论其中的消息是否被消费.kafka通过这种简单的手段,来释放磁盘空间,以及减少消息消费之后对文件内容改动的磁盘IO开支.  
　　对于consumer而言,它需要保存消费消息的offset,对于offset的保存和使用,有consumer来控制;当consumer正常消费消息时,offset将会”线性”的向前驱动,即消息将依次顺序被消费.事实上consumer可以使用任意顺序消费消息,它只需要将offset重置为任意值。  
　　partitions的设计目的有多个.**最根本原因是kafka基于文件存储**.通过分区,可以将日志内容分散到多个server上,来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存;可以将一个topic切分多任意多个partitions,来消息保存/消费的效率.此外越多的partitions意味着可以容纳更多的consumer,有效提升并发消费的能力.

## 1.５ Distribution ##

一个Topic的多个partitions,被分布在kafka集群中的多个server上;每个server(kafka实例)负责partitions中消息的读写操作;此外kafka还可以配置partitions需要备份的个数(replicas),**每个partition将会被备份到多台机器上**,以提高可用性.  
　　基于replicated方案,那么就意味着需要对多个备份进行调度;每个partition都有一个server为”leader”;leader负责所有的读写操作,如果leader失效,那么将会有其他follower来接管(成为新的leader);follower只是单调的和leader跟进,同步消息即可..由此可见作为leader的server承载了全部的请求压力,因此从集群的整体考虑,有多少个partitions就意味着有多少个”leader”,kafka会将”leader”均衡的分散在每个实例上,来确保整体的性能稳定.

**Producers**  
　　Producer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition;比如基于”round-robin”方式或者通过其他的一些算法等.

**Consumers**  
　　本质上kafka只支持Topic.每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer.发送到Topic的消息,只会被订阅此Topic的每个group中的一个consumer消费.  
　　如果所有的consumer都具有相同的group,这种情况和queue模式很像;消息将会在consumers之间负载均衡.  
　　如果所有的consumer都具有不同的group,那这就是”发布-订阅”;消息将会广播给所有的消费者.  
　　在kafka中,一个partition中的消息只会被group中的一个consumer消费;每个group中consumer消息消费互相独立;我们可以认为一个group是一个”订阅”者,一个Topic中的每个partions,只会被一个”订阅者”中的一个consumer消费,不过一个consumer可以消费多个partitions中的消息.kafka只能保证一个partition中的消息被某个consumer消费时,消息是顺序的.事实上,从Topic角度来说,消息仍不是有序的.  
　　kafka的设计原理决定,对于一个topic,同一个group中不能有多于partitions个数的consumer同时消费,否则将意味着某些consumer将无法得到消息.

**Guarantees**

1) 发送到partitions中的消息将会按照它接收的顺序追加到日志中

2) 对于消费者而言,它们消费消息的顺序和日志中消息顺序一致.

3) 如果Topic的”replicationfactor”为N,那么允许N-1个kafka实例失效.

参考文章：  
[分布式消息系统：Kafka][Kafka]  
[学会使用Kafka（一）Kafka是什么以及基本概念][Kafka_Kafka]

[70]: /images/20220514/da289c37e2ae40eabc3a08d508a50ea9.png
[70 1]: /images/20220514/af207a92fba146c5a57f6c4e85c85f66.png
[70 2]: /images/20220514/11e9e89e0d5c4875b4003904c9ff9fe9.png
[70 3]: /images/20220514/33c60db95e194190a16eacec900e81e4.png
[70 4]: /images/20220514/ac367280075d4cabbca435149ef65624.png
[Kafka]: http://blog.jobbole.com/75328/
[Kafka_Kafka]: https://www.cnblogs.com/yunxizhujing/articles/9460302.html