Well, whenever we work in our local system everything works as butter. That is why we call "No better place than 127.0.0.1" but WAKE UP TO THE REALITY
Well things not always work in production as expected. Mostly when you are running multiple instances of your application.
? As you can see that if multiple instances of our application are running and let's say that our client make a request to mark a user as a paid user in our DB.
It seems alright right? No problem till now right.
Well, yes till now there is no problem. But what if we want to write a business logic like:-
⚡️ As we know that (assume we are using MySQL here) MySQL DBs are ACID compliant which means any query will be atomic and isolated. which means MySQL query will be run in atomic way, either it will pass or fail. But it will not quit in between.
? But there is one issue here. Think, Think....
What will happen if at Step 2, one more request comes to cancel the payment, and then that query runs first and marks user as free, then step 3 runs and user marked as Paid.
?? Hurray, User got access to our Products without even paying.
✅ Here comes the saviour, Locks
? Lock is a structure that allows only one thread at a time to enter a critical section (block of code that should not be accessed by multiple workers i.e. threads)
Hence, we will acquire lock before and release after the completion of the operation:-
Now, here comes the problem which is if we will use some in memory lock data structure or any memory based lock it will be eligible for one instance for our application. what about the other instances running the same code and updating in the DB?
Well here comes the concept of Distributed locking
Here lock acts as a centralised service, where if one instance of our service acquires the lock then others can't on the same key.
WHAT KEY COULD BE HERE IN PAYMENT SERVICE?
? For a user making payment key could be the combination of = "PAYMENT_" + user_id + amount
And this will be unique per user. And this key will remain same in case of user making payment or cancelling payment. Hence when one is happening other action can't proceed because both actions will try to acquire on same key.
? What what the heck is Key, Acquire lock, release lock. And most importantly how redis is being in use?
But here are the few problems with a single redis instance:-
? So, if lock is acquired on master, and while communication to replica if master goes down before syncing with replica. Replica will become master where Lock on the same key will be available to acquire that was acquired on the master earlier.
Two instances of our services will be able to acquire the lock on redis even having two instances (master-replica).
Acquiring Lock:- We will try to acquire lock on multiple redis instances with lock expiration time
Validation of Lock:- lock will be considered as acquired if major redis instances got lock acquired for the client
Releasing Lock:- When releasing the lock, all instances releases the lock
And yes that's it.
❤️ Thanks for the read, and subscribe to our newsletter for more such articles:- https://www.serversidedigest.com/
For more information:-
The above is the detailed content of How to implement a Distributed Lock using Redis. For more information, please follow other related articles on the PHP Chinese website!