前言
最近在參加學校安排的實訓任務，我們小組需完成一套分布式&微服務跨境電商，雖然這題目看起來有點老套，并且隊友多是 Java 技術棧，所以我光榮（被迫）
的成為了一名前端，并順路使用 PHP 的 Swoole 幫助負責服務器端的同學編寫了幾個微服務模塊。在小組成員之間的協作中，還是出現了不少有趣的火花。
在昨天 review 隊友代碼的過程中，發現了我們組分布式鎖的寫法似乎有點問題，實現代碼如下：
加鎖部分
解鎖部分
主要原理是使用了 redis 的 setnx 去插入一組 key-value，其中 key 要上鎖的標識（在項目中是鎖死用戶 userId），如果上鎖失敗則返回 false。但是根據二段鎖的思路，仔細思考會存在這么一個有趣的現象：
假設微服務 A 的某個請求對 userId = 7 的用戶上鎖，則微服務 A 的這個請求可以讀取這個用戶的信息，且可以修改其內容 ；其他模塊只能讀取這個用戶的信息，無法修改其內容。
假設微服務 A 的當前請求對 userId = 7 的用戶解鎖，則所有模塊可以讀取這個用戶的信息，且可以修改其內容
如此一來：
很明顯，這三點并不是我們所希望的。那么如何實現分布式鎖才是最佳實踐吶？
一個好的分布式鎖需要實現什么
我們應該怎么做
綜上所述，我們小組的分布式鎖在實現模塊互斥的情況下，忽略的一個重要問題便是“請求互斥”。我們只需要在加鎖時，key-value 的值保存為當前請求的 requestId ，解鎖時加多一次判斷，是否為同一請求即可。
那么這么修改之后，我們可以高枕無憂了嗎?
是的，夠用了。因為我們開發環境 Redis 是統一用一臺服務器上的單例，采用上述方式實現的分布式鎖并沒有什么問題，但在準備部署到生產環境下時，突然意識到一個問題：如果實現主從讀寫分離，redis 多機主從同步數據時，采用的是異步復制，也便是一個“寫”操作到我們的 reids 主庫之后，便馬上返回成功（并不會等到同步到從庫后再返回，如果這種是同步完成后再返回便是同步復制），這將會造成一個問題：
假設我們的模塊 A中 id=1 的請求上鎖成功后，沒同步到從庫前主庫被我們玩壞了（宕機），則 redis 哨兵將會從從庫中選擇出一臺新的主庫，此時若模塊 A 中 id=2 的請求重新請求加鎖，將會是成功的。
技不如人，我們只能借助搜索引擎劃水了（大霧），發現這種情況還真的有通用的解決方案：redlock。
怎么實現 Redlock 分布式安全鎖
首先 redlock 是 redis 官方文檔推薦的實現方式，本身并沒有用到主從層面的架構，采用的是多態主庫，依次去取鎖的方式。假設這里有 5 臺主庫，整體流程大致如下：
加鎖
解鎖
直接向 5 臺服務器發起請求即可，無論這臺服務器上是不是已經有鎖。
整體思路很簡單，但是實現起來仍有許多值得注意的地方。在向這 5 臺服務器發送加鎖請求時，由于會帶上一個過期時間以保證上文所提到的“自動解鎖(容錯性) ”，考慮到延時等原因，這 5 臺機自動解鎖的時間不完全相同，因此存在一個加
鎖時間差的問題，一般而言是這么解決的：