​

Lead: take advantage of everyone lunch time to give everyone the whole text, next steamed bread, next bowl of rice, slip a small wine, open a stomach ~\

Technical article prologue for programmers

sequence

The pine mountain

Blue sky and white clouds built wallsSunlight penetrates the bamboo stream

Sprinkled on the bluestone platform

Lingering cicadas and birdsong

The raindrops fell implicitly on the summerhouse last night

Avoid the noise and heat of the city

The beginning of text and nature interweaveA cup of green tea goes well with a refreshing summer meal

Lovely pig’s weekend has been quietly opened: good weekend, starting with a good article!

Distributed locks have too much privacy. Second in a series: Who secretly releases your locks?

The plot to review

Redis: The Deadlock trilogy review: Based on the byte Interview original novel: Distributed lock too much privacy series deadlock trilogy

We find three vulnerabilities of setnx+ Del lock and release lock to solve thread safety of accessing shared resources in distributed environment step by step:

    1. Code exceptions cause deadlocks finally code blocks release locks to ensure that exceptions are also triggered lock release \

    2. An unexpected process termination causes a deadlock to set the timeout period for the key, forcing the key to eventually be released as well, avoiding deadlock \

    3. The setnx and expire non-atomic operations use the atomic command provided with Redis 2.6.12: SET lock 1 EX 10 NX. Perfect solution! After three optimizations, the pseudocode looks like this: \

Boolean success = setnxAndsetExpire(key,30); // Get the lock and set the expire time to 30 seconds. Try {// do something that cannot be described doSomeBeyondDescription(); }finally{// release lock del(key); }Copy the code

Is that how it ends? !

Of Course,NO!!!

Who was it that broke our locks?

The introduction of multithreading often increases the complexity of program development and design. Locking operations are no exception.

Communication between two or more threads through shared resources. Let’s take a look at the problem by hand:

  • Thread 1 locks (locks the door) and sets a timeout time of 30 seconds (which thread 1 estimated to be 30 seconds), starts to do something indescribable for 1 minute (thread 1 is more persistent 😋), but apparently gives itself less time than expected, and at 30 seconds the lock is released (the door automatically opens).
  • Thread 2 was waiting for the lock and at 30 seconds the lock was released.The door opens, and thread 1 is still doing something inside), resulting in thread 2 locking the door (and locking the door) and also doing something indescribable.
  • Thread 1 is finally done at 2:30, releasing the lock. (Opens the door and goes away)
  • Thread 3 was waiting for the lock and found that the lock was released. (The door opens, and thread 2 is still doing something inside)
  • Thread 3 also starts doing things…

Things got awkward and out of hand:

  • Thread 1 and thread 2 are working at the same time —- note: ①
  • At 2min3s, thread 2 and thread 3 are doing something —- note: ①

So who’s secretly releasing our locks? You must have the answer. Thread 1 is

How to ensure that the lock is not secretly released by others?

Today this article we first talk about the problem ②, pay attention to our public account “interview strange circle”, we will continue to kan the problem ① next article!

Do not know do you have solution train of thought? Revelation! Revelation! Each thread uses its own proprietary token. Each thread can only release its own lock 🔐 by using its own token.

The pseudocode looks like this:

// Generate token String Token = uuid.random (); Boolean success = setnxAndsetExpire(key,token,30); // Get the lock and set the expiration time to 30 seconds. Try {// do something that cannot be described doSomeBeyondDescription(); If (get(key) == token){del(key); }}Copy the code

The lock added by each thread can only be released by itself. Thread 1 can no longer open thread 2’s door.

Is Redis distributed lock perfect?

Again, no? Distributed environment and multi-threading background, it is really, really, really complicated!

Note 1: The problem of thread 1 and thread 2 accessing a shared code block is not solved.

Ok, dinner is ordered, it’s time to serve!

According to the byte interview adaptation of the original novel: distributed lock privacy too much series third play, next to be continued….

Let’s continue the interview cycle. I’m cute pig.

Go a finally!

A pig said

So-and-so: How dangerous are pigs? Piggy: Why? X: You know too much. Pig: 😒 cold ~

The pig keeps learning to keep from being stupid. Piggy has organized the lifelong learning materials into personal resources: classic interview questions in the industry, basic tutorials, advanced tutorials, big factory face classics, middleware practice, database principles, technical learning routes, mind maps… There are too many to write

Now that you’ve seen this, take a look at this struggling pig:

www.mianshiguaiquan.comIt’s purple like this. It’s your favoriteSimple little cardsStyle: