深入了解Kafka的概述与基础架构
1、概述
Kafka是一个分布式的、基于发布订阅的消息系统,主要解决应用解耦、异步消息、流量削峰等问题。
2、发布订阅模型
消息生产者将消息发布到Topic中,同时有多个消息消费者订阅该消息,消费者消费数据之后,并不会清除消息。属于一对多的模式,如图:
发布订阅模型.png
3、系统架构
网上找了个不错的架构图:
系统总架构.png
上图中标识了一个kafka体系架构包括若干Producer、Broker、Consumer和一个zookeeper集群。
再贴两张带有Topic和Partition的架构图:
系统总架构-详细-1.png
系统总架构-详细-2.jpg
下面介绍一下各个角色:
3.1、Producer
消息生产者,将消息push到Kafka集群中的Broker。
3.2、Consumer
消息消费者,从Kafka集群中pull消息,消费消息。
3.3、Consumer Group
消费者组,由一到多个Consumer组成,每个Consumer都属于一个Consumer Group。消费者组在逻辑上是一个订阅者。
消费者组内每个消费者负责消费不同分区的数据,一个分区只能由一个组内消费者消费;消费者组之间互不影响。
即每条消息只能被Consumer Group中的一个Consumer消费;但是可以被多个Consumer Group组消费。这样就实现了单播和多播。
3.4、Broker
一台Kafka服务器就是一个Broker,一个集群由多个Broker组成,每个Broker可以容纳多个Topic.
3.5、Topic
消息的类别或者主题,逻辑上可以理解为队列。Producer只关注push消息到哪个Topic,Consumer只关注订阅了哪个Topic。
3.6、Partition
负载均衡与扩展性考虑,一个Topic可以分为多个Partition,物理存储在Kafka集群中的多个Broker上。可靠性上考虑,每个Partition都会有备份Replica。
3.7、Replica
Partition的副本,为了保证集群中的某个节点发生故障时,该节点上的Partition数据不会丢失,且Kafka仍能继续工作,所以Kafka提供了副本机制,一个Topic的每个Partition都有若干个副本,一个Leader和若干个Follower。
3.8、Leader
Replica的主角色,Producer与Consumer只跟Leader交互。
3.9、Follower
Replica的从角色,实时从Leader中同步数据,保持和Leader数据的同步。Leader发生故障时,某个Follower会变成新的Leader。
3.9、Controller
Kafka集群中的其中一台服务器,用来进行Leader election以及各种Failover(故障转移)。
3.9、ZooKeeper
Kafka通过Zookeeper存储集群的meta等信息。
4、Topic和Partition
一个Topic可以认为是一类信息,逻辑上的队列,每条消息都要指定Topic。为了使得Kafka的吞吐量可以线性提高,物理上将欢迎进入大数据学习扣群522189307,一起学习交流,Topic分成一个或多个Partition。每个Partition在存储层面时append log文件,消息push进来后,会被追加到log文件的尾部,每条消息在文件中的位置成为offset(偏移量),offset是一个long型数字,唯一的标识一条信息。因为每条消息都追加到Partition的尾部,所以属于磁盘的顺序写,效率很高。如图:
Topic and Partition.png
5、网络模型
Kafka的网络模型基于Reactor模型,即响应模型。Kafka网络模型分为两部分:Kafka客户端即Consumer和Producer都是单线程的Reactor模型,Kafka服务端是多线程的Reactor模型。
5.1、单线程Reactor
如图:
单线程Reactor.jpg
Reactor线程负责多路分离套接字,Accept新连接,并分派请求到Handler处理器。
5.2、多线程Reactor
如图:
多线程Reactor.jpg
[图片上传失败...(image-5678a1-1575294197801)]
- Acceptor:1个接收线程,负责监听新的连接请求,同时注册OP_ACCEPT 事件,将新的连接按照"round robin"方式交给对应的 Processor 线程处理;
- Processor:N个处理器线程,其中每个 Processor 都有自己的 selector,它会向 Acceptor 分配的 SocketChannel 注册相应的 OP_READ 事件,N 的大小由“num.networker.threads”决定;
- KafkaRequestHandler:M个请求处理线程,包含在线程池—KafkaRequestHandlerPool内部,从RequestChannel的全局请求队列—requestQueue中获取请求数据并交给KafkaApis处理,M的大小由“num.io.threads”决定;
- RequestChannel:其为Kafka服务端的请求通道,该数据结构中包含了一个全局的请求队列 requestQueue和多个与Processor处理器相对应的响应队列responseQueue,提供给Processor与请求处理线程KafkaRequestHandler和KafkaApis交换数据的地方。
- NetworkClient:其底层是对 Java NIO 进行相应的封装,位于Kafka的网络接口层。Kafka消息生产者对象—KafkaProducer的send方法主要调用NetworkClient完成消息发送;
- SocketServer:其是一个NIO的服务,它同时启动一个Acceptor接收线程和多个Processor处理器线程。提供了一种典型的Reactor多线程模式,将接收客户端请求和处理请求相分离;
- KafkaServer:代表了一个Kafka Broker的实例;其startup方法为实例启动的入口;
- KafkaApis:Kafka的业务逻辑处理Api,负责处理不同类型的请求;比如“发送消息”、“获取消息偏移量—offset”和“处理心跳请求”等;
- 点赞
- 收藏
- 分享
- 文章举报
- Linq to Object 深入理解(一):了解Linq之前的基础知识
- Windows深入了解故障恢复控制台1--概述
- MyBatis 基础搭建及架构概述
- 深入了解Kafka基本原理
- 深入了解jQuery之整体架构
- Android 4学习(6):概述 - 深入了解Android Activity
- 快速学习javaSE基础1-java概述(了解)
- html基础结构(深入了解head元素)
- 深入了解kafka(二)
- java基础 深入了解单例设计模式
- 深入了解HBASE架构
- Android 4学习(6):概述 - 深入了解Android Activity
- 物联网架构成长之路(8)-EMQ-Hook了解、连接Kafka发送消息
- 这些 iOS 面试基础题目,你都深入了解吗?
- 这些 iOS 面试基础题目,你都深入了解吗?
- 深入了解CPU两大架构ARM与X86
- OC基础—语法概述(初步了解Objective-C)
- Java基础----从装饰设计模式例子深入了解this
- 【Kafka】深入了解kafka
- 《深入了解mybatis原则》 MyBatis架构设计和案例研究