作为快速入门Kafka系列的第三篇博客，本篇为大家带来的是Kafka架构之宏微观分析~
码字不易,先赞后看!
Kafka技术架构
宏观
宏观上，Kafka的架构包含四大部分
1、生产者API
允许应用程序发布记录流至一个或者多个kafka的主题（topics）。
2、消费者API
允许应用程序订阅一个或者多个主题，并处理这些主题接收到的记录流。
3、StreamsAPI
允许应用程序充当流处理器（stream processor），从一个或者多个主题获取输入流，并生产一个输出流到一个或 者多个主题，能够有效的变化输入流为输出流。
4、ConnectAPI
允许构建和运行可重用的生产者或者消费者，能够把kafka主题连接到现有的应用程序或数据系统。例如：一个连 接到关系数据库的连接器可能会获取每个表的变化。
微观
说明：kafka支持消息持久化，消费端为拉模型来拉取数据，消费状态和订阅关系有客户端负责维护，消息消费完 后，不会立即删除，会保留历史消息。因此支持多订阅时，消息只会存储一份就可以了。
内部细节
1）Producer：消息生产者，就是向 kafka broker 发消息的客户端；
2）Consumer ：消息消费者，向 kafka broker 取消息的客户端；
3）Consumer Group （CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4）Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个 topic。
5）Topic ：可以理解为一个队列，生产者和消费者面向的都是一个 topic；每条发布到kafka集群的消息都必须有一个类别（topic）
6）Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；
7）segment：一个partition当中存在多个segment文件段，每个segment分为两部分，.log文件和.index文件，其中.index文件是索引文件，主要用于快速查询.log文件当中数据的偏移量位置
8）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且kafka 仍然能够继续工作，且kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。
9）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。
10）follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower。
知识拓展：
1.一个broker只能有一个leader，一个broker可以只有一个Topic一个Partition
2.副本不负责数据的读取响应，消费者只能从Lead读取数据，Follwer只是为了提高容错性
3.消费者的并发度取决于分区数量
4.分区数据副本数量<=Broker的数量(不允许一个分区的数据副本放在同一个Broker)
好了，终于码完字了~本篇博客可谓是精华满满，对于刚学习Kafka的朋友可谓是十分良心了~如果你觉得对你有帮助，不妨带个点赞，点个关注，让更多的人受益٩(๑❛ᴗ❛๑)۶。
本篇博客的知识总结就到这里了，下一篇博客将为大家带来Kafka的命令行操作，敬请期待~
转载：https://blog.csdn.net/weixin_44318830/article/details/104959846