Design of Kafka producer message sending and receiving

think123 2020-11-10 11:24:45
design kafka producer message sending


Previous articles have analyzed Kafka The sending process and NIO How to use , But there are still a lot of holes left , Here is a summary of the remaining issues .

Why should the received data be cached ?

Kafka in Selector When reading the data from the remote end, the received data will be cached first

private void attemptRead(SelectionKey key, KafkaChannel channel) throws IOException {
//if channel is ready and has bytes to read from socket or buffer, and has no
//previous receive(s) already staged or otherwise in progress then read from it
if (channel.ready() && (key.isReadable() || channel.hasBytesBuffered()) && !hasStagedReceive(channel)
&& !explicitlyMutedChannels.contains(channel)) {
NetworkReceive networkReceive;
while ((networkReceive = channel.read()) != null) {
madeReadProgressLastPoll = true;
addToStagedReceives(channel, networkReceive);
}
}
}

stay NetworkClient in , What goes down is a complete ClientRequest, Enter Selector, Staging to channel Medium , It's also a complete Send object (1 A packet ). But this Send object , Leave it to the bottom channel.write(Bytebuffer b) When , You don't have to send it all at once , It may be called more than once write, In order to put a Send The object is sent out completely . This is because write It's non blocking , Not until it's completely sent out , Will return .

Send send = channel.write();
if (send != null) {
this.completedSends.add(send);
this.sensors.recordBytesSent(channel.id(), send.size());
}

If you go back here send==null It means it's not finished , You need to wait until the next time Selector.poll Send again . So the next time you send it, if Channel Inside Send Only part of it was sent , So this time node You won't be in ready state , Not from RecordAccumulator Take it out to this node Data sent , wait until Send After the object is sent , This node Will be in ready state , Then we can take out the data for processing again .

Again , At the time of receiving ,channel.read(Bytebuffer b), One response It may also be read many times , To fully receive . So there's the top while Loop code .

How to confirm the completion of message receiving ?

Know from above , Communication of underlying data , It's in every channel above ,2 A steady stream of byte flow , One send flow , One receive flow .
send When , It's good to say , Know the size of a complete message before sending it .
But when we receive the message response When , This information may be incomplete ( The rest of the data will be available later ), It can also contain more than one message . So how do we judge that the message has been sent ?
For reading messages, we must consider how the end of the message is represented , There are several ways to identify the end of a message :

  1. Fixed message size .
  2. Prefix the message with the length of the message .
  3. Use a special symbol to mark the end of the message .

Obviously, the first and third methods are not very suitable , therefore Kafka A second way is used to determine the size of the message to be sent . Put... In the head of the message 4 Bytes to determine the size of the message .

// receive messages , front 4 Bytes represent the size of the message
public class NetworkReceive implements Receive {
private final String source;
// Confirm the message size
private final ByteBuffer size;
private final int maxSize;
// The whole news response Of buffer
private ByteBuffer buffer;
public NetworkReceive(String source) {
this.source = source;
// Distribute 4 Byte header
this.size = ByteBuffer.allocate(4);
this.buffer = null;
this.maxSize = UNLIMITED;
}
}
// message sending , front 4 Bytes for message size
public class NetworkSend extends ByteBufferSend {
public NetworkSend(String destination, ByteBuffer buffer) {
super(destination, sizeDelimit(buffer));
}
private static ByteBuffer[] sizeDelimit(ByteBuffer buffer) {
return new ByteBuffer[] {sizeBuffer(buffer.remaining()), buffer};
}
private static ByteBuffer sizeBuffer(int size) {
//4 Bytes for message size
ByteBuffer sizeBuffer = ByteBuffer.allocate(4);
sizeBuffer.putInt(size);
sizeBuffer.rewind();
return sizeBuffer;
}
}

OP_WRITE When will it be ready ?

Although the last article mentioned epoll Principle , But I believe some people still feel confused , Let's put it another way OP_WRITE event .
OP_WRITE The event's ready condition does not occur when calling channel Of write After method , And it doesn't happen when you call channel.register(selector,SelectionKey.OP_WRITE) after , But when the underlying buffer has free space . Because write buffers have free space most of the time , So if you register to write events , This makes the write event always write ready , Choose to deal with the scene will always occupy CPU resources . therefore , Only when you do have data to write, register the write operation , And cancel the registration immediately after writing .

max.in.flight.requests.per.connection

This parameter specifies how many messages the producer can send before receiving a response from the server , look for Kafka Producer There is a corresponding class in InFlightRequests, A request to fly in the sky , That is, the request has been sent out response The number of requests that haven't come back yet , This parameter is also used to determine whether the node is ready The key factor . Only ready The node data can only be obtained from Accumulator Take it out and send it .

