Differences

This shows you the differences between two versions of the page.

--- distributed_computing:locks [2017/09/09 13:34] – angelegt phreazer
+++ distributed_computing:locks [2017/09/09 14:30] (current) – phreazer
@@ Line 3: / Line 3: @@
 Locks, mutexes, semaphores, monitors are usually associated with concurrent programming. But exclusive resource access is also needed in distributed environments, e.g. when using a micro-service architecture.
+====== Locking service ======
+When having multiple instances of a service, it needs to be ensured that the action is performed only by one instance.
+A leader will be elected, and failure needs to be detected and dealt with. Consensus algorithm like Paxos exist.
+A separate locking service could be build, which is able to manage locks. The service needs a strongly consistent datastore, which holds information about the lock (who holds it, how long) and there needs to be logic to deal with failures.
+====== Implementations ======
+  * Distributed locking with Zoo-Keeper: https://dzone.com/articles/distributed-lock-using
+  * Hashicorp Consul: https://www.consul.io/docs/guides/semaphore.html
+  * Google Chubby
+  * Distributed locks with Redis: https://redis.io/topics/distlock
+    * Not recommended when lock should be used for guarantee correctness (http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html)
+  * Relational database
+    * Fencing tokens
+    * Linearizable writes
+      * Writes should appear to be instantaneous. Once a write completes, all later reads should return the value of that write or the value of a later write. Once a read returns a particular value, all later reads should return that value or the value of a later write.