preface

Dude, I just dude, the interviewer just asked me if I could start tomorrow. What happened was that Anjiang was interviewing a large (really big) government affairs related company in Guangzhou. After a brief talk with the interviewer about some business scenarios and function implementation (maybe there was a shortage of staff, or maybe Anjiang was so excellent that she directly slapped the interviewer), she asked me if I could come to work tomorrow.

Of course, the above is the second interview, which mainly examines Anjiang’s ability to understand the whole project and to solve some implementation difficulties. There is no doubt that these two are a little confident.

At the end of the second meal, Anjiang declined. Good brothers to say, you are not stupid, so soon refused, is not enough money (yes, not enough). Of course I’m not that shallow. That’s what you want me to do. Bye. Ha, ha, ha, ha. It’s all in my head. Mainly because this company’s project is a government project, good brothers understand it.

The most horrible part was not this. In the interview, the interviewer asked me if I had any questions to ask him. I asked weakly: What is your technical system? Guess what the interviewer said, guys. I just got a quote from an old system that’s been running for almost ten years, as old as you can think of in terms of technology. It’s horrible to contemplate, my good brothers.

The following questions were mainly asked on one side. In general, there were no difficult questions or too many original things. Anjiang selected some representative questions, and some of the answers were my original answers, and some were sorted out by combining some materials.

How does MQ ensure idempotent consumption of messages

This problem is due to anjiang’s resume written proficient (familiar) MQ lead to a problem. So the way to answer that question is to understand what idempotency is.

Idempotent means that the result of multiple operations is the same. In other words, the results of one or multiple requests for the same operation are the same, and there are no side effects caused by multiple clicks. In the CASE of MQ, because of the jitter of the network, both the MQ consumer and the production side can have timeouts, resulting in repeated sending and consumption of MQ.

The key to idempotent consumption is to solve the problem of repeated message consumption. What does Anjiang say? No!!

Ahem, ahem, back to business. First, the production side needs to add a uniquely identified field to the message. Consumers can be divided into two situations. The first is to use Redis to solve the problem when there is no strict requirement for consistency in business or data. In other words, in the process of message consumption, Redis is read first to judge whether the message has passed. If the message has been consumed, no processing is done. Otherwise, a mark is added to Redis after successful consumption. In this way, there is a probability that the message is consumed, but the Redis flag is not added.

The second is to use Mysql to fetch transactions from other databases. When consuming a message, a record is inserted into the message consumption record (the table can even have a single field, such as the unique identifier (primary key) field mentioned above), and then the corresponding business logic operation is performed. The first thing to note here is that you need to add transactions to the method. Second, DuplicateKeyException needs to be caught, because normally the consumer has to turn on the ACK mechanism, and the message will not be ACK if it is not caught. This approach is not as good as the first approach in terms of performance.

Good brothers can tell according to the actual situation of their own business, the best thing to say both ways.

How does MQ handle large data volumes

Here’s the original scenario. After asking RabbitMQ how to ensure idempotent consumption of messages, the interviewer said how would you handle millions of concurrent requests.

Emmmmm, to be honest, I still don’t know why the interviewer asked me that. What is his motivation?

To my surprise, I answered. To begin with, the QPS for RabbitMQ and RocketMQ stand-alone machines would be around 100,000, but since our business logic for consuming messages would certainly involve changes to the database, normal message consumption would be synchronous, which would result in messages piling up at high concurrency levels.

So the problem is that the speed of the consumer is out of sync with the speed of the producer sending the message. The first step is to locate the cause of the slow consumption. After normal BUG removal, RabbitMQ can support concurrent consumption. For example, if you consume one item at the beginning, you can optimize it to consume 10 items at a time. It is important to turn on the ACK mechanism, otherwise you will lose messages. The other one is idempotent consumption, which is a sure way to repeat message consumption.

If the speed of the consumer is not enough, then we can expand horizontally. For example, add more consumer instances. One thing to note here is that because the database is the same, the database may not be able to hold up when there is too much consumption. Don’t forget the original reason for using MQ, asynchronous, decoupled, peak-clipping.

What if, in an emergency situation, information keeps piling up and is about to explode. Emmmm, stop asking, okay? I can’t handle it.

In case of emergency, we can make a temporary plan, first get more consumers, these consumers do not have any message processing logic, is to consume the message, and then into the database. After the repository is complete, the message is processed by running scheduled tasks or other means.

Where are the Redis performance throughput bottlenecks

This question Ann Jiang is a simple answer, the main two points.

First of all, since Redis is based on memory, the size of the machine memory also determines how much data to store.

But yes but it’s important to make a point here that Redis actually has a clustering model that sort of solves this problem. Cluster, if the good guys know about it. Some good brother will say, this thing I can’t ah, did not hear also did not play. That’s okay. You don’t even know hash Slot for an interview, right

The second bottleneck is network bandwidth, which is nothing to say.

Mysql > slow query

This word is really different people see different people see wisdom, good brothers how to blow, to their familiar direction to blow it. Ann sauce here is about a list of points for good brothers reference.

  1. First look at the length of the SQL, the number of associated tables. If a SQL is written like a snake, consider splitting the SQL.

  2. Check whether the table index design is reasonable, depending on the actual business scenario, or the condition of frequent query. Of course, do not add fields such as 0 or 1, such as the state type, which is meaningless.

  3. Check whether SQL queries some fields that are not needed in business scenarios, such as SELECT * FROM XXX. Here we need to explain why you can’t write this question, index overwrite and back to the table is roughly stated. Ann sauce here is not so deep, good brothers baidu.

  4. If both 1 and 2 are ok, use the explain keyword. The catch is that the interviewer will ask this question when they hear this key word. Which metrics (which are actually the fields of the Explain keyword) you focus on when using the Explain keyword should be remembered.

  5. Explain can be used to identify the cause of the index failure, such as OR, LIKE %xx%, conditional field function operations and so on.

Ann Jiang usually talks about these, if the interviewer is in the question of basic into our set inside. Because the above several are more familiar with us, for example, the third will certainly be asked in detail, good brothers to study the problem is not big. Hee hee hee hee

How does Feign solve cross-domain problems

Emmmmm, up to now I still don’t understand what the problem is, Anjiang is really never encountered. If it’s a request header pass, it’s easy to implementRequestInterceptorThis interceptor will do. But the interviewer said not this, I searched a circle also did not find the answer. Do you have a good brother to know, the comment section to teach Ann sauce, mo-mo-da!!

conclusion

These are some of the common interview questions anjiang asks or answers that are not very good, and some that she forgets.

Of course, the above answer is just for the sake of interview, good brothers usually more research, it is best to have a thing is not proficient, but at least very familiar with, after all, the thickness of the foundation determines the height of life.

Far away, I hope good brothers can become a bully after reading the interview, press the interviewer on the ground friction!!

Good brothers praise attention is the source of my renewal of power, and finally daily praise, attention