distributed lock

• problems
  • race condition on shared resource
  • data inconsistency
• solutions
  • database locking
  • zookeeper locking
  • redis locking

redis locking - best effort basis lock

• redis runs all commands in single thread, no risk of 2 commands run concurrently
• use SETNX to acquire lock (only set if not exist) and DEL to release lock. lock MUST include time-to-live
• the lock is approximate, and only be used for non-critical purposes link
• if client holding the lock stops working, and resumes after lock is released (due to time-to-live) -> system can end up with corrupted data
• use delaying restart of crashed nodes link for at least the longest ttl of locks
• 

redis lock with fencing token

• every write requires a fencing token (increasing number) when acquiring lock (but require token service generates strictly motonotically increasing tokens -> zookeeper) -> write with old token is rejected
• 

zookeeper/etcd - correctness lock

• keep data consistent across most of servers (through quorum)
• strong consistency but heavier computation compared to redis