現在學習分散式鎖還來得及嗎？

小江音樂MV2019-06-16 22:10:14

來得及，學無止境！

多執行緒情況下對共享資源的操作需要加鎖，避免資料被寫亂，在分散式系統中，這個問題也是存在的，此時就需要一個分散式鎖服務。常見的分散式鎖實現一般是基於DB、Redis、zookeeper。下面筆者會按照順序分析下這3種分散式鎖的設計與實現，想直接看分散式鎖總結的小夥伴可直接翻到文件末尾處。分散式鎖的實現由多種方式，但是不管怎樣，分散式鎖一般要有以下特點：排他性：任意時刻，只能有一個client能獲取到鎖容錯性：分散式鎖服務一般要滿足AP，也就是說，只要分散式鎖服務叢集節點大部分存活，client就可以進行加鎖解鎖操作避免死鎖：分散式鎖一定能得到釋放，即使client在釋放之前崩潰或者網路不可達除了以上特點之外，分散式鎖最好也能滿足可重入、高效能、阻塞鎖特性（AQS這種，能夠及時從阻塞狀態喚醒）等，下面就話不多說，趕緊上（開往分散式鎖的設計與實現的）車~DB鎖在資料庫新建一張表用於控制併發控制，表結構可以如下所示：CREATE TABLE `lock_table` （ `id` int（11） unsigned NOT NULL COMMENT ‘主鍵’， `key_id` bigint（20） NOT NULL COMMENT ‘分散式key’， `memo` varchar（43） NOT NULL DEFAULT ‘’ COMMENT ‘可記錄操作內容’， `update_time` datetime NOT NULL COMMENT ‘更新時間’， PRIMARY KEY （`id`，`key_id`）， UNIQUE KEY `key_id` （`key_id`） USING BTREE） ENGINE=InnoDB DEFAULT CHARSET=utf8；key_id作為分散式key用來併發控制，memo可用來記錄一些操作內容（比如memo可用來支援重入特性，標記下當前加鎖的client和加鎖次數）。將key_id設定為唯一索引，保證了針對同一個key_id只有一個加鎖（資料插入）能成功。此時lock和unlock虛擬碼如下：def lock ： exec sql： insert into lock_table（key_id， memo， update_time） values （key_id， memo， NOW（）） if result == true ： return true else ： return falsedef unlock ： exec sql： delete from lock_table where key_id = ‘key_id’ and memo = ‘memo’注意，虛擬碼中的lock操作是非阻塞鎖，也就是tryLock，如果想實現阻塞（或者阻塞超時）加鎖，只修反覆執行lock虛擬碼直到加鎖成功為止即可。基於DB的分散式鎖其實有一個問題，那就是如果加鎖成功後，client端宕機或者由於網路原因導致沒有解鎖，那麼其他client就無法對該key_id進行加鎖並且無法釋放了。為了能夠讓鎖失效，需要在應用層加上定時任務，去刪除過期還未解鎖的記錄，比如刪除2分鐘前未解鎖的虛擬碼如下：def clear_timeout_lock ： exec sql ： delete from lock_table where update_time < ADDTIME（NOW（），‘-00：02：00’）因為單例項DB的TPS一般為幾百，所以基於DB的分散式效能上限一般也是1k以下，一般在併發量不大的場景下該分散式鎖是滿足需求的，不會出現效能問題。不過DB作為分散式鎖服務需要考慮單點問題，對於分散式系統來說是不允許出現單點的，一般透過資料庫的同步複製，以及使用vip切換Master就能解決這個問題。以上DB分散式鎖是透過insert來實現的，如果加鎖的資料已經在資料庫中存在，那麼用select xxx where key_id = xxx for udpate方式來做也是可以的。順便在此給大家推薦一個Java架構方面的交流學習群：698581634，進群即可免費獲取Java架構學習資料：裡面有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能最佳化這些成為架構師必備的知識體系，群裡一定有你需要的資料，大家趕緊加群吧。Redis鎖Redis鎖是透過以下命令對資源進行加鎖：set key_id key_value NX PX expireTime其中，set nx命令只會在key不存在時給key進行賦值，px用來設定key過期時間，key_value一般是隨機值，用來保證釋放鎖的安全性（釋放時會判斷是否是之前設定過的隨機值，只有是才釋放鎖）。由於資源設定了過期時間，一定時間後鎖會自動釋放。set nx保證併發加鎖時只有一個client能設定成功（Redis內部是單執行緒，並且資料存在記憶體中，也就是說redis內部執行命令是不會有多執行緒同步問題的），此時的lock/unlock虛擬碼如下：def lock： if （redis。call（‘set’， KEYS［1］， ARGV［1］， ‘ex’， ARGV［2］， ‘nx’）） then return true end return falsedef unlock： if （redis。call（‘get’， KEYS［1］） == ARGV［1］） then redis。call（‘del’， KEYS［1］） return true end return false分散式鎖服務中的一個問題如果一個獲取到鎖的client因為某種原因導致沒能及時釋放鎖，並且redis因為超時釋放了鎖，另外一個client獲取到了鎖，此時情況如下圖所示：那麼如何解決這個問題呢，一種方案是引入鎖續約機制，也就是獲取鎖之後，釋放鎖之前，會定時進行鎖續約，比如以鎖超時時間的1/3為間隔週期進行鎖續約。關於開源的redis的分散式鎖實現有很多，比較出名的有redisson、百度的dlock，關於分散式鎖，筆者也寫了一個簡易版的分散式鎖redis-lock，主要是增加了鎖續約和可同時針對多個key加鎖的機制。對於高可用性，一般可以透過叢集或者master-slave來解決，redis鎖優勢是效能出色，劣勢就是由於資料在記憶體中，一旦快取服務宕機，鎖資料就丟失了。像redis自帶複製功能，可以對資料可靠性有一定的保證，但是由於複製也是非同步完成的，因此依然可能出現master節點寫入鎖資料而未同步到slave節點的時候宕機，鎖資料丟失問題。順便在此給大家推薦一個Java架構方面的交流學習群：698581634，進群即可免費獲取Java架構學習資料：裡面有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能最佳化這些成為架構師必備的知識體系，群裡一定有你需要的資料，大家趕緊加群吧。zookeeper分散式鎖ZooKeeper是一個高可用的分散式協調服務，由雅虎建立，是Google Chubby的開源實現。ZooKeeper提供了一項基本的服務：分散式鎖服務。zookeeper重要的3個特徵是：zab協議、node儲存模型和watcher機制。透過zab協議保證資料一致性，zookeeper叢集部署保證可用性，node儲存在記憶體中，提高了資料操作效能，使用watcher機制，實現了通知機制（比如加鎖成功的client釋放鎖時可以通知到其他client）。zookeeper node模型支援臨時節點特性，即client寫入的資料時臨時資料，當客戶端宕機時臨時資料會被刪除，這樣就不需要給鎖增加超時釋放機制了。當針對同一個path併發多個建立請求時，只有一個client能建立成功，這個特性用來實現分散式鎖。注意：如果client端沒有宕機，由於網路原因導致zookeeper服務與client心跳失敗，那麼zookeeper也會把臨時資料給刪除掉的，這時如果client還在操作共享資料，是有一定風險的。基於zookeeper實現分散式鎖，相對於基於redis和DB的實現來說，使用上更容易，效率與穩定性較好。curator封裝了對zookeeper的api操作，同時也封裝了一些高階特性，如：Cache事件監聽、選舉、分散式鎖、分散式計數器、分散式Barrier等，使用curator進行分散式加鎖示例如下： org。apache。curator curator-framework 2。12。0 org。apache。curator curator-recipes 2。12。0public static void main（String［］ args） throws Exception { String lockPath = “/curator_recipes_lock_path”； CuratorFramework client = CuratorFrameworkFactory。builder（）。connectString（“192。168。193。128：2181”）。retryPolicy（new ExponentialBackoffRetry（1000， 3））。build（）； client。start（）； InterProcessMutex lock = new InterProcessMutex（client， lockPath）； Runnable task = （） -> { try { lock。acquire（）； try { System。out。println（“zookeeper acquire success： ” + Thread。currentThread（）。getName（））； Thread。sleep（1000）； } catch （Exception e） { e。printStackTrace（）； } finally { lock。release（）； } } catch （Exception ex） { ex。printStackTrace（）； } }； ExecutorService executor = Executors。newFixedThreadPool（10）； for （int i = 0； i < 1000； i++） { executor。execute（task）； } LockSupport。park（）；}總結從上面介紹的3種分散式鎖的設計與實現中，我們可以看出每種實現都有各自的特點，針對潛在的問題有不同的解決方案，歸納如下：效能：redis > zookeeper > db。避免死鎖：DB透過應用層設定定時任務來刪除過期還未釋放的鎖，redis透過設定超時時間來解決，而zookeeper是透過臨時節點來解決。可用性：DB可透過資料庫同步複製，vip切換master來解決，redis可透過叢集或者master-slave方式來解決，zookeeper本身自己是透過zab協議叢集部署來解決的。注意，DB和redis的複製一般都是非同步的，也就是說某些時刻分散式鎖發生故障可能存在資料不一致問題，而zookeeper本身透過zab協議保證叢集內（至少n/2+1個）節點資料一致性。鎖喚醒：DB和redis分散式鎖一般不支援喚醒機制（也可以透過應用層自己做輪詢檢測鎖是否空閒，空閒就喚醒內部加鎖執行緒），zookeeper可透過本身的watcher/notify機制來做。使用分散式鎖，安全性上和多執行緒（同一個程序內）加鎖是沒法比的，可能由於網路原因，分散式鎖服務（因為超時或者認為client掛了）將加鎖資源給刪除了，如果client端繼續操作共享資源，此時是有隱患的。因此，對於分散式鎖，一個是儘量提高分散式鎖服務的可用性，另一個就是要部署同一內網，儘量降低網路問題發生機率。這樣來看，貌似分散式鎖服務不是“完美”的（PS：技術貌似也不好做到十全十美：（），那麼開發人員該如何選擇分散式鎖呢？最好是結合自己的業務實際場景，來選擇不同的分散式鎖實現，一般來說，基於redis的分散式鎖服務應用較多。