redis分布式鎖--003(鎖沖突處理)

鎖沖突處理

上節課我們講了分布式鎖的問題,但是沒有提到客戶端在處理請求時加鎖沒加成功怎么辦。一般有 3 種策略來處理加鎖失敗:
1、直接拋出異常,通知用戶稍后重試;
2、sleep 一會再重試;
3、將請求轉移至延時隊列,過一會再試;

直接拋出特定類型的異常

這種方式比較適合由用戶直接發起的請求,用戶看到錯誤對話框后,會先閱讀對話框的內容,再點擊重試,這樣就可以起到人工延時的效果。如果考慮到用戶體驗,可以由前端的代碼替代用戶自己來進行延時重試控制。它本質上是對當前請求的放棄,由用戶決定是否重新發起新的請。

sleep

sleep 會阻塞當前的消息處理線程,會導致隊列的后續消息處理出現延遲。如果碰撞的比較頻繁或者隊列里消息比較多,sleep 可能并不合適。如果因為個別死鎖的 key 導致加鎖不成功,線程會徹底堵死,導致后續消息永遠得不到及時處理。

延時隊列

這種方式比較適合異步消息處理,將當前沖突的請求扔到另一個隊列延后處理以避開沖突。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。