版权声明
本文为[think123]所创,转载请带上原文链接,感谢

  1. 【计算机网络 12(1),尚学堂马士兵Java视频教程
  2. 【程序猿历程,史上最全的Java面试题集锦在这里
  3. 【程序猿历程(1),Javaweb视频教程百度云
  4. Notes on MySQL 45 lectures (1-7)
  5. [computer network 12 (1), Shang Xuetang Ma soldier java video tutorial
  6. The most complete collection of Java interview questions in history is here
  7. [process of program ape (1), JavaWeb video tutorial, baidu cloud
  8. Notes on MySQL 45 lectures (1-7)
  9. 精进 Spring Boot 03:Spring Boot 的配置文件和配置管理,以及用三种方式读取配置文件
  10. Refined spring boot 03: spring boot configuration files and configuration management, and reading configuration files in three ways
  11. 精进 Spring Boot 03:Spring Boot 的配置文件和配置管理,以及用三种方式读取配置文件
  12. Refined spring boot 03: spring boot configuration files and configuration management, and reading configuration files in three ways
  13. 【递归,Java传智播客笔记
  14. [recursion, Java intelligence podcast notes
  15. [adhere to painting for 386 days] the beginning of spring of 24 solar terms
  16. K8S系列第八篇(Service、EndPoints以及高可用kubeadm部署)
  17. K8s Series Part 8 (service, endpoints and high availability kubeadm deployment)
  18. 【重识 HTML (3),350道Java面试真题分享
  19. 【重识 HTML (2),Java并发编程必会的多线程你竟然还不会
  20. 【重识 HTML (1),二本Java小菜鸟4面字节跳动被秒成渣渣
  21. [re recognize HTML (3) and share 350 real Java interview questions
  22. [re recognize HTML (2). Multithreading is a must for Java Concurrent Programming. How dare you not
  23. [re recognize HTML (1), two Java rookies' 4-sided bytes beat and become slag in seconds
  24. 造轮子系列之RPC 1:如何从零开始开发RPC框架
  25. RPC 1: how to develop RPC framework from scratch
  26. 造轮子系列之RPC 1:如何从零开始开发RPC框架
  27. RPC 1: how to develop RPC framework from scratch
  28. 一次性捋清楚吧,对乱糟糟的,Spring事务扩展机制
  29. 一文彻底弄懂如何选择抽象类还是接口,连续四年百度Java岗必问面试题
  30. Redis常用命令
  31. 一双拖鞋引发的血案,狂神说Java系列笔记
  32. 一、mysql基础安装
  33. 一位程序员的独白:尽管我一生坎坷,Java框架面试基础
  34. Clear it all at once. For the messy, spring transaction extension mechanism
  35. A thorough understanding of how to choose abstract classes or interfaces, baidu Java post must ask interview questions for four consecutive years
  36. Redis common commands
  37. A pair of slippers triggered the murder, crazy God said java series notes
  38. 1、 MySQL basic installation
  39. Monologue of a programmer: despite my ups and downs in my life, Java framework is the foundation of interview
  40. 【大厂面试】三面三问Spring循环依赖,请一定要把这篇看完(建议收藏)
  41. 一线互联网企业中,springboot入门项目
  42. 一篇文带你入门SSM框架Spring开发,帮你快速拿Offer
  43. 【面试资料】Java全集、微服务、大数据、数据结构与算法、机器学习知识最全总结,283页pdf
  44. 【leetcode刷题】24.数组中重复的数字——Java版
  45. 【leetcode刷题】23.对称二叉树——Java版
  46. 【leetcode刷题】22.二叉树的中序遍历——Java版
  47. 【leetcode刷题】21.三数之和——Java版
  48. 【leetcode刷题】20.最长回文子串——Java版
  49. 【leetcode刷题】19.回文链表——Java版
  50. 【leetcode刷题】18.反转链表——Java版
  51. 【leetcode刷题】17.相交链表——Java&python版
  52. 【leetcode刷题】16.环形链表——Java版
  53. 【leetcode刷题】15.汉明距离——Java版
  54. 【leetcode刷题】14.找到所有数组中消失的数字——Java版
  55. 【leetcode刷题】13.比特位计数——Java版
  56. oracle控制用户权限命令
  57. 三年Java开发,继阿里,鲁班二期Java架构师
  58. Oracle必须要启动的服务
  59. 万字长文!深入剖析HashMap,Java基础笔试题大全带答案
  60. 一问Kafka就心慌?我却凭着这份,图灵学院vip课程百度云