Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/alexandrelamarre/dlock
Reliable & scalable distributed locking, scheduling and process synchronization
https://github.com/alexandrelamarre/dlock
api consensus distributed-lock distrubted-systems grpc lock process-synchronization
Last synced: about 2 months ago
JSON representation
Reliable & scalable distributed locking, scheduling and process synchronization
- Host: GitHub
- URL: https://github.com/alexandrelamarre/dlock
- Owner: alexandreLamarre
- License: apache-2.0
- Created: 2024-01-25T20:29:27.000Z (11 months ago)
- Default Branch: main
- Last Pushed: 2024-11-07T04:41:00.000Z (about 2 months ago)
- Last Synced: 2024-11-07T05:28:53.403Z (about 2 months ago)
- Topics: api, consensus, distributed-lock, distrubted-systems, grpc, lock, process-synchronization
- Language: Go
- Homepage:
- Size: 404 KB
- Stars: 3
- Watchers: 2
- Forks: 0
- Open Issues: 5
-
Metadata Files:
- Readme: README.md
- Funding: .github/FUNDING.yml
- License: LICENSE
Awesome Lists containing this project
README
# Dlock
[](./LICENSE)
Dlock is a server for distributed locking for process synchronization & exclusive transactions in distributed systems.
Generally, a distributed lock can be used to coordinate access to a resource or interest in
such a resource in a distributed environment. In other words, distributed locks are useful when multiple systems need to reach a consensus about a shared resource.
## Lock Modes
As apposed to standard single-host locking mechanisms, distributed locks can be categorized into distinct modes with varying degress of distributed access guarantees.
- Null (NL) : indicates interest in the resource, but does not prevent other process from locking it
- Concurrent Read (CR) : Indicates a desire to read (but not update) the resources. Allows other processes to read or update the resource but prevents exclusive access to it.
- Concurrent Write (CW) : Indicates a desire to read and update the resource. It allows other processes to read or update the resource, but prevents others from having EX access to it.
- Protected Read (PR) : Traditional share lock, which indicates a desire to read the resource but prevents others from updating it. Others can however also read the resource.
- Protected Write (PW) : Traditional update lock, indicates a desire to read and update the resource and prevents others from updating it. Others with Concurrent read access can however read the resource
- Exclusive (EX) : Traditional exclusive lock, which allows read and update access to the resource, and prevents others from having access to it.
Mode
NL
CR
CW
PR
PW
EX
NL
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:
CR
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:white_check_mark:
:x:
CW
:white_check_mark:
:white_check_mark:
:white_check_mark:
:x:
:x:
:x:
PR
:white_check_mark:
:white_check_mark:
:x:
:white_check_mark:
:x:
:x:
PW
:white_check_mark:
:white_check_mark:
:x:
:x:
:x:
:x:
EX
:white_check_mark:
:x:
:x:
:x:
:x:
:x:
### Notes
- A typical mutex corresponds one-to-one with a distributed exclusive lock (EX).
- There is no one-to-one mapping for a RW mutex in a distributed setting, although Protected Read & Write locks correspond closely to many of a RW mutexe's guarantees
## Support Matrix
| Backend / Lock Type | EX | PW | PR | CW | CR | NL |
| :-------------------------------------------------------: | :----------------: | :-: | :-: | :-: | :-: | :-: |
| [Jetstream](https://docs.nats.io/nats-concepts/jetstream) | :white_check_mark: | :x: | :x: | :x: | :x: | :x: |
| [Etcd ](https://etcd.io/) | :white_check_mark: | :x: | :x: | :x: | :x: | :x: |
| [Redis ](https://redis.io/) | :white_check_mark: | :x: | :x: | :x: | :x: | :x: |
## Dlock specific guarantees
### Exclusive Locks (EX)
- **Liveliness A** : A lock is always eventually released when the process holding it crashes or exits unexpectedly.
- **Liveliness B** : A lock is always eventually released when its backend store is unavailable.
- **Atomicity A** : No two processes or threads can hold the same lock at the same time.
- **Atomicity B** : Any call to unlock will always eventually release the lock
## References
- [Distributed Lock Manager](https://en.wikipedia.org/wiki/Distributed_lock_manager). (n.d.). In Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Distributed_lock_manager
- Kleppmann, Martin. "Designing Data-Intensive Applications." (2019).
- [Redis redlock algorithm](https://redis.io/docs/manual/patterns/distributed-locks/) from https://redis.io/docs/manual/patterns/distributed-locks/