读书笔记：Kafka源码解析与实战——Kafka的架构

清疚 2022-11-19 07:49 214阅读 0赞

## Kafka的架构 ##

Kafka集群由若干个Broker组成，Topic由若干个Partition组成，每个Partition里面的消息通过Offset来获取。

*  一台Kafka服务器就是一个Broker，一个集群由多个Broker组成，一个Broker可以容纳多个Topic，**Broker和Broker之间没有Master和Standby的概念**，它们之间的地位基本是平等的。
 *  每条发送到Kafka集群的消息都属于某个主题，这个主题就称为Topic。**物理上不同Topic的消息分开存储**，逻辑上一个Topic的消息虽然保存在一个或多个Broker上，但是用户只需指定消息的主题Topic即可生产或消费数据而不需要去关心数据存放在何处。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]
 *  为了实现可扩展性，一个非常大的Topic可以被分为多个Partition，从而分布到多台Broker上。Partition中的每条消息都会被分配一个自增Id(offset)。**Kafka只保证按一个Partition种的顺序将消息发送给消费者，但是不保证单个Topic中的多个Partition之间的顺序**。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]
 *  Topic的Partition含有N个Replica，N为副本因子。**其中一个Replica为Leader，其他都为Follower，Leader处理Partition的所有读写请求，与此同时，Follower会定期地去同步Leader上的数据**。
 *  消息在Topic的Partition中的位置，**同一个Partition中的消息随着消息的写入，其对应的Offset也自增**。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 2]

*  消息，是通信的基本单位。每个Producer可以向一个Topic发布一些消息
 *  消息生产者，即将消息发布到指定的Topic中，同时Producer也能决定此消息所属的Partition：比如基于Round-Robin方式或Hash方式等一些算法
 *  消息消费者，即向指定的Topic获取消息，根据指定Topic的分区索引及其对应分区上的消息偏移量来获取消息  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 3]
 *  消费者组，每个Consumer属于一个Consumer Group；反过来，每个Consumer Group中可以包含多个Consumer。**如果所有的Consumer都具有相同的Consumer Group，那么消息将会在Consumer之间进行负载均衡**。也就是说一个Partition中的消息只会被相同Consumer Group中的某个Consumer消费，每个Consumer Group消息消费是相互独立的。如果所有的Consumer都具有不同的Consumer Group，则消息将会广播给所有的Consumer。
 *  Zookeeper存放Kafka集群相关元数据的组件。在Zookeeper集群中会保存Topic的状态信息，例如分区的个数、分区的组成、分区的分布情况等；保存Broker的状态信息；保存消费者的消费信息等。通过这些信息，Kafka很好地将消息生产、消息存储、消息消费的过程结合起来。

Producer使用Push模式将消息发布到Broker上，Consumer使用Pull模式从Broker上订阅并消费消息。**Producer根据指定路由方法（Round-Robin、Hash等），将消息Push到Topic的某个Partition里**。Kafka集群收到Producer发过来的消息后，将其持久化到硬盘，并保留消息指定时长，而不关注消息是否被消费。Consuber从Kafka集群Pull数据，并控制获取消息的Offset。

## Kafka内部通信协议 ##

区分Replica Leader和Broker Leader  
Topic的Partition含有N个Replica，N为副本因子。**其中一个Replica为Leader，其他都为Follower，Leader处理Partition的所有读写请求，与此同时，Follower会定期地去同步Leader上的数据**。Partition就像一个一个磁盘，而Topic就像将Partition磁盘做了RAID 0一样，这些磁盘存储Topic不同部分的数据，而Replica就是类似磁盘上的数据在其他磁盘有备份一样，也就是磁盘交错备份数据，有原始数据的那个磁盘的数据就是Leader。  
kafka内部各个Broker之间的角色并不是完全相等的，Broker内部负责管理分区和副本状态以及异常情况下分区的重新分配等这些功能的模块称为KafkaController。**每个Kafka集群中有且只有1个Leader状态的KafkaController**，相当于集群只有一个master主机。当Leader状态的KafkaController出现异常时，其余的Standby状态下的KafkaController会通过Zookeeper选举出又一个Leader状态的KafkaController。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]: /images/20221119/74c7d350f2fd48a6950c1cfe166b0a52.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]: /images/20221119/5d35c1d1b60148e4bb4110103dc30624.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 2]: /images/20221119/9fceeb96733a48b1ab5f7c0fdc1c60b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 3]: /images/20221119/23dd7e834b66470ca80d4a353a0747ae.png