Kafka原理解析（一）-- Kafka主要流程概览

系列文章目录

第一章 Kafka原理解析（一）-- Kafka主要流程概览
第二章 Kafka原理解析（二）-- Kafka创建主题Topic流程解析

---

前言

Kafka是一个主流的大数据级别的分布式流式消息处理系统，其Cluster内部实现涉及的知识点繁多，每一个知识点都可以单独作为一个技术话题进行讨论和参考，本文只是将这些知识点整合到一起，用简单易懂的语言进行描述，重在概念、流程和机制，也便于统一查阅和备忘。

---

本章主要从概念术语中描述Kafka的总体运转流程，在后续章节再逐一详细描述细节流程和机制。

一、Kafka总体架构中的概念和流程

1. 概念

• Broker ： 相当于Kafka的服务端程序，负责接收客户端发送和拉取数据的请求，并将消息数据持久化到本地日志文件中。在Kafka中Broker只是一组无状态的程序，整个集群可以有很多Broker提供服务，支持扩展以及Failover故障转移。
• Zookeeper ：Kafka使用Zookeeper来进行集群协调，监督Broker的变化以及保存集群元数据。
• Producer ：在消息发送端负责与Broker沟通的程序，在客户端创建，接收客户端的消息发送请求，然后转化为内部协议数据发送到Broker。
• Log：Kafka消息的存储载体，是Broker所在服务器中存储的日志文件，当Broker接收到Producer发来的消息后马上存入相应的Log日志文件，做持久化处理，因此消息可以被多次读取和消费，Broker故障后也可以很快恢复处理。
• Consumer：在消息消费端负责与Broker沟通的程序，由客户端创建并不停调用poll来进行消息的读取，读取到的消息由客户端安排processor进行处理，然后客户端通过Consumer通知Broker已消费完成本消息。

2. 流程

总体流程：

1. 消息从客户端的Kafka Producer中发送到Kafka Broker中
2. Kafka Broker将其存储到Log日志文件后，等待Kafka Consumer来读取
3. Kafka Consumer在客户端中不断轮询poll来读取Broker中的新数据，并通知Broker已完成消费

以下进一步细化概念和流程

二、Kafka生产端的的概念和流程

1. 概念

• Topic主题 ： Kafka可以同时处理不同类型的消息，并以主题的形式进行管理，同一类型的消息发布到同一个主题中，消费端可以订阅和接收感兴趣的主题中的消息，忽略没有订阅的主题。
• Partition分区 ： 作为大数据级的消息处理系统，Kafka要保证高可扩展性以及高吞吐高性能，需要将一个Topic中的消息在物理上分成了多个Partition分区进行存储和处理，这样不同的Partition可以分布到不同的Broker中，Partition是消息处理的最小单元，既保证扩展性和高吞吐，同时还提供了负载均衡和高可用性。
• Message key 消息主键 ： 消息主键指一条消息中用户指定的主键，是这条消息的内容识别key（如应用系统中的用户id），指定消息key的意义在于Kafka可以根据该key来进行特定规则下的分区计算，然后将此消息分配到相应的分区Partition中，这样解决了Partition分区的均衡分配问题，同时保证了相同key的消息能保存到同一分区中，便于消费端统一计算处理。
• Replica副本 ：为了解决Partition分区的单点问题（在Broker宕机时上面的Partition将会失去可用性），Kafka提供了副本机制，每个分区在不同的Broker机器中生成多个副本，每条消息进入某个分区时，需要复制到所有的分区中，这样一旦主分区失效后，可以马上切换到另一个副本中，实现高可用性。
• Partition Leader分区领导者 ：每个Partition可以有多个Replica副本，但是总是有一个Leader领导者副本来对外提供服务，其他的副本只是负责同步备份数据，不提供服务。Partition Leader在创建主题时就已经定好（一般是副本集中的第一个副本作为 Leader），在Leader宕机后会触发重新选举新的Leader。
• Controller协调控制者：Controller是Broker的一种角色，由某一个Broker担任。它主要负责监控Brokers节点和Topic主题的变化，负责主题创建的操作，以及Broker宕机后的分区Leader重新选举等。若负责Controller的Broker宕机，则其他Broker会自动竞争成为Controller。
• Metadata元数据：Kafka中的元数据由Controller信息、Brokers信息、Topics信息、分区信息、分区中的副本集以及Header、ISR（及时同步好数据的副本）等信息。Kafka中所有流程参与者都必须时时保持最新的Metadata元数据，以便于在发送变化时采取相应的措施。

2. 流程

生产端的流程主要包括两个流程：创建主题流程 和 生产消息流程。

