前幾天看到一篇distributed lock的中文文章[1]，細看發現是很久以前就有討論的，有關redis用於lock的討論[2]。

dist-lock的應用類型

• effciency: lock失效可能導致某些工作被執行多次
• correctness: lock失效可能導致系統混亂或錯誤

對於effciency，lock失效不會帶來太大的問題，所以可議的部分在於correctness。

甚麼時候鎖會失效

假設我們想透過鎖保護某項資源的存取，如果使用lock，可能在很多地方隱藏著fail：

• process paused
  • GC
  • signal
• networking
  • 503, 403, 500… whatever
  • TCP/IP delay可能長達數分鐘
• disk IO
  • 不知道disk實際上到底是什麼，可能blocking很久

結論是根本無法確保執行的順序(不同client間)

如何解決：

給每個request一個increse only access token。

為什麼redis不適合

redlock根據”時間”的假設來設計演算法，而時間是不可靠的，因為有delay，而且無法預估。

他假設

• bounded networking latency
• bounded process pause time
• bounded clock error

選用其他更穩健的consensus algo: raft, zab, paxos。

[1] http://lday.me/2018/11/18/0022_how_to_do_distributed_lock/ [2] https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html