kafka入门之broker--通信协议

kafka的通讯协议是基于tcp之上的二进制协议，所有类型的请求和响应都是结构化的，由不同的初始类型构成。kafka使用这组协议完成各个功能的实现。

单个kafka client通常需要同时连接多个broker服务器进行数据交互，但每个broker之上只需要维护一个Socket连接用于数据传输。clients可能会创建额外的socket连接用于其他任务，如元数据获取以及组rebalance等。kafka自带的java clients使用了类似于epoll的方式在单个连接上不停的轮训以传输数据。

broker端某时刻只能处理一条请求的做法是为了保证不会出现请求乱序。clients端在实现时，需要自行保证请求发送顺序。

3中请求发送流向：

1.clients给broker发送请求

2.controller也能够给其他broker发送请求

3.follower副本所在的broker向leader副本所在broker发送请求。

请求/响应结构：

统一构建于多种初始类型之上：

初始类型：

所有的请求和响应都具有统一的格式，即size+Request/Response,其中的Size时int32表示的整数，表示了该请求或响应的长度信息。

请求=请求头部+请求体，请求体随类型变化，

请求头固定：

api_key:请求类型,int16整数表示

api_version:请求版本号,以int16整数表示

correlation_id:与对应响应的关联号，实际中用于关联response与request，方便用户调试和排错。该字段以int32整数表示

client_id:表示发出此请求的client ID，实际场景中用于区分集群上不同clients发送的请求。该字段是一个非空字符串。

响应=响应头部+响应体，响应体格式随请求类型变化，

响应头部固定：

corrlation_id:该字段值就是上面请求头部中的correlation_id。有了该字段，用户就能知道该请求对应于哪个请求了。

kafka推荐用户总是指定client_id和correlation_id，这样可以方便用户后续定位问题和debug。

1.0.0版本38个请求类型

produce请求：事务id+ack+timeout+[topic数据]

produce响应结构：

2.FETCH请求，既包括clients向broker发送的fetch请求，也包括分区follower副本发送给leader副本的fetch请求。格式为：

replica_id+max_wait_time+min_bytes+max_bytes+isolation_level+[topics]

3.client向broker发送metadata请求以获取指定topic的元数据信息。

请求处理流程：