1、拓扑结构
2、基本组成
- Broker：一台Kafka服务器就是一个Broker，一个集群由多个Broker组成，一个Broker可以容纳多个Topic，Broker和Broker之间没有Master和Standby的概念，他们之间地位是平等的；
- Topic：每条发送到Kafka集群的消息都属于某个主题，这个主题就称为Topic。物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存在一个或多个Broker上，但是用户只需指定消息主题Topic即可生产或消费数据而不需要关心数据存放在何处；
- Partition：为了实现可扩展性，一个非常大的Topic可以被分为多个Partition，从而分布到多台Broker上。Partition中的每条消息都会被分配一个自增Id（Offset）。Kafka只保证按照一个Partition中的顺序将消息发送给消费者，但是不保证单个Topic中多个Partition之间的顺序；
- Offset：消息在Topic的Partition中的位置，同一个Partition中的消息随着消息的写入其对应的Offset也自增；
- Replica：副本，Topic的Partition有N个副本，N为副本因子。其中一个Replica为Leader，其他都为Follower，Leader处理Partition的所有读写请求，Follower定期同步Leader上的数据；
- Message：消息是通信的基本单位。每个Producer可以向一个Topic发布消息；
- Producer：消息生产者，将消息发布到指定的Topic中，也能够决定消息所属的Partition：比如基于Round-Robin或者Hash算法；
- Consumer：消息消费者，向指定的Topic获取消息，根据指定Topic的分区索引及其对应分区上的消息偏移量来获取消息；
- Consumer Group：消费者组，每个消费者都属于一个组。当消费者具有相同组时，消息会在消费者之间负载均衡。一个Partition的消息只会被相同消费者组中的某个消费者消费。不同消费者组是相互独立的；
- Zookeeper：存放Kafka集群相关元数据的组件。Zookeeper集群中保存了Topic的状态信息，例如分区个数、分区组成、分区的分布情况等；保存Broker的状态信息；保存消费者的消费信息等。通过这些信息，Kafka很好地将消息生产、消息存储、消息消费的过程结合起来；
3、zk节点说明
- topic注册信息：/brokers/topics/[topic]，存储topic的partitions的所有信息；
示例：
{ "version": 1, "partitions": { "0": [1, 2], "1": [2, 1], "2": [1, 2] } }
- partition状态信息：/brokers/topics/[topic]/partitions/[partitionId]/state，存储分区状态信息；
示例：
{ "controller_epoch": 1, "leader": 2, "version": 1, "leader_epoch": 0, "isr": [2, 1] }
- broker注册信息：/brokers/ids/[0...N] ，每个broker都会对应一个全局的id，此节点为临时节点；
示例：
{ "jmx_port": 6061, "timestamp": "1403061899859", "version": 1, "host": "192.168.1.148", "port": 9092 }
- ControllerEpoch信息：/controller_epoch，值为数字，每当主controller变更时，其对应的epoch就会增大；
- Controller注册信息：/controller，存储主控制器所在的broker节点信息；
示例：
{ "version": 1, "brokerid": 3, "timestamp": "1403061802981" }
- Consumer offset：/consumers/[groupId]/offsets/[topic]/[partitionId]，用来跟踪每个Consumer所消费的分区的最大offset，此节点为持久化节点。
- 删除的topic信息：/admin/delete_topics，需要删除的topic信息；
示例：
{ "version": 1, "topics": ["foo", "bar"] }
- Topic配置信息：/config/topics/[topic_name]
示例：
{ "version": 1, "config": { "config.a": "x", "config.b": "y" } }
4、Broker模块
kafka集群一般由多个 broker 节点构成，Kafka 会从中选举一个 broker 节点作为 Leader 角色，并通过节点上运行的 KafkaController 组件控制整个集群中各个 broker 节点的协同运行，以统一对外提供服务。就单个 broker 节点而言，Kafka 会为节点绑定一个 Acceptor，用于接收来自客户端和其它 broker 节点的连接，Processor 组件会从这些连接中获取请求并交由 Handler 线程进行处理。Handler 基于 KafkaApis 组件解析具体的请求类型并分发给具体的组件，同时负责构造和发送响应结果。KafkaApis组件使用LogManager、ReplicaManager 和 GroupCoordinator等组件完成协议的处理。
- SocketServer：首先开启一个Acceptor线程来监听9092端口，当有新连接建立成功时，会将对应的SocketChannel轮询交由Processor线程池中的某个线程处理。Processor线程会监听客户端网络上的的读写事件，当有读事件时，会读取数据并放入RequestChannel的请求队列；当有数据发送时，会从RequestChannel的相应队列读取并发送给客户端；
- KafkaRequestHandlerPool：处理Socket读写请求的线程池，线程KafkaRequestHandler从RequestChannel的请求队列中获取请求，然后调用KafkaApis处理业务逻辑，最后将响应回写只RequestChannel中的响应队列，并最终交由SocketServer中的Processor线程发送给客户端；
- LogManager：日志管理模块。提供日志文件管理，索引文件管理，删除过期数据及冗余数据、刷新脏数据、日志文件checkPoint等功能；
- ReplicaManager：副本管理模块。提供Topic的副本分区管理，Leader及ISR状态管理，副本变更管理等；
- OffsetManager：偏移量管理模块。提供对偏移量的管理功能；
- GroupCoordinator：消费分组协调模块。主要提供对消费者分组内分区的分配管理，维护分组内消费偏移量等；
- KafkaScheduler：后台任务资源调度模块。主要为LogManager、ReplicaManager、OffsetManager等提供定期的任务调用服务；
- KafkaApis：kafka业务逻辑实现模块。根据不同的Request，利用LogManager、ReplicaManager、OffsetManager等来处理具体的业务逻辑。
- KafkaHealthCheck：broker在/brokers/ids上注册自己的id，当broker上/下线的时候会在更新自己的id；
- TopicConfigManager：在/config/changes上注册自己的回调函数来监测Topic配置信息的变更；
- KafkaController：集群控制管理模块。集群元数据信息保存在zk上，此模块通过在不同的节点注册回调函数来达到监测集群状态的目的；