2.1 创建主题流程

 1. 用户通过脚本创建主题
 2. Controller接收到请求，验证主题合法性
 3. Controller为主题分配合理的分区和副本，并指定Leader，更新Zookeeper
 4. Controller监听到主题变化后，发送Metadata更新请求给Brokers
 5. Broker接收到更新请求，更新本地的Metadata缓存

2.2 生产消息流程

 1. Client调用Producer发送一个消息以及key
 2. Producer根据key进行分区计算，找到分区Leader所在的Broker，向Borker发送数据
 3. 分区Leader所在的Broker接收到消息请求后，存储到本地Log日志文件中
 4. 分区的其他Broker上的副本检查到有新的消息，马上开始同步数据，存入本地
 5. 当副本同步完成，Leader将此消息置为可消费状态，Consumer可以开始消费此消息。

以上两个流程中的细节会在接下来的章节中进一步细化，分为 创建主题、集群协调、元数据更新、生产消息、消息存储、分区副本等六个部分来详细描述。

三、Kafka消费端的的概念和流程

1. 概念

• Consumer消费者实例 ：Client中启动的Consumer程序，他可以创建在进程或线程中，不停循环调用poll从分区中读取消息，并处理读取到的消息。典型如spring-kafka, FlinkKafkaConsumer等。
• Consumer Group消费分组 ：消费者分组是一个逻辑概念，一个名称而已，Kafka规定消费者均需指定一个消费者分组来加入系统，一个消费者分组中可以有一个或多个Consumer实例。由于Consumer关注的主题可能不同，因此一个分组可能有多个主题，这些主题的相关分区会在组中的消费者实例中均匀分配，每个实例均领到不同的分区进行消费，一个实例可以领到多个分区进行消费，但是不会和其他实例同时消费同一分区（即一个分区只能被分组中的一个实例进行消费）。
• Group Coordinator分组协调者： 当第一个消费者实例指定一个消费者分组后，此消费者分组就形成了，但是消费者分组需要在Kafka中注册，同时以后增员或减员（其他实例加入分组或退出）都要向“组织汇报”，这个组织的管理者就是Group Coordinator分组协调者，他在每个Broker中都建有“办事处”，每个消费者分组都规定好属于某一个Broker中的Coordinator来管理（以后不会变）。
• Rebalance重平衡：Rebalance是消费者分组中有成员增减（包括第一个）时向Coordinator汇报时要走的一个流程，也是一个协议，通过这个过程，重新分配了组内的分区，大家都了解了自己要负责的分区，相当于开了一个由Coordinator组织、组长主导的一次共识性会议。（组长由 Coordinator指定，一般是第一个加入者）。
• Offset位移：Offset指某个消费者实例在某个分区中消费的最新一条消息的id。Kafka中每条新的消息都会按顺序生成一个整数id，此id就是消费者消费时的offset位移。Kafka保证在一个分区中的消息是严格有序排列的，消费到某个offset，表明此offset之前的消息都已经消费过了。

2. 流程

消费端的流程主要包括两个流程：建立消费分组流程 和 消息消费流程。

2.1 建立消费分组流程

 1. 第一个消费实例启动，并指定了一个消费者分组
 2. 消费实例通过计算知道Coordinator所在的位置，发送加入分组请求
 3. Coordinator接收到请求后将它选为组长，并安排Rebalance过程
 4. 完成Rebalance后该消费者分组正式成立，此时组长也可以开始消费数据了
 5. 若有新的消费者实例启动，也是指定同一个分组
 6. 新实例向Coordinator发送加入分组请求
 7. Coordinator接收到请求后发起Rebalance过程，此时分组暂停消费活动
 8. Coordinator在Rebalance过程中要求组长制定一个重新分配分区的策略
 9. 组长提交新的策略后，Coordinator通知所有的实例
 10.分组中的所有实例收到最新分区分配策略后，结束Rebalance，各自开始消费数据
  

2.2 消息消费流程

 1. Consumer实例连接上所负责的分区的Leader所在的Broker
 2. Consumer实例发送Fetch数据请求，并附上当前offset
 3. Broker接收到请求后将相应分区中的offset之后可以消费的消息发回
 4. Consumer实例收到数据后进行处理
 5. 当所有消息处理完成后，向Broker提交消息消费结果的offset（自动提交的流程除外）

以上两个流程中的细节会在接下来的章节中进一步细化，分为 建立消费分组和消息消费等两个部分来详细描述。

---

总结

本文总结了Kafka中所有重要的流程、角色、概念等，总体上对Kafka有了清晰的认识，接下来将是分环节进行细节描述。