kafka学习（一）：介绍、相关概念

不念不忘少年蓝@ 2023-09-26 10:34 161阅读 0赞

## 1、**Kafka介绍** ##

Kafka最初由Linkedin公司开发，是一个分布式的、⽀持分区的（partition）、多副本的（replica）、多订阅者，基于zookeeper协调的**分布式消息系统**（也可以当做MQ系统），也是一个**分布式流处理平台**（Distributed Streaming Platform）。常用于web/nginx日志、访问日志、消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

### 1.1、Kafka是一个分布式数据流平台，可以从如下几个层面来理解： ###

1.  我们可以向kafka发布数据以及从kafka订阅数据，即 我们可以将kafka看做一个消息队列，所起到的作用：缓冲（消峰限流），实现生产与消费的解耦。
2.  Kafka可以存储数据，并提供**容错机制**，即：数据丢失后可以进行恢复。
3.  当数据到达kafka之后，可以马上的被消费处理，即 kafka的**延迟很低**。
4.  **Kafka的数据，无论消费与否，数据会一直存在，不会删除**。

### 1.2、kafka版本命名 ###

![244c218fff6544e580d5e4f654c83201.png][]

**前面的版本号**：是编译 Kafka 源代码的 **Scala 编译器版本，示例中为：2.12**。

**真正的 Kafka 版本号，示例中为：** ：**2.5.0**

**那么这个 2.5.0 又表示什么呢？**  
前面的 2 表示**大版本号**，即 Major Version；  
中间的 5 表示小版本号或次版本号，即 Minor Version；  
最后的 1 表示修订版本号，也就是 Patch 号。

## 2、kafka的特性 ##

*  **高吞吐量、低延迟**：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒；
 *  **可扩展性**：kafka集群支持热扩展；
 *  **持久性、可靠性**：消息被持久化到本地磁盘，并且支持数据备份防止丢失；
 *  **容错性**：允许集群中的节点失败(若分区副本数量为n,则允许n-1个节点失败)；
 *  **高并发**：单机可支持数千个客户端同时读写；

## 3、kafka的相关概念 ##

![cf3a274e570d4d9f915bf8babb93a68b.png][]

### 3.1、Broker ：kafka节点 ###

一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

Kafka代理(broker)是无状态的，即代理并不知道消费者是否已经使用了该消息，当消息在代理中超过一定时间后，将会被自动删除。

集群中每个broker都有一个**唯一broker\_id**，不得重复。

### 3.2、**Producer：消息生产者** ###

向主题发布消息的客户端应用程序，称为生产者（Producer），生产者用于持续不断的向某个主题发送消息。

消息生产者，**数据的分发策略由producer决定**，默认是:

> **defaultPartition = Utils.abs(key.hashCode) % numPartitions**

生产者可以发布数据到指定的主题（topic）中，并可以指定在主题（topic）中哪些消息分配到哪些分区。

生产者直接把消息发送给对应分区的broker，而不需要任何路由层。

**批处理发送：**当message积累到一定数量或等待一定时间后进行发送。

### 3.3、**Consumer：消息消费者** ###

**消息传递**通常由两种模式，**queuing（队列）**和**publish-subscribe （发布-订阅）**

*  **queuing**：每个Consumer从消息队列中取走一个消息。
 *  **pub-scrib**：消息被广播到每个Consumer。

Kafka通过提供了一个对Consumer的抽象来同时实现这两种模式--**ConsumerGroup**。

Consumer实例需要给自己指定一个ConsumerGroup的名字，如果所有的实例都用同一个ConsumerGroup名字，那么这些Consumer就会以queuing的模式工作；如果所有的实例分别用的不同的ConsumerGroup名字，那么它们就以public-subscribe模式工作。

如下图所示：两台server的集群一共有p0~p3四个Partition，两个Consumer Group，在Group内部是以queuing的模式消费Partition，在Group之间是以pub-scrib模式消费。

![b7eefe4eb78048fc93dab49d22c873b0.png][]

**消息顺序性：**

Kafka是如何确保消息消费的顺序性的呢？消息在一个Partition中的顺序是有序的，但是Kafka只保证消息在一个Partition中有序，如果要想使整个topic中的消息有序，那么一个topic仅设置一个Partition即可。

### 3.4、**Consumer Group：消费者组** ###

