What should I do if I have not been exposed to high concurrency and distribution in my work?

background

There are always some highly concurrent and distributed problems in the interview, but I don’t get in touch with them in my work, and I don’t study by myself deeply. What can I do?

Distributed architecture knowledge is too large, small artisan is also a glimpse of the picture, combined with their own experience to elaborate their own ideas.

Based on my own interview experience, I will talk about the possible problems, technologies and solutions from the construction system of distributed system, which is the focus of distributed system and interview.

The phenomenon of

We start with the business scenario. With more and more users, when the memory, disk and CPU of a single system cannot meet the needs of the business, we need to change the single machine into multiple machines to solve the problem, so we need to introduce distributed horizontal expansion machines to increase throughput. For different business needs of hardware, bandwidth, importance are different, we once again do a fine-grained split, each module according to the context of the business split, so there is a microservice.

Then it also causes some problems, a request needs to cooperate with multiple services to solve, inevitably there will be data inconsistency problem? Then we need to make a trade-off between CAP, and we need to focus on the dependencies and data transfers between each service in terms of idempotent, distributed transactions, distributed locks, retries, compensation, etc. Finally, for different business can do circuit breaker, downgrade and other processing.

How does someone who doesn’t have the opportunity to work with so many nouns have to deal with such a busy Internet interview?

?

Start by recommending two books that do not solve the interview problem you encounter, but rather provide a general idea and solution. “Large Web Systems and JAVA Middleware Practices”, “Large Web Technology Architecture: Core Principles and Case Studies” and a pamphlet, which I quickly looked at is not bad, can quickly understand some key concepts. Introduction to Distributed Principles

Then someone continued to ask, “So far you have actually said a lot of nonsense, BUT I still have no idea how to solve the problem that I have no experience in distributed projects, and why I think it is difficult to mention distributed problems in the interview process?”

The answer is only one is to apply what you learn, because you hit the books again thoroughly, their own practice demo write again complete, the above listed technology and knowledge is still a little knowledge.

Here is my personal experience, to find a way to push the existing project to make technological change, if not, can do “fake change”.

At that time, my project did not use distributed architecture. I received a demand and estimated that it would take 3 weeks to complete, so I used my spare time to investigate how long it would take to access Dubbo, and it took about 5 weeks. Then I directly told my supervisor that I wanted to use Dubbo to complete the demand. It will take about 5 weeks, but it will solve the coupling problem of our project and increase the reuse. However, considering the schedule, I may need to work overtime every day to ensure the progress. Please rest assured. Sure enough, the supervisor agreed, so it was time for me to give full play to what I had learned. Only when I applied it to real projects could I truly understand its secrets.

This is how I learned dubbo, and another similar experience. When I joined the company, it was not a front end separation project, the development cost was too high, and angular was still popular, so I volunteered to do a refactoring using Spring Boot + Angular. Although I worked a lot of overtime at that time, I grew up a lot. When I think about it now, I am very grateful to my leaders at that time.

After these two things, I have a different understanding of these technologies. If you are like me, and you don’t have the experience of a big factory, and you don’t have enough environment to contact new technologies, you can also do similar attempts with me…

If?

Of course, even if you touch the distributed architecture is the tip of the iceberg, but enough to get started, then you need to constantly improve their own architecture, such as considering the access to cache, access to distributed locks, access to distributed transactions, access to message queues, and then consider the addition of fuses, degradation and other components. So over time you’ve been getting better.

So the question is, what if you, like me, argue and lose and don’t take your advice? Here I also have an experience to share with you, this is also an interview skill.

At that time, I was learning ZSET of Redis, and basically understood its data structure, principle and classic use cases. Therefore, I copied an existing piece of logic into our project, thought about it to see if there was any problem, and then built Redis on my own machine to solve it using ZSET. And solved all the problems perfectly. Remember when the requirement was to implement a weekly hot topic, live updates of the kind. Did you learn something at this point? This is what I called the “fake revolution” above.

The last

In the end, no matter what kind of thinking you choose, don’t give up your passion for learning and stay competitive.