Welcome to follow our wechat official account: Shishan100
My new course ** “C2C e-commerce System Micro-service Architecture 120-day Practical Training Camp” is online in the public account ruxihu Technology Nest **, interested students, you can click the link below for details:
120-Day Training Camp of C2C E-commerce System Micro-Service Architecture
1, read and write lock introduction
What are fair and unfair locks for Concurrent interview questions in Java? “, talking about fair and unfair locks for Java and packet distribution.
This article talks about read-write locks. The so-called read-write lock is to split a lock into read locks and write locks. Then when you add a lock, you can add a write lock or a read lock. As shown in the following code:
If one thread holds a write lock, no other thread can hold a write lock. Only one thread can hold a write lock at a time. Because a write lock means that someone has to write to the shared data, no one else can write to the data.
At the same time, if one thread adds a write lock, the other thread cannot add a read lock, because since someone else is writing data, the rest of you cannot read data.
If one thread has a read lock, the other thread can read the lock at the same time, because only one thread is reading the data, and other threads can also read the data!
Similarly, if one thread holds a read lock, no other thread can hold a write lock. Since someone is reading data, you can’t write data at will.
All right! This is a preliminary introduction to the use of read and write lock, I believe that many students should know before, because this is a very basic piece of knowledge in Java development.
2. Optimization of read/write locks for microservices registries
Moving on now, let’s focus on optimizing read/write locks in microservices registries.
Why talk about it?
Because if you go out for an interview, you are likely to be asked the question of read/write lock, this time you can naturally bring up, you have learned about the Spring Cloud micro service technology architecture, and at the same time, there are some insights and opinions about the micro service registry registry read/write lock optimization.
This will be much better than simply explaining the basics of read-write locking and how to use it.
First of all, you need to understand a little bit about the overall architecture of microservices, you can refer to an article written before: Please! Please do not ask me the underlying principles of Spring Cloud in the interview! .
It’s also important to understand the core principles of The Spring Cloud Eureka, or microservices registry. You can refer to an article I wrote earlier how does a microservices registry host tens of millions of accesses to a large system? .
Ok, so with that in mind, let’s get started.
Take a look at the figure below, now that we know that a microservice registry (either Eureka or Consul or a microservice registry you wrote yourself) will definitely have the concept of a service registry in memory.
This service registry is to store the address information sent by each micro-service registration, which stores the number of service instances of each service, which machine each service instance is deployed to monitor which port number, mainly such information.
OK, so now the problem is that the data in the service registry is actually read and written by someone else.
For example, if a service is registered when it is started, the data in the service registry will be modified. This is the write process.
In turn, other services will also read the data from the service registry, because each service needs to be aware of the machines on which other services are deployed.
Therefore, the service registry data in memory, is naturally read and write concurrency problem! There may be multiple threads to write, and there may be multiple threads to read!
If you don’t protect the registry data in the same memory, then you can have multiple threads simultaneously modifying the shared data, which can lead to data corruption, right?
If you look at the diagram below, you can see the above process.
Synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized
Synchronized, you might think, serializes all threads reading and writing to the service registry. Isn’t that enough to keep the service registry data safe in memory?
Here is a piece of pseudo-code to give you a feel for it:
Synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized synchronized
All threads reading and writing to the service registry are serialized.
Think about it, what do we want? In fact, when someone writes data to the service registry, it won’t let others write it, and it won’t let others read it!
Then, when someone is reading the service registry data, everyone else can read it at the same time, but no one else is allowed to write the service registry data!
Right? Isn’t that what we want?
With this in mind, we should not force synchronized to serialize all read-write threads, which would result in very low concurrency.
If you look at the following figure, we want the first effect: once someone is writing to the service registry data, we put a write lock on it so that no one else can write or read.
What if someone is reading the data? This allows others to read, but allows no one to write. Look at the picture below.
Now, the key point is, what’s the good of this? In fact, most of the time is read operation, so the use of read lock allows a large number of threads to read data at the same time, without blocking and queuing, ensuring high concurrent read performance is relatively high.
Then, when a small number of services are online to register data, there are few data writing scenarios. At this time, data writing can only be done by adding write locks one by one and then writing data, while writing data, others are not allowed to read data.
So read/write locks are ideal for this type of read-write scenario.
Also, can we try to keep reading the data while we’re writing it? When a large number of read locks are added, it will block other people to write data and lock for a long time. Can this situation be avoided?
Yes, use multi-level caching, as described in the previous article: How does a microservice registry host tens of millions of accesses to a large system? ,. It analyzes the multi-level caching mechanism in the Spring Cloud Eureka microservice registry.
And finally, what would that pseudo-code look like if it were optimized with read/write locks?
What is volatile about Java concurrent interview Questions? How can Java 8 optimize CAS performance? What is your understanding of AQS? What are Fair locks and Unfair Locks for Concurrent Java interview questions? Optimization of read/write locks for microservices Registries in Java concurrent Interview questions **, ** stay tuned
END
If there is any harvest, please help to forward, your encouragement is the biggest power of the author, thank you!
A large wave of micro services, distributed, high concurrency, high availability of original series of articles is on the way
Please scan the qr code belowContinue to pay attention to:
Architecture Notes for Hugesia (ID: Shishan100)
More than ten years of EXPERIENCE in BAT architecture