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的元数据信息。