一 前言

redis在分布式應(yīng)用十分廣泛，本篇文章也是互聯(lián)網(wǎng)面試的重點(diǎn)內(nèi)容，讀者至少需要知道為什么需要分布式鎖，分布式鎖的實(shí)現(xiàn)原理，分布式鎖的應(yīng)用場(chǎng)景，在使用分布式鎖時(shí)遇到哪些問題?你是如何解決的，如果讀者能掌握以上問題，那么關(guān)于這道面試題，你也就基本過關(guān)了；

二 分布式鎖的產(chǎn)生背景

分布式鎖對(duì)應(yīng)的是多個(gè)應(yīng)用，每個(gè)應(yīng)用中都可能會(huì)處理相同的數(shù)據(jù)，如果多個(gè)應(yīng)用對(duì)用一個(gè)操作進(jìn)行了重復(fù)操作，就會(huì)出現(xiàn)數(shù)據(jù)不一致，數(shù)據(jù)重復(fù)問題，于是分布式鎖應(yīng)用而生，通常你可以理解為多線程中的synchronized

三 分布式鎖的應(yīng)用場(chǎng)景

多臺(tái)機(jī)器都能執(zhí)行某個(gè)任務(wù)，如果限制任務(wù)每次只能被一臺(tái)機(jī)器執(zhí)行，不能重復(fù)執(zhí)行，就可以用分布式鎖來做標(biāo)記秒殺場(chǎng)景，要求并發(fā)量很高，那么同一件商品只能被一個(gè)用戶搶到，就可以使用分布式鎖實(shí)現(xiàn)比較敏感的數(shù)據(jù)比如金額修改，同一時(shí)間只能有一個(gè)人操作，如果2個(gè)人同時(shí)修改金額，一個(gè)加一個(gè)減金額，為了防止同時(shí)操作造成數(shù)據(jù)不一致，就可以使用分布式鎖實(shí)現(xiàn)

四 分布式鎖的實(shí)現(xiàn)

4.1 分布式鎖的實(shí)現(xiàn)方式

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

4.2 分布式鎖使用原理

每個(gè)應(yīng)用對(duì)敏感數(shù)據(jù)進(jìn)行操作時(shí)都需要向獲取一個(gè)鎖，持有鎖的應(yīng)用才能對(duì)數(shù)據(jù)進(jìn)行操作，保證在同一時(shí)間內(nèi)只有一臺(tái)應(yīng)用能對(duì)數(shù)據(jù)進(jìn)行操作；

4.3 分布式鎖實(shí)現(xiàn)過程

基本實(shí)現(xiàn)思路：

redis分布式實(shí)現(xiàn)是基于 命令setnx key value ， 其意指 若該鍵不存在則創(chuàng)建鍵，這就保證了redis中只有一個(gè)該鍵，故應(yīng)用誰先獲得該鍵，誰就拿到了鎖的權(quán)限；然后業(yè)務(wù)邏輯執(zhí)行完畢則需要使用 del key 刪除鍵，表示釋放鎖；

出現(xiàn)了問題：

如果一臺(tái)業(yè)務(wù)邏輯執(zhí)行完畢，程序出現(xiàn)異常，則鎖會(huì)一直存在，沒有得到釋放，其它應(yīng)用就會(huì)無法獲得鎖，此時(shí)就會(huì)造成死鎖問題；

改進(jìn)方式：

拿到鎖之后，給鎖加上一個(gè)過期時(shí)間，也就是 expire key seconds 指令；此時(shí)避免了死鎖問題，但是由于業(yè)務(wù)邏輯執(zhí)行的時(shí)間不同，過期的時(shí)間設(shè)置也是一個(gè)問題，故通常分布式鎖不能應(yīng)用于業(yè)務(wù)邏輯執(zhí)行較長(zhǎng)的程序；

出現(xiàn)問題：

由于redis 每條指令都是原子性操作，但由于setnx 和 expire 是2 條指令，如果在執(zhí)行setnx后程序出現(xiàn)問題expire指令未得到執(zhí)行就會(huì)造成死鎖問題；

解決問題：

redis2.8版本之后引入了指令 set key value [EX seconds] [PX milliseconds] [NX|XX] ,該指令可以同時(shí)執(zhí)行 setnx 和 expire ，于是解決了死鎖問題；

參數(shù)列表解釋

• EX seconds: 設(shè)定過期時(shí)間，單位為秒
• PX milliseconds: 設(shè)定過期時(shí)間，單位為毫秒
• NX: key不存在時(shí)設(shè)置值
• XX: key存在時(shí)設(shè)置值
  

使用jedis客戶端實(shí)現(xiàn)分布式鎖方式

public boolean lock(Jedis jedis,String key,String val,int expireTime){
  String lock = jedis.set(key, val, "NX", "PX",
      expireTime);
  return "OK".equals(lock);
}

關(guān)于未獲得鎖的解決思路：

可以直接拋出異常讓客戶重試

可以使用延遲隊(duì)列

五 分布式鎖的超時(shí)問題

問題：

如果在加鎖和釋放鎖之間，業(yè)務(wù)邏輯執(zhí)行時(shí)間太長(zhǎng)，導(dǎo)致超出了鎖的超時(shí)限制，就會(huì)出現(xiàn)鎖過期問題；換句話說，就是第一臺(tái)應(yīng)用執(zhí)行了業(yè)務(wù)，導(dǎo)致鎖過期；第二臺(tái)應(yīng)用此時(shí)可以獲得鎖，進(jìn)行執(zhí)行業(yè)務(wù)，此時(shí)第一臺(tái)應(yīng)用釋放了鎖，第二臺(tái)應(yīng)用在執(zhí)行業(yè)務(wù)的時(shí)第三臺(tái)應(yīng)用獲得了鎖執(zhí)行業(yè)務(wù)，導(dǎo)致在執(zhí)行過程中，會(huì)有2臺(tái)應(yīng)用在同時(shí)執(zhí)行業(yè)務(wù)邏輯；

解決思路：

在釋放鎖的時(shí)候出現(xiàn)了問題，即每臺(tái)應(yīng)用都可以釋放鎖，這會(huì)造成1應(yīng)用的鎖釋放了2應(yīng)用鎖的問題，換句話說，很多人手中持有的鑰匙是通用的，都可以開同一個(gè)門；為了避免這個(gè)問題，就是1 應(yīng)用只能釋放1應(yīng)用上的鎖，2應(yīng)用只能釋放2應(yīng)用上的鎖，則需要對(duì)釋放鎖進(jìn)行身份校驗(yàn)；由于上鎖的時(shí)候key是唯一，但value可以不同，所以可以根據(jù)value進(jìn)行身份的唯一標(biāo)識(shí)，隨機(jī)數(shù)就是一個(gè)很好的選擇 ：

String value = UUID.randomUUID().toString();

由于考慮到匹配到value校驗(yàn)和del不是同一個(gè)操作，故需要使用Lua腳本實(shí)現(xiàn)多條指令的原子性執(zhí)行；

jedis釋放鎖實(shí)現(xiàn)方式：

public void unlock(Jedis jedis,String key,String value) {
    String script_command = "if redis.call('get',KEYS[1]) == ARGV[1] then " +
        "return redis.call('del',KEYS[1]) else return 0 end";
    // 解鎖
    jedis.eval(script_command, Collections.singletonList(key), Collections.singletonList(value));
    
  }

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論