*  Consumer Group可以有多个，每个Consumer Group消费的数据都是一样的。可以把多个consumer划分为一个组，组里面所有成员共同消费一个topic的数据，组员之间不能重复消费。
 *  ### **3.5、Topic ：主题** ###
    
     *  通过对消息指定主题（topic）可以将消息分类，消费者可以只关注自己需要的Topic中的消息。
        
        这是一个逻辑上的概念，落到磁盘上是一个partition的目录。partition的目录中有多个segment组合(index,log)。一个**Topic**对应多个partition\[0,1,2,3…\]，一个**partition**对应多个**segment**组合。一个segment有默认的大小是**1G**。
     *  每个partition可以设置多个副本(replication-factor 1), 会从所有的副本中选取一个leader出来。所有读写操作都是通过leader来进行的。特别强调，**在kafka中读写操作都是leader**。无论发布的消息是否被消费，kafka都会持久化一定时间（可配置，默认7天），每个消费者都会持久化offset到日志中，且offset的位置由消费者控制。
     *  ### **3.6、Partition：分区** ###
        
         *  在topic基础上做了进一步区分，
            
             *   为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition（partition是一个磁盘目录），每个partition是一个FIFO的队列。partition中的每条消息都会被分配一个有序的id（offset）。**kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。**
                
                 *  ### **3.7、offset ：**偏移量 ###
                 *   kafka为每条在分区的消息保存一个偏移量offset，这也是消费者在分区的位置。比如一个偏移量是5的消费者，表示已经消费了从0-4偏移量的消息，下一个要消费的消息的偏移量是5。
                    
                     kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想找位于2049的位置，只要找到2048.kafka的文件即可。当然the first offset就是00000000000.kafka

![48d80eaa52ab42d0ae0b92902a0e7b0f.png][]

上图所示，从分区中消费数据，kafka底层有一个offset机制。Kafka会记录消费者的offset（消费的位置偏移量），便于下一次从正确的位置进行消费。

>  *  Kafka 0.9 版本之前，consumer 默认将 offset 保存在 Zookeeper 中。**存在的问题**：会频繁的和zookeeper进行通信交互，即可能为zookeeper带来较高的访问负载。
>  *  **从 0.9 版本开始，consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为\_\_consumer\_offsets**

**Offset验证思路：**

> 1.  启动一个消费者线程（需要带有消费者组 属性）
> 
>     sh kafka-console-consumer.sh --bootstrap-server localhost:90923 --topic book --from-beginning --group 20220707
> 
> 1.  会发现多出了一些目录，是因为 **kafka底层是通过一个主题来进行管理offset的，主题名为**：**\_\_consumer\_offsets** ,该主题有**50个分区**。
> 2.  某个消费者组的offset就存在这50个分区目录中的其中一个。

**存储规则：**

> **Math.abs(groupId.hashCode())%50** **该结果在：0~49之间**
> 
> 说明：Math.abs()返回指定数字的绝对值。

*  ## 4、**Topic & Partition** ##
    
     *  Topic相当于传统消息系统MQ中的一个队列queue，**producer端发送的message必须指定是发送到哪个topic，但是****不需要指定topic下的哪个partition**，因为kafka会把收到的message进行load balance，均匀的分布在这个topic下的不同的**partition上****（hash(message) % \[broker数量\]** ）。
        
         *  物理存储上，这个topic会分成一个或多个partition，每个partiton相当于是一个子queue。在物理结构上，每个partition对应一个物理的目录（文件夹），文件夹命名是**\[topicname\]\_\[partition\]\_\[序号\]**，一个topic可以有无数多的partition，根据业务需求和数据量来设置。在kafka配置文件中可随时更改num。partitions参数来配置更改topic的partition数量，在 创建Topic时通过参数指定parittion数量。 Topic创建之后通过Kafka提供的工具也可以修改partiton数量。
            
            一般来说，
            
             *  （1）一个Topic的Partition数量大于等于Broker的数量， 可以提高吞吐率。
                
                 *  （2）同一个Partition的Replica尽量分散到不同的机器， 高可用。
                    
                    当add a new partition的时候，partition里面的message不会重新进行分配，原来的partition里面的message数据不会变，新加的这个partition刚开始是空的，随后进入这个topic的message就会重新参与所有partition的load balance
                    
                     **Partition Replica**：每个partition可以在其他的kafka broker节点上存副本，以便某个kafka broker节点宕机不会影响这个kafka集群。存replica副本的方式是按照kafka broker的顺序存。
                    
                     *  例如有5个kafka broker节点，某个topic有3个partition，每个partition存2个副本，那么partition1存broker1,broker2，partition2存broker2,broker3。。。以此类推（replica副本数目不能大于kafka broker节点的数目，否则报错。**这里的replica数其实就是partition的副本总数，其中包括一个leader，其他的就是copy副本）**。这样如果某个broker宕机，其实整个kafka内数据依然是完整的。但是，replica副本数越高，系统虽然越稳定，但是回来带资源和性能上的下降；replica副本少的话，也会造成系统丢数据的风险。
                        
                         *  ![3280ee0200c6425181f91c1795738e58.png][]
                            
                            如上图所示，向一个主题生产数据，数据最终是存储到各个分区中。
                            
                            分区从逻辑上来看，实际上是一个队列。
                            
                            分区从物理上来看，实际上是一个分区目录。
                            
                            向分区中存储数据，最终是存到分区目录下的log文件中。
                         *  ![deb9c3417ea641fa98f7b2186cff844f.png][]
                            
                            底层**实际上是****数据磁盘的顺序写操作**。（即：**往文件末尾追加**。）所以kafka的写入性能较高。
                            
                            ## 5、**kafka的应用场景** ##
                            
                             **日志收集**：一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口开放给各种消费端，例如hadoop、Hbase、Solr等。
                            
                             **消息系统**：解耦生产者和消费者、缓存消息等。
                            
                             **用户活动跟踪**：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索记录、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
                            
                             **运营指标**：Kafka也经常用来记录运营监控数据。
                            
                             **流式处理。**
                            
                            ## 6、知识点 ##
                         *  ### 6.1、**controller** : **控制进程** ###
                            
                             *  kafka集群中，**controller控制进程**会随机在某台broker上启动，此进程用于leader的选举，以及失败恢复。**Controller进程的信息由zookeeper来维护**，如果controller宕机后，会在其他剩下的broker服务器上启动。
                         *  ### 6.2、zookeeper ###

