In today's article, I will write a detailed explanation of an interview question.
In the past two weeks, I have been working on the department's budget for next year, and I have made a big head. Finally got it almost, I quickly took time to learn to charge these days.
In order to study with questions, I specially asked a friend from a big factory to ask for a copy of their interview questions. The company name is not mentioned, and the difficulty is roughly equivalent to P8.
One of the interview questions is:
How does Kafka achieve sequential consistency between sender and receiver?
I searched for information and answers on the Internet, and found that many of them were wrong or outdated.
So, I decided to write my own article to explain this problem in detail.
Producer 端：
The sender of Kafka sends messages. If the default parameters are not set, the messages can be sent to the Kafka server in batches in the order in which the messages are sent if there is no network jitter. However, once the network fluctuates, messages can go out of order.
Therefore, to strictly ensure that Kafka sends messages in an orderly manner, we must first consider sending messages synchronously.
There are two ways to send messages synchronously:
The first way: set the message response parameter acks > 0, preferably -1.
Then, set
max.in.flight.requests.per.connection = 1
After this setting is completed, on the sender side of Kafka, after a message is sent, the response must meet the parameters set by acks before sending the next message. Therefore, although in use, it is still sent asynchronously, in fact, the bottom layer is already sent one by one.
The second way: After calling the send method of KafkaProducer, call the get method of the Future object returned by the send method to block and wait for the result. After the result is returned, continue to call the send method of KafkaProducer to send the next message.
In addition to sending messages synchronously, the problem of message retransmission must also be considered.
When there is a problem with sending, the Kafka sender can determine whether the problem can be automatically recovered. If it is a problem that can be automatically recovered, retries > 0Kafka can be set to automatically retry.
Depending on the version of Kafka, after Kafka 1.0, the sender introduced the idempotent feature. Introducing the idempotent feature, we can set it like this
enable.idempotence = true
Idempotent feature This feature can add a sequence number to the message, and each time it is sent, the sequence number is incremented by 1.
After enabling the idempotent feature of the Kafka sender, we can set
max.in.flight.requests.per.connection = 5
In this way, when Kafka sends a message, since the message has a serial number, when there is an error in sending the message, the bottom layer of Kafka will obtain the serial number of the last few logs on the server side and the serial number of the message that the sender needs to resend. In contrast, if it is continuous, then you can continue to send messages to ensure the order of the messages.
Broker side:
Kafka's Topic is just a logical concept. The partitions that make up the Topic are where the real messages are stored.
Kafka only guarantees that messages within the same partition are ordered. Therefore, if you want to ensure that the business is strictly ordered globally, you must set the Topic as a single partition.
However, often our business does not need to consider the overall order, we only need to ensure the order of different types of messages in the business. Different types of messages in these services can be set to different Keys, and then modulo is obtained according to the Keys. In this way, since messages of the same type have the same Key, they will be assigned to the same partition to ensure ordering.
However, there is a problem here, that is, when we change the number of partitions, the messages that may have been allocated to the same partition before will be allocated to other partitions. This does not guarantee message order.
Faced with this situation, it is necessary to consider the impact on the business when dynamically changing the partition. It may be necessary to reclassify messages based on business and current partition requirements.
In addition, if a topic has multiple partitions, and the min.insync.replicasspecified number of replicas hangs, this situation will occur: the sending message cannot be written to the corresponding partition, but the consumption can still consume the message.
At this time, we often guarantee availability and consider switching the partition of messages. Once this is done, the order of messages may be inconsistent.
Therefore, it is necessary to ensure that the min.insync.replicasparameter configuration is appropriate to ensure the order of message writing to the greatest extent possible.
Consumer 端：
On the consumer side, according to the Kafka model, each partition under a topic can only belong to a certain consumer in the consumer group that listens to the topic.
Suppose the number of partitions of the topic is P, and the number of consumers in the consumer group is C. Then, if P < C, the consumer will be idle; if P > C, a consumer will be allocated multiple partitions, as shown in the following figure.
Therefore, when we use the poll method on the consumer side, we must pay attention: the records obtained by the poll method are likely to be in multiple partitions or even multiple topics.
It is also necessary to further sort and filter through the records (TopicPartition partition) of ConsumerRecords in order to truly guarantee the sequential and consistent use of sending and consumption.
Another point to pay attention to is the consumer's Rebalance. Rebalance is the process of letting all consumer instances under a consumer group reach a consensus on how to consume all partitions of a subscription topic.
This Rebalance mechanism is the most notorious place for Kafka to take care of:
-
Every time it rebalances, it will suspend the consumption of all consumer groups.
-
Then there are many bugs in Rebalance. For example, after Rebalance, either a certain consumer suddenly collapses, or some consumers in the consumer group stop.
-
Since Rebalance is equivalent to redistributing partitions to the consumer group, this may cause the partitions corresponding to consumers before and after Rebalance to be inconsistent. If the partitions are inconsistent, the natural consumption order cannot be consistent.
Therefore, we will try our best not to let Rebalance happen. There are three situations that will trigger the rebalance of Kafka consumers:
-
Change of consumer group membership: This often means that we believe that the number of consumers in the group has been increased or decreased, or that some consumers have crashed, resulting in being kicked out of the group.
-
The number of subscription topics has changed: Kafka's consumer group can use regular rules to fuzzy match topics. This creates a problem. When we add topics in Kafka, the number of topics monitored by the consumer group may change.
-
The number of partitions of the subscription topic changes: Sometimes, we may want to dynamically change the number of partitions of the topic online.
Therefore, when these three situations trigger Rebalance, there will be problems, and the inconsistent consumption order is only a slight negative impact.
Writing here, it is basically a complete answer to this interview question.
Among them, the idempotent nature of the Producer side and the Rebalance situation of the Consumer side are the easiest to miss in answering the similar interview questions about Kafka's sequential consistency. And many online interview questions answers are relatively outdated, and no questions about these two characteristics have been discussed.
Therefore, when you are preparing for an interview, you must review the knowledge and characteristics of the relevant middleware, rather than memorizing the answers by rote. I hope you will pay more attention when you study.
Hello, I'm Shimonai.
The technical director of a listed company, managing a technical team of more than 100 people.
I went from a non-computer graduate to a programmer, working hard and growing all the way.
I will write my own growth story into articles, boring technical articles into stories.
Welcome to pay attention to my official account. After following, you can receive high concurrency and algorithm learning materials.
