kafka学习(四)

集群成员关系

kafka使用Zookeeper 来维护集群成员的信息。每个broker都有一个唯一标识符，这个标识符可以在配置里指定，也可以自动生成。在broker启动的时候，它通过创建临时节点把自己的ID注册到Zookeeper。kafka组件订阅Zookeeper的/brokers/ids路径，当有broker加入集群或退出集群时，这些组件就可以获取通知。

 

控制器

 

控制器其实就是一个broker，只不过它除了具有一般broker的功能之外，还负责分区首领的选举。集群里第一个启动的broker通过在zookeeper里创建一个临时节点/controller 让自己成为控制器。其他broker在启动时也会尝试创建这个节点，不过他们会收到一个“节点已存在”的异常，然后“意识”到控制节点已存在，也就是说集群里已经有一个控制器了。如果控制器被关闭或者zookeeper断开连接，zookeeper上的临时节点就会消失。

 

复制

 

复制功能是kafka架构的核心，kafka使用主题来组织数据，每个主题被分为若干区，每个分区有多个副本。而副本有一下两种类型。

 

1.首领副本，每个分区都有一个首领副本。为了保证一致性，所以生产者请求和消费者请求都会经过这个副本。

2.跟随者副本，首领以外的副本都是跟随副本。跟随者副本不处理来自客户端的请求，它们唯一的任务就是从首领哪里复制信息，保持与首领一致的状态。如果首领发送崩溃，其中的一个跟随者会被提升为新首领。首领的另一个任务是搞清楚那个跟随者的状态与自己是一致的。

 

请求得到的最新消息副本被称为同步的副本。在首领发生失效，只有同步副本才有可能被选为新首领。

每个分区都有一个首选首领-创建主题时选定的首领就是分区的首选首领。

 

处理请求

broker的大部分工作是处理客户端，分区副本和控制器发送给分区首领的请求。

所有的请求信息都包含一个标准消息头。

Request type (也就是API key)

Request version （broken可以处理不同版本的客户端请求，并根据客户端版本作出不同的响应）

Correlation ID 一个具有唯一性的数字，用于标识请求信息，同时也会出现在响应消息和错误日志里。

Client ID 用于标识发送请求的客户端

 

broker会在它所监听的每一个端口运行一个acceptor线程，这个线程会创建一个连接，并把它交给processor线程去处理。processor线程的数量是可配置的，网络线程负责从客户端获取消息，把他们放进请求队列，然后从响应队列获取消息，把它们发送给客户端。

 

生产请求

生产者发送的请求，它包含客户端要写入broker的消息。

生产请求参数acks 可选值0 ，1 ,all

0 代表生产者发送消息之后就不管了

1代表只要首领收到消息就认为写入成功

all 代码所有的需要同步副本收到消息才算成功

包含首领副本的broker在收到生产请求是，会对请求做一些验证。

1.发送数据的用户是否有主题写入权限

2.请求里包含的acks值是否有效(0,1,all)

3.如果是acks=all 是否有足够多的同步副本保证消息已经被安全写入

最后消息被写入磁盘，Linux系统上，消息会被写到文件系统缓存里，并不保证它们何时回被刷新到磁盘上。

 

获取请求

在消费者和跟随者副本需要从broker读取消息时发送的请求。客户端发送请求，向broker请求主题分区里具有特定偏移量的消息。如果请求的偏移量存在，broker将按照客户端指定的数量上限从分区里读取消息，再把消息返回客户端。客户端除了可以设置broker返回数据的上限，也可以设置下限。

 

索引

kafka为每个分区维护了一个索引，消费者可以从任意位置读取偏移量。

 

清理的工作原理

 

每个日志片段可以分为两个部分

1.干净的部分

这些消息之前被清理过，每个键只有一个对应的值，这个值是上一次清理时保留下来的。

 

2.污浊的部分

这些消息是在上一次清理之后写入的。