掌握分布式事務(wù)鎖，這個(gè)大廠實(shí)戰(zhàn)訂單鎖你一定要會(huì)

在成都做網(wǎng)站、成都網(wǎng)站建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)過程中，需要針對(duì)客戶的行業(yè)特點(diǎn)、產(chǎn)品特性、目標(biāo)受眾和市場(chǎng)情況進(jìn)行定位分析，以確定網(wǎng)站的風(fēng)格、色彩、版式、交互等方面的設(shè)計(jì)方向。成都創(chuàng)新互聯(lián)還需要根據(jù)客戶的需求進(jìn)行功能模塊的開發(fā)和設(shè)計(jì)，包括內(nèi)容管理、前臺(tái)展示、用戶權(quán)限管理、數(shù)據(jù)統(tǒng)計(jì)和安全保護(hù)等功能。

分布式趨勢(shì)

目前幾乎很多大型網(wǎng)站及應(yīng)用都是分布式部署的，分布式場(chǎng)景中我們也都會(huì)遇到一個(gè)非常重要的問題：數(shù)據(jù)一致性。正如分布式的CAP理論說的一樣：“任何一個(gè)分布式系統(tǒng)都無法同時(shí)滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯(cuò)性（Partition tolerance），最多只能同時(shí)滿足兩項(xiàng)。”所以，很多系統(tǒng)在設(shè)計(jì)之初就要對(duì)這三者進(jìn)行取舍。在互聯(lián)網(wǎng)領(lǐng)域的絕大多數(shù)的場(chǎng)景中，都需要犧牲強(qiáng)一致性來換取系統(tǒng)的高可用性，系統(tǒng)往往只需要保證“最終一致性”，只要這個(gè)最終時(shí)間是在用戶可以接受的范圍內(nèi)即可。

在很多場(chǎng)景中，我們?yōu)榱吮ＷC數(shù)據(jù)的最終一致性，需要很多的技術(shù)方案來支撐，比如分布式事務(wù)、分布式鎖、定時(shí)任務(wù)調(diào)度等。盡管Java提供了很多并發(fā)處理API，但這些API在分布式場(chǎng)景中就顯得無能為力了。

所以針對(duì)分布式鎖的實(shí)現(xiàn)我們需要借助別的工具，目前比較常用的有以下幾種方案：

1. 基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖
2. 基于緩存（redis，memcached，tair）實(shí)現(xiàn)分布式鎖
3. 基于Zookeeper實(shí)現(xiàn)分布式鎖

本篇發(fā)文我們主要說下基于Redis的分布式鎖實(shí)戰(zhàn)。

實(shí)際編寫代碼之前，我們說下首要條件

分布式鎖可用的四個(gè)條件：

1. 互斥性。在任意時(shí)刻，只有一個(gè)客戶端能持有鎖。
2. 不會(huì)發(fā)生死鎖。即使有一個(gè)客戶端在持有鎖的期間崩潰而沒有主動(dòng)解鎖，也能保證后續(xù)其他客戶端能加鎖。
3. 具有容錯(cuò)性。只要大部分的Redis節(jié)點(diǎn)正常運(yùn)行，客戶端就可以加鎖和解鎖。
4. 解鈴還須系鈴人。加鎖和解鎖必須是同一個(gè)客戶端，客戶端自己不能把別人加的鎖給解了。

分布式鎖實(shí)戰(zhàn)步驟：

編寫ILock接口

編寫ILock接口實(shí)現(xiàn)

LockGetter抽象類

從圖示我們可以看出，通過LockGetter抽象類進(jìn)行具體的加鎖成功或則失敗的具體業(yè)務(wù)走向。這一個(gè)思想同學(xué)們要謹(jǐn)記于心。能夠熟練應(yīng)用的話，他會(huì)使你在編程之路上走的更加順暢。

此外，可以看到，我們實(shí)際加鎖就一行代碼：jedis.set(fieldKey, value, "NX", "EX", seconds);，這個(gè)set()方法一共有五個(gè)形參：

第一個(gè)參數(shù)為key，我們使用key來當(dāng)鎖，因?yàn)閗ey是唯一的。

第二個(gè)參數(shù)為value，我們傳的是requestId，很多童鞋可能不明白，有key作為鎖不就夠了嗎，為什么還要用到value？原因就是我們?cè)谏厦嬷v到可靠性時(shí)，分布式鎖要滿足第四個(gè)條件解鈴還須系鈴人，通過給value賦值為requestId，我們就知道這把鎖是哪個(gè)請(qǐng)求加的了，在解鎖的時(shí)候就可以有依據(jù)。requestId可以使用UUID.randomUUID().toString()方法生成。

第三個(gè)參數(shù)為nxxx，這個(gè)參數(shù)我們填的是NX，意思是SET IF NOT EXIST，即當(dāng)key不存在時(shí)，我們進(jìn)行set操作；若key已經(jīng)存在，則不做任何操作；

第四個(gè)參數(shù)為expx，這個(gè)參數(shù)我們傳的是PX，意思是我們要給這個(gè)key加一個(gè)過期的設(shè)置，具體時(shí)間由第五個(gè)參數(shù)決定。

第五個(gè)參數(shù)為time，與第四個(gè)參數(shù)相呼應(yīng)，代表key的過期時(shí)間。

總的來說，執(zhí)行上面的set()方法之后會(huì)出現(xiàn)兩種情況：

1. 當(dāng)前沒有鎖（key不存在），那么就進(jìn)行加鎖操作，并對(duì)鎖設(shè)置個(gè)有效期，同時(shí)value表示加鎖的客戶端。
2. 鎖已經(jīng)存在，redis不做任何操作。

總結(jié)：

使用緩存來實(shí)現(xiàn)分布式鎖優(yōu)點(diǎn)：

1. 可以提供更好的性能，同時(shí)很多緩存服務(wù)都是集群部署的，可以避免單點(diǎn)問題。
2. 很多緩存服務(wù)都提供了可以用來實(shí)現(xiàn)分布式鎖的方法，比如redis的setnx方法等。
3. 緩存服務(wù)也都提供了對(duì)數(shù)據(jù)的過期自動(dòng)刪除的支持，可以直接設(shè)置超時(shí)時(shí)間來控制鎖的釋放。

使用緩存實(shí)現(xiàn)分布式鎖盡管性能好，實(shí)現(xiàn)起來較為方便。但也不是沒有缺點(diǎn)，有時(shí)候我們的程序內(nèi)部出現(xiàn)異常后可能會(huì)發(fā)生死鎖，這就需要開發(fā)時(shí)候注意代碼編寫，后續(xù)測(cè)試人員測(cè)試時(shí)候測(cè)試案例要盡可能覆蓋。

網(wǎng)頁題目：掌握分布式事務(wù)鎖，這個(gè)大廠實(shí)戰(zhàn)訂單鎖你一定要會(huì)
文章鏈接：http://muchs.cn/article34/jpdipe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動(dòng)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)公司、域名注冊(cè)、動(dòng)態(tài)網(wǎng)站、網(wǎng)站制作、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)