建站
咨詢
售后
建站咨詢
新聞中心
創(chuàng)新互聯(lián)www.cdcxhl.cn八線動(dòng)態(tài)BGP香港云服務(wù)器提供商，新人活動(dòng)買多久送多久，劃算不套路！
這篇文章將為大家詳細(xì)講解有關(guān)SpringBoot整合Redis實(shí)現(xiàn)分布式鎖的方法，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。
前言
最近在做分塊上傳的業(yè)務(wù)，使用到了Redis來維護(hù)上傳過程中的分塊編號(hào)。
每上傳完成一個(gè)分塊就獲取一下文件的分塊集合，加入新上傳的編號(hào)，手動(dòng)接口測試下是沒有問題的，前端通過并發(fā)上傳調(diào)用就出現(xiàn)問題了，并發(fā)的get再set，就會(huì)存在覆蓋寫現(xiàn)象，導(dǎo)致最后的分塊數(shù)據(jù)不對(duì)，不能觸發(fā)分塊合并請(qǐng)求。
遇到并發(fā)二話不說先上鎖，針對(duì)執(zhí)行代碼塊加了一個(gè)JVM鎖之后問題就解決了。
仔細(xì)一想還是不太對(duì)，項(xiàng)目是分布式部署的，做了負(fù)載均衡，一個(gè)節(jié)點(diǎn)的代碼被鎖住了，請(qǐng)求輪詢到其他節(jié)點(diǎn)還是可以進(jìn)行覆蓋寫，并沒有解決到問題啊
沒辦法，只有用上分布式鎖了。之前對(duì)于分布式鎖的理論還是很熟悉的，沒有比較好的應(yīng)用場景就沒寫過具體代碼，趁這個(gè)機(jī)會(huì)就學(xué)習(xí)使用一下分布式鎖。
理論
分布式鎖是控制分布式系統(tǒng)之間同步訪問共享資源的一種方式。是為了解決分布式系統(tǒng)中，不同的系統(tǒng)或是同一個(gè)系統(tǒng)的不同主機(jī)共享同一個(gè)資源的問題，它通常會(huì)采用互斥來保證程序的一致性
通常的實(shí)現(xiàn)方式有三種：
- 基于 MySQL 的悲觀鎖來實(shí)現(xiàn)分布式鎖，這種方式使用的最少，這種實(shí)現(xiàn)方式的性能不好，且容易造成死鎖，并且MySQL本來業(yè)務(wù)壓力就很大了，再做鎖也不太合適
- 基于 Redis 實(shí)現(xiàn)分布式鎖，單機(jī)版可用setnx實(shí)現(xiàn)，多機(jī)版建議用Radission
- 基于 ZooKeeper 實(shí)現(xiàn)分布式鎖，利用 ZooKeeper 順序臨時(shí)節(jié)點(diǎn)來實(shí)現(xiàn)
為了確保分布式鎖可用，我們至少要確保鎖的實(shí)現(xiàn)同時(shí)滿足以下四個(gè)條件：
- 互斥性。在任意時(shí)刻，只有一個(gè)客戶端能持有鎖。
- 不會(huì)發(fā)生死鎖。即使有一個(gè)客戶端在持有鎖的期間崩潰而沒有主動(dòng)解鎖，也能保證后續(xù)其他客戶端能加鎖。
- 具有容錯(cuò)性。只要大部分的Redis節(jié)點(diǎn)正常運(yùn)行，客戶端就可以加鎖和解鎖。
- 解鈴還須系鈴人。加鎖和解鎖必須是同一個(gè)客戶端，客戶端自己不能把別人加的鎖給解了。
本文就使用的是Redis的setnx實(shí)現(xiàn)，如果Redis是多機(jī)版的可以去了解下Radssion，封裝的就特別的好，也是官方推薦的
代碼
1. 加依賴
引入Spring Boot和Redis整合的快速使用依賴
org.springframework.boot spring-boot-starter-data-redis
當(dāng)前文章：SpringBoot整合Redis實(shí)現(xiàn)分布式鎖的方法-創(chuàng)新互聯(lián)
標(biāo)題來源：http://www.dlmjj.cn/article/dpphed.html
