table of Contents
1 interactive, client and server-side
2, bad performance network communication frequently brought
3, batch mechanisms: a plurality of messages into a batch packaged
4, request mechanisms: a plurality of packed into a batch request
"This article, we talk to a message-oriented middleware technology related topics, for an excellent messaging middleware, the client and server communication when this mechanism for how communication network design, in order to ensure the best performance gifted it? even through good design, so more than 10 times performance improvement.
In this paper, we have to Kafka as an example to give you an analysis, Kafka on the client and server communication when some network communication-related mechanisms underlying how to design and how to optimize.
1 interactive, client and server-side
If we use kafka as messaging middleware, there is bound to the client as a producer sends a message to him, that we should be able to understand.
For Kafka, it is his own support distributed message store, and what does it mean?
For example, now you have a "Topic", a "Topic" you can understand the logic of a set of message data.
For example, now you put all the orders are sent to a "Topic" to go, then the "Topic" is called "OrderTopic", which have put the order data.
Then the "Topic" amount of data can be a big, big, can not be placed on a machine, right?
So, we can disperse Kafka stored on multiple machines, machine data can be stored as part of each.
This is the mechanism Kafka distributed message store, each server is called a Kafka Broker, is responsible for managing data on a single machine.
Take a look at the following chart:
A "Topic" can be split into a plurality of "Partition", each "Partition" portion of the data store, each Partition are on different machines Kafka Broker, thus achieving a dispersion of data stored on multiple machines effects.
The client then sends a message to the time of Kafka Broker, for example, you define a "OrderTopic" order data split into three "Partition", then the three "Partition" were placed on a Kafka Broker, that is, to to distribute data to all three orders Kafka Broker up.
At this point it will default three Broker laid down the strategy balancing a load, for example, assume that the order data, a total of 30,000, will distribute 10,000 order messages to each Partition, so that uniformly dispersed in the order data on the machine.
The whole process, as shown below:
2, bad performance network communication frequently brought
Well, now the question is, the client sends a message to Kafka Broker when, for example, now you want to send an order to go Kafka, when he sent in the past is how it?
Is a direct order message corresponds to a network request, send it up to a Broker?
If you do so, it is bound to cause frequent network communication with a broker, frequent communication networks, each related to the complex network connection, transmission process, then in turn leads to poor client performance.
Give you an example, say each time you send an order to the broker through a communication network, require time-consuming 10ms.
So if an order is sent to the network traffic on a broker, it is to send up to 100 orders a second, we think, is not the truth?
But if you say there are 10,000 orders per second to be sent, then it will cause you to send your performance fell far short of demand, that is, poor performance, it appears your system to send orders to kafka speed is particularly the slow.
3, batch mechanisms: a plurality of messages into a batch packaged
So first of all address this issue, kafka did the first optimization is to achieve a batch mechanism.
This means is that he will put the client in a memory buffer, every time you write an order to go into the memory buffer, and then in the memory buffer, will become multiple orders to pack up a batch.
For example, the default kafka specified size batch that 16kb, it means that your default is more than an order to scrape together the full size of 16kb, it will be a batch, then he will put up the batch sent to the broker via network communications.
假如说一个batch发送到broker，同样也是耗费10ms而已，但是一个batch里可以放入100条订单，那么1秒是不是可以发送100个batch？
此时，1秒是不是就可以发送10000条订单出去了？
而且在打包消息形成batch的时候，是有讲究的，你必须是发送到同一个Topic的同一个Partition的消息，才会进入一个batch。
这个batch里就代表要发送到同一个Partition的多条消息，这样后续才能通过一个网络请求，就把这个batch发送到broker，对应写入一个Parititon中。
4、request机制：多个batch打包成一个request
事情到这里就结束了吗？还没有！
比如现在我们要是手头有两个Topic，每个Topic都有3个Partition，那么每个Broker是不是就会存放2个Partition？其中1个Partition是Topic01的，1个Partition是Topic02的。
现在假如说针对Topic01的Partition02形成了一个batch，针对Topic02的Partition02也形成了一个batch，但是这两个batch其实都是发往同一个Broker的，如上图的第二个Broker。
此时，还是一个网络请求发送一个batch过去吗？
其实就完全没必要了，完全此时可以把多个发往同一个Broker的batch打包成一个request，然后一个request通过一次网络通信发送到 那个Broker上去。
假设一次网络通信还是10ms，那么这一次网络通信就发送了2个batch过去。
通过这种多个batch打包成一个request一次性发往Broker的方式，又进一步提升了网络通信的效率和性能。
其实 batch机制 + request 机制，都是想办法把很多数据打包起来，然后一次网络通信尽量多发送一些数据出去，这样可以提升单位时间内发送数据的数量。
这个单位时间内发送数据的数量，也就是所谓的“吞吐量”，也就是单位时间内可以发送多少数据到broker上去。
For example, every second can send 30,000 messages in the past, which is to represent the client's "throughput" how much.
Therefore, understand this principle, you can learn to design such a very good idea. Also during the interview, if you talk with the interviewer to kafka, can also be regaling kafka bottom with the interviewer, it is how to effectively improve network communication performance.
Finally, a picture again, as the full summary.