I am using global redis datastore, with two clusters Region-A and Region-B.Each regional cluster has three redis nodes one primary and two read replicas.
I have my service deployed in two regions as well Region-A and Region-B. So essentially I'm in an active/active setup when both Regions receive traffic.
Region-A and Region-B consume messages that get replicated between regions, which means that I'm getting duplicates.
Services need to be idempotent, so I'm using redis as a distributed lock mechanism.
The quesion:Java redison lib provides two APIs to lock something in redis:
- getLock -> tryLock
- getBucket -> setIfAbsent
Performance of those two is drastically different:80ms for fist option and5ms for the second option. Documentation is saying that option 2 is discouraged.
What's the difference? Is it safe to use option 2 for my use case?
1 Answer1
Yeah, that performance gap is normal.getLock().tryLock() does a lot more under the hood, it’s Redisson’s full distributed lock with renewals, pub/sub, and safety across nodes. That’s why it’s slower.
getBucket().setIfAbsent() is just a rawSETNX, super fast but with no recovery if your service dies or the lock key isn’t cleaned up. In a cross-region setup, that can lead to stale locks or both sides thinking they’ve acquired it.
So, unless you’re okay with occasional duplicates or race conditions, stick withgetLock(). It’s slower because it’s actually doing the right thing in distributed mode.
2 Comments
Explore related questions
See similar questions with these tags.