**Zookeeper** ：负责管理、监控kafka集群运行（临时节点+监听机制），包括存储一些元数据信息（比如：主题名、主题的分区数、分区的副本数、副本leader的位置信息、controller位置等）

*  **示例说明：**
    
    ①进入zookeeper客户端：进入bin目录，执行sh zkCli.sh，进入zookerper客户端，查看kafka节点信息。
 *  ![19bb777d8c7945229ef51529aa782eb6.png][]
    
    ### 6.3、分区的副本机制 ###
    
     *  kafka支持数据的容错机制，即分区数据丢失后，可以恢复，通过副本冗余机制来实现，即我们在创建主题时，可以指定每个分区有多个副本。

分区的副本机制，是为了数据容错。

**补充说明：**

> 1.  分区副本的数量不能超过broker服务器数量。
> 2.  分区的副本数不宜过多，副本数量越多，集群磁盘的利用率越低，比如：3个副本，集群磁盘的利用率只有33%。
> 3.  在实际生产环境下，一般3个副本足够了，2个副本也可以。如果副本数是1，则没有容错机制。

综上，kafka最基础、最核心的概念就是topic主题。因为无论是向kafka生产数据，还是从kafka消费数据，都需要指定主题。

主题topic的属性：

*  主题名 topic
 *  分区数量 partition
 *  分区的副本数量 replication

### 6.4、分区副本知识点 ###

![6b14ceea73be481bab818328b06a5109.png][]

> 1.  kafka是有leader和follower概念的。注意：是针对分区的副本而言的，不是针对broker来说的。
> 2.  分区的副本leader的作用：无论是生产数据，还是消费数据，都是和分区副本的leader交互的。
> 3.  如果分区副本的leader挂掉了，kafka会从剩余的follower中选出新的leader。

[244c218fff6544e580d5e4f654c83201.png]: https://img-blog.csdnimg.cn/244c218fff6544e580d5e4f654c83201.png
[cf3a274e570d4d9f915bf8babb93a68b.png]: https://img-blog.csdnimg.cn/cf3a274e570d4d9f915bf8babb93a68b.png
[b7eefe4eb78048fc93dab49d22c873b0.png]: https://img-blog.csdnimg.cn/b7eefe4eb78048fc93dab49d22c873b0.png
[48d80eaa52ab42d0ae0b92902a0e7b0f.png]: https://img-blog.csdnimg.cn/48d80eaa52ab42d0ae0b92902a0e7b0f.png
[3280ee0200c6425181f91c1795738e58.png]: https://img-blog.csdnimg.cn/3280ee0200c6425181f91c1795738e58.png
[deb9c3417ea641fa98f7b2186cff844f.png]: https://img-blog.csdnimg.cn/deb9c3417ea641fa98f7b2186cff844f.png
[19bb777d8c7945229ef51529aa782eb6.png]: https://img-blog.csdnimg.cn/19bb777d8c7945229ef51529aa782eb6.png
[6b14ceea73be481bab818328b06a5109.png]: https://img-blog.csdnimg.cn/6b14ceea73be481bab818328b06a5109.png