distributed lock

2018/12/04 共 706 字,約 3 分鐘

前幾天看到一篇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

文章訊息

Search

    Table of Contents