himadieievsv / redpulsar Goto Github PK

Summary
It nice to have ListenerLock in oppose to polling locks.
Basic requirements:

1. Utilizing Pub/Sub mechanism
2. Still should try to lock with by sending lock call to backend first and then listen for unlock event.

Motivation
Reduce calls to backend attempting to lock resource

Summary
Load LUA script prior to commands execution on Redis.
Initialization can be done when object created once per application.

Motivation
All Redis backends are sending LUA scripts as is. Those calls ending up with slitty bigger size.
Reduce that redundancy with using script hash to call it.

Caveats

• Tracking what Redis instances already has scripts might be challenging if cluster topology changes or individual instance get restarted/replaced.

Summary
It nice to have FairLock.
Basic requirements:

1. Polling mechanism to obtain lock
2. First client who tried to lock resource should be able to lock resource after its unlock

Motivation
FairLock is attempt to have fairness in lock obtaining racing, if client first requested lock it should be able obtain lock as soon as lock is available.

Summary
It nice to have Leader election algorithm too.
Basic requirements:
TBD

Motivation
Currently it is possible to have only one node in luster to perform workload using locks, but it have many drawbacks for using that approach in cluster with different types of nodes (computing power, network bandwidth, memory capacity, etc ). Ideally nodes should vote on the best candidate.

Workaround
Use locks

multiInstanceExecute can get result properly with strategy waitForMajority.
There are multiple unit tests failures due to that