I am Dumb

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

Madara Uchiha

Well things not always work in production as expected. Mostly when you are running multiple instances of your application.

Microservices

πŸš€ 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.

  • Client will request our server
  • Request will reach at our load balancer
  • And one of the instance will get the request and will make a write query into 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:-

  • fetch the user from the DB
  • check if user is a free user or already paid
  • if free, then mark it paid and save in the db
  • if paid, send “Already paid” in the response.

⚑️ 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….

  • Step 1: We are fetching user (Atomic transaction)
  • Step 2: Running some business logic in the code
  • Step 3: Updating the MySQL record if user not paid (Atomic transaction)

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.



Locking

βœ… Here comes the saviour, Locks
Operating systems locks meme

πŸ” 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:-

  • Step 0: try-acquire() lock
  • Step 1: If acquired, We are fetching user (Atomic transaction)
  • Step 2: Running some business logic in the code
  • Step 3: Updating the MySQL record if user not paid (Atomic transaction)
  • Step 4: release() the lock



πŸ˜… Problem

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



πŸ”“ Distributed Locking

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?




🎈 Using Redis to implement Distributed Locking



Using a single instance of Redis:-

Redis single instance lock

But here are the few problems with a single redis instance:-

  • A single instance may fail & lock acquired may not be released
  • If two instances are used (master-replica) when one client will acquire lock on one instance
  • master has to communicate the same with replica to sync. This communication itself is an async communication

πŸš€ 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).



Using Redlock Algorithm:-

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

Redlock algorithm

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:-



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *