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" bu...
For further actions, you may consider blocking this person and/or reporting abuse
Why just not use DB lock?
It is taken as an example bruh
Bad example "bruh". The point of DB transactions is that you can do:
Step 0: start transaction
Step 1: fetch data
Step 2: do business logic
Step 3: write data and commit transaction
Fetch and write become one atomic transaction together.
Or do the same with user locks as mentioned in another comment.
Performance impact: Long-held database locks can lead to contention, slowing down queries and increasing latency.
Reduced DB load: By offloading locking to Redis, you reduce contention on the database and improve overall system performance.
And also using distributed locks for every critical sections is more preferred than using resource level locks in the code
Actually redis is also a db in the sense it stores KV of any type.
You can perform the same but then you have to add a code logic on client side for resource locking and sync which is also possible.
Using redis gives you that for free as its curse has become a favor of being single thread actually helps with critical operations
First, thing is, you can actually use db for lock, as specified earlier: dev.mysql.com/doc/refman/8.4/en/lo...
Secondly: You could try to do update user with "transaction" and watch approach: redis.io/docs/latest/develop/inter...
And finally, as you have multiple redis instances, perhaps some hybrid solution, e.g sharding + lock would work well too.
You need to define some sort of hash function, which would help you to identify to which server to connect.
E.g, in simplest approach l you calculate some sort of crc, normalise that to your number os servers,
That way all components will try to acquire lock on the same redis server
In Laravel I tried cache locks and it were failing in production, now implemented database transaction with mysql lock for update on query with retry mechanism and no exception for the last few days.
Yep that works also
This is absolutely awesome, using db rise at times is always confusing and a little bit stress.
You have really put in do much there.
Nice one
Redlock is not safe and should not be used. To understand why, please see this thorough analysis
If you need distributed consensus, look elsewhere!
I believe It may take care by DB transaction isolation levels like dirty read and others and each server request will acquire DB lock until DB operation may not completed. another query can anyone let me know the use case to use redis/distributed cache locking?
Performance impact: Long-held database locks can lead to contention, slowing down queries and increasing latency.
Reduced DB load: By offloading locking to Redis, you reduce contention on the database and improve overall system performance.
And also using distributed locks for every critical sections is more preferred than using resource level locks in the code
I believe locking at distributed cache level, it would be for longer time as it may include cache level ops + network communication + Db operation. While DB lock shall have for DB operation only. Apart from that Db lock provide lot's of other features like locking timeout in case of Db connection down/Db down. I am not sure how distributed level locking is more optimized then DB locking. Whether Distribute cache level locking have all the mandatory features like DB locking which may required during any failure.
If you already have a sql db, why not simply use transactions and conditional writes?
DB is taken as an example for the critical section man