併發情況如何實現加鎖來保證數據一致性?

来源:https://www.cnblogs.com/Jcloud/archive/2023/12/05/17876895.html
-Advertisement-
Play Games

單體架構下鎖的實現方案 1. ReentrantLock全局鎖 ReentrantLock(可重入鎖),指的是一個線程再次對已持有的鎖保護的臨界資源時,重入請求將會成功。 簡單的與我們常用的Synchronized進行比較: ReentrantLock Synchronized 鎖實現機制 依賴AQ ...


單體架構下鎖的實現方案

1. ReentrantLock全局鎖

ReentrantLock(可重入鎖),指的是一個線程再次對已持有的鎖保護的臨界資源時,重入請求將會成功。

簡單的與我們常用的Synchronized進行比較:

ReentrantLock Synchronized
鎖實現機制 依賴AQS 監視器模式
靈活性 支持響應超時、中斷、嘗試獲取鎖 不靈活
釋放形式 必須顯示調用unlock()釋放鎖 自動釋放監視器
鎖類型 公平鎖 & 非公平鎖 非公平鎖
條件隊列 可關聯多個條件隊列 關聯一個條件隊列
可重入性 可重入 可重入

AQS機制:如果被請求的共用資源空閑,那麼就當前請求資源的線程設置為有效的工作線程,將共用資源通過CAScompareAndSetState設置為鎖定狀態;如果共用資源被占用,就採用一定的阻塞等待喚醒機制(CLH變體的FIFO雙端隊列)來保證鎖分配。

可重入性:無論是公平鎖還是非公平鎖的情況,加鎖過程會利用一個state值

private volatile int state


  • state值初始化的時候為0,表示沒有任何線程持有鎖
  • 當有線程來請求該鎖時,state值會自增1,同一個線程多次獲取鎖,就會多次+1,這就是可重入的概念
  • 解鎖也是對state值自減1,一直到0,此線程對鎖釋放。
public class LockExample {

    static int count = 0;
    static ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) throws InterruptedException {

        Runnable runnable = new Runnable() {
            @Override
            public void run() {

                try {
                    // 加鎖
                    lock.lock();
                    for (int i = 0; i < 10000; i++) {
                        count++;
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }
                finally {
                    // 解鎖,放在finally子句中,保證鎖的釋放
                    lock.unlock();
                }
            }
        };

        Thread thread1 = new Thread(runnable);
        Thread thread2 = new Thread(runnable);
        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();
        System.out.println("count: " + count);
    }
}

/**
 * 輸出
 * count: 20000
 */


2. Mysql行鎖、樂觀鎖

樂觀鎖即是無鎖思想,一般都是基於CAS思想實現的,而在MySQL中通過version版本號 + CAS無鎖形式實現樂觀鎖;例如T1,T2兩個事務一起併發執行時,當T2事務執行成功提交後,會對version+1,所以T1事務執行的version條件就無法成立了。

對sql語句進行加鎖以及狀態機的操作,也可以避免不同線程同時對count值訪問導致的數據不一致問題。

// 樂觀鎖 + 狀態機
update
    table_name
set
    version = version + 1,
    count = count + 1
where
    id = id AND version = version AND count = [修改前的count值];

// 行鎖 + 狀態機
 update
    table_name
set
    count = count + 1
where
    id = id AND count = [修改前的count值]
for update;


3. 細粒度的ReetrantLock鎖

如果我們直接採用ReentrantLock全局加鎖,那麼這種情況是一條線程獲取到鎖,整個程式全部的線程來到這裡都會阻塞;但是我們在項目裡面想要針對每個用戶在操作的時候實現互斥邏輯,所以我們需要更加細粒度的鎖。

public class LockExample {
    private static Map<String, Lock> lockMap = new ConcurrentHashMap<>();
    
    public static void lock(String userId) {
        // Map中添加細粒度的鎖資源
        lockMap.putIfAbsent(userId, new ReentrantLock());
        // 從容器中拿鎖並實現加鎖
        lockMap.get(userId).lock();
    }
    public static void unlock(String userId) {
        // 先從容器中拿鎖,確保鎖的存在
        Lock locak = lockMap.get(userId);
        // 釋放鎖
        lock.unlock();
    }
}


弊端:如果每一個用戶請求共用資源,就會加鎖一次,後續該用戶就沒有在登錄過平臺,但是鎖對象會一直存在於記憶體中,這等價於發生了記憶體泄漏,所以鎖的超時和淘汰機制機制需要實現。

4. 細粒度的Synchronized全局鎖

上面的加鎖機制使用到了鎖容器ConcurrentHashMap,該容易為了線程安全的情況,多以底層還是會用到Synchronized機制,所以有些情況,使用lockMap需要加上兩層鎖。

那麼我們是不是可以直接使用Synchronized來實現細粒度的鎖機制

public class LockExample {
    public static void syncFunc1(Long accountId) {
        String lock = new String(accountId + "").intern();

        synchronized (lock) {

            System.out.println(Thread.currentThread().getName() + "拿到鎖了");
            // 模擬業務耗時
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            System.out.println(Thread.currentThread().getName() + "釋放鎖了");
        }
    }

    public static void syncFunc2(Long accountId) {
        String lock = new String(accountId + "").intern();

        synchronized (lock) {

            System.out.println(Thread.currentThread().getName() + "拿到鎖了");
            // 模擬業務耗時
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            System.out.println(Thread.currentThread().getName() + "釋放鎖了");
        }
    }

    // 使用 Synchronized 來實現更加細粒度的鎖
    public static void main(String[] args) {
        new Thread(()-> syncFunc1(123456L), "Thread-1").start();
        new Thread(()-> syncFunc2(123456L), "Thread-2").start();
    }
}

/**
 * 列印
 * Thread-1拿到鎖了
 * Thread-1釋放鎖了
 * Thread-2拿到鎖了
 * Thread-2釋放鎖了
 */


  • 從代碼中我們發現實現加鎖的對象其實就是一個與用戶ID相關的一個字元串對象,這裡可能會有疑問,我每一個新的線程進來,new的都是一個新的字元串對象,只不過字元串內容一樣,怎麼能夠保證可以安全的鎖住共用資源呢;
  • 這其實需要歸功於後面的intern()函數的功能;
  • intern()函數用於在運行時將字元串添加到堆空間中的字元串常量池中,如果字元串已經存在,返回字元串常量池中的引用。

分散式架構下鎖的實現方案

核心問題:我們需要找到一個多個進程之間所有線程可見的區域來定義這個互斥量。

一個優秀的分散式鎖的實現方案應該滿足如下幾個特性:

  1. 分散式環境下,可以保證不同進程之間的線程互斥
  2. 同一時刻,同時只允許一條線程成功獲取到鎖資源
  3. 保證互斥量的地方需要保證高可用性
  4. 要保證可以高性能的獲取鎖和釋放鎖
  5. 可以支持同一線程的鎖重入性
  6. 具備合理的阻塞機制,競爭鎖失敗的線程要有相應的處理方案
  7. 支持非阻塞式的獲取鎖。獲取鎖失敗的線程可以直接返回
  8. 具備合理的鎖失效機制,如超時失效等,可以確保避免死鎖情況出現

Redis實現分散式鎖

  • redis屬於中間件,可獨立部署;
  • 對於不同的Java進程來說都是可見的,同時性能也非常可觀
  • 依賴與redis本身提供的指令setnx key value來實現分散式鎖;區別於普通set指令的是只有當key不存在時才會設置成功,key存在時會返回設置失敗

代碼實例:

// 扣庫存介面
@RequestMapping("/minusInventory")
public String minusInventory(Inventory inventory) {
    // 獲取鎖
    String lockKey = "lock-" + inventory.getInventoryId();
    int timeOut = 100;
    Boolean flag = stringRedisTemplate.opsForValue()
            .setIfAbsent(lockKey, "竹子-熊貓",timeOut,TimeUnit.SECONDS);
    // 加上過期時間,可以保證死鎖也會在一定時間內釋放鎖
    stringRedisTemplate.expire(lockKey,timeOut,TimeUnit.SECONDS);
    
    if(!flag){
        // 非阻塞式實現
        return "伺服器繁忙...請稍後重試!!!";
    }
    
    // ----只有獲取鎖成功才能執行下述的減庫存業務----        
    try{
        // 查詢庫存信息
        Inventory inventoryResult =
            inventoryService.selectByPrimaryKey(inventory.getInventoryId());
        
        if (inventoryResult.getShopCount() <= 0) {
            return "庫存不足,請聯繫賣家....";
        }
        
        // 扣減庫存
        inventoryResult.setShopCount(inventoryResult.getShopCount() - 1);
        int n = inventoryService.updateByPrimaryKeySelective(inventoryResult);
    } catch (Exception e) { // 確保業務出現異常也可以釋放鎖,避免死鎖
        // 釋放鎖
        stringRedisTemplate.delete(lockKey);
    }
    
    if (n > 0)
        return "埠-" + port + ",庫存扣減成功!!!";
    return "埠-" + port + ",庫存扣減失敗!!!";
}

作者:竹子愛熊貓
鏈接:https://juejin.cn/post/7038473714970656775


過期時間的合理性分析:

因為對於不同的業務,我們設置的過期時間的長短都會不一樣,太長了不合適,太短了也不合適;

所以我們想到的解決方案是設置一條子線程,給當前鎖資源續命。具體實現是,子線程間隔2-3s去查詢一次key是否過期,如果還沒有過期則代表業務線程還在執行業務,那麼則為該key的過期時間加上5s。

但是為了避免主線程意外死亡後,子線程會一直為其續命,造成“長生鎖”的現象,所以將子線程變為主(業務)線程的守護線程,這樣子線程就會跟著主線程一起死亡。

// 續命子線程
public class GuardThread extends Thread { 
    private static boolean flag = true;

    public GuardThread(String lockKey, 
        int timeOut, StringRedisTemplate stringRedisTemplate){
        ……
    }

    @Override
    public void run() {
        // 開啟迴圈續命
        while (flag){
            try {
                // 先休眠一半的時間
                Thread.sleep(timeOut / 2 * 1000);
            }catch (Exception e){
                e.printStackTrace();
            }
            // 時間過了一半之後再去續命
            // 先查看key是否過期
            Long expire = stringRedisTemplate.getExpire(
                lockKey, TimeUnit.SECONDS);
            // 如果過期了,代表主線程釋放了鎖
            if (expire <= 0){
                // 停止迴圈
                flag = false;
            }
            // 如果還未過期
            // 再為則續命一半的時間
            stringRedisTemplate.expire(lockKey,expire
                + timeOut/2,TimeUnit.SECONDS);
        }
    }
}


// 創建子線程為鎖續命
GuardThread guardThread = new GuardThread(lockKey,timeOut,stringRedisTemplate);
// 設置為當前 業務線程 的守護線程
guardThread.setDaemon(true);
guardThread.start();

作者:竹子愛熊貓 
鏈接:https://juejin.cn/post/7038473714970656775


Redis主從架構下鎖失效的問題

為了在開發過程保證Redis的高可用,會採用主從複製架構做讀寫分離,從而提升Redis的吞吐量以及可用性。但是如果一條線程在redis主節點上獲取鎖成功之後,主節點還沒有來得及複製給從節點就宕機了,此時另一條線程訪問redis就會在從節點上面訪問,同時也獲取鎖成功,這時候臨界資源的訪問就會出現安全性問題了。

解決辦法:

  • 紅鎖演算法(官方提出的解決方案):多台獨立的Redis同時寫入數據,在鎖失效時間之內,一半以上的機器寫成功則返回獲取鎖成功,失敗的時候釋放掉那些成功的機器上的鎖。但這種做法缺點是成本高需要獨立部署多台Redis節點。
  • 額外記錄鎖狀態:再額外通過其他獨立部署的中間件(比如DB)來記錄鎖狀態,在新線程獲取鎖之前需要先查詢DB中的鎖持有記錄,只要當鎖狀態為未持有時再嘗試獲取分散式鎖。但是這種情況缺點顯而易見,獲取鎖的過程實現難度複雜,性能開銷也非常大;另外還需要配合定時器功能更新DB中的鎖狀態,保證鎖的合理失效機制。
  • 使用Zookepper實現

Zookeeper實現分散式鎖

Zookeeper數據區別於redis的數據,數據是實時同步的,主節點寫入後需要一半以上的節點都寫入才會返回成功。所以如果像電商、教育等類型的項目追求高性能,可以放棄一定的穩定性,推薦使用redis實現;例如像金融、銀行、政府等類型的項目,追求高穩定性,可以犧牲一部分性能,推薦使用Zookeeper實現。

分散式鎖性能優化

上面加鎖確實解決了併發情況下線程安全的問題,但是我們面對100w個用戶同時去搶購1000個商品的場景該如何解決呢?

  • 可與將共用資源做一下提前預熱,分段分散存儲一份。搶購時間為下午15:00,提前再14:30左右將商品數量分成10份,並將每一塊數據進行分別加鎖,來防止併發異常。
  • 另外也需要在redis中寫入10個key,每一個新的線程進來先隨機的分配一把鎖,然後進行後面的減庫存邏輯,完成之後釋放鎖,以便之後的線程使用。
  • 這種分散式鎖的思想就是,將原先一把鎖就可以實現的多線程同步訪問共用資源的功能,為了提高瞬時情況下多線程的訪問速度,還需要保證併發安全的情況下一種實現方式。

參考文章:

  1. https://juejin.cn/post/7236213437800890423

  2. https://juejin.cn/post/7038473714970656775

  3. https://tech.meituan.com/2019/12/05/aqs-theory-and-apply.html

作者:京東科技 焦澤斌

來源:京東雲開發者社區 轉載請註明來源


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 資料庫完整性包括正確性和相容性,DBMS通過提供約束條件機制、檢查方法和違約處理功能維護資料庫完整性,其中實體完整性通過主鍵確保唯一標識,參照實體性通過外鍵關聯,用戶定義完整性滿足特定應用需求,而觸發器和斷言提供事件驅動和複雜約束支持,共同構成資料庫保持一致性的關鍵機制。 ...
  • SQL(結構化查詢語言)的演變從IBM的SystemR開始,經過ANSI的標準化,近年來SQL標準變得更加豐富和複雜。SQL的特點包括綜合統一、高度非過程化、面向集合的操作方式以及提供多種使用方式的統一語法結構。在資料庫實例中,基本表獨立存在,而視圖是基本表導出的虛表,用於供人查看。資料庫模式結構包... ...
  • SQL ALTER TABLE 語句 SQL ALTER TABLE 語句用於在現有表中添加、刪除或修改列,也可用於添加和刪除各種約束。 ALTER TABLE - 添加列 要在表中添加列,請使用以下語法: ALTER TABLE 表名 ADD 列名 數據類型; 以下 SQL 向 "Customer ...
  • 本文分享自華為雲社區《GaussDB資料庫SQL系列-SQL與ETL淺談》,作者:Gauss松鼠會小助手2。 一、前言 在SQL語言中,ETL(抽取、轉換和載入)是一種用於將數據從源系統抽取到目標系統的過程。ETL過程通常包括三個階段:抽取(Extract)、轉換(Transform)和載入(Loa ...
  • 數據作為新時代重要的生產要素之一,數據資產化的相關工作正在提速。自今年10月1日起,中國資產評估協會制定的《數據資產評估指導意見》正式施行。同時,《企業數據資源相關會計處理暫行規定》近期轉為正式稿,也將於明年1月1日起施行。 《暫行規定》規定:企業使用的數據資源,符合《企業會計準則第6號——無形資產 ...
  • 解耦、削峰:傳統的方式上游發送數據下游需要實時接收,如果上游在某些業務場景:例如上午十點會流量激增至頂峰,那麼下游資源可能會扛不住壓力。但如果使用消息隊列,就可以將消息暫存在消息管道中,下游可以按照自己的速度逐步處理; ...
  • 大數據框架下,常用的數據更新策略有三種: COW: copy-on-write, 寫時複製; MOR: merge-on-read, 讀時合併; MOW: merge-on-write, 寫時合併; hudi等數據湖倉框架,常用的是前兩種實現數據更新。而Doris則主要用後兩種更新數據。 COW 在 ...
  • 資料庫關係模型是數據組織的核心,以關係為基礎,表達實體和實體關係。關係模型通過域、笛卡爾積、關係模式構建二維表,形成資料庫。完整性約束確保數據有效性,實體完整性、參照完整性和用戶定義完整性保證數據質量。關係操作包括基本操作和數據語言,而關係代數提供了強大的查詢手段。資料庫關係模型為信息管理提供了結構... ...
一周排行
    -Advertisement-
    Play Games
  • 背景 在瀏覽器中訪問本地靜態資源html網頁時,可能會遇到跨域問題如圖。 是因為瀏覽器預設啟用了同源策略,即只允許載入與當前網頁具有相同源(協議、功能變數名稱和埠)的內容。 WebView2預設情況下啟用了瀏覽器的同源策略,即只允許載入與主機相同源的內容。所以如果我們把靜態資源發佈到iis或者通過node ...
  • 最近看幾個老項目的SQL條件中使用了1=1,想想自己也曾經這樣寫過,略有感觸,特別拿出來說道說道。編寫SQL語句就像炒菜,每一種調料的使用都會影響菜品的最終味道,每一個SQL條件的加入也會影響查詢的執行效率。那麼 1=1 存在什麼樣的問題呢?為什麼又會使用呢? ...
  • 好久不見,我又回來了。 給大家分享一個我最近使用c#代碼操作ftp伺服器的代碼示例: 1 public abstract class FtpOperation 2 { 3 /// <summary> 4 /// FTP伺服器地址 5 /// </summary> 6 private string f ...
  • 一:背景 1. 講故事 過年喝了不少酒,腦子不靈光了,停了將近一個月沒寫博客,今天就當新年開工寫一篇吧。 去年年初有位朋友找到我,說他們的系統會偶發性崩潰,在網上也發了不少帖子求助,沒找到自己滿意的答案,讓我看看有沒有什麼線索,看樣子這是一個牛皮蘚的問題,既然對方有了dump,那就分析起來吧。 二: ...
  • 自己製作的一個基於Entity Framework Core 的資料庫操作攔截器,可以列印資料庫執行sql,方便開發調試,代碼如下: /// <summary> /// EF Core 的資料庫操作攔截器,用於在資料庫操作過程中進行日誌記錄和監視。 /// </summary> /// <remar ...
  • 本文分享自華為雲社區《Go併發範式 流水線和優雅退出 Pipeline 與 Cancellation》,作者:張儉。 介紹 Go 的併發原語可以輕鬆構建流數據管道,從而高效利用 I/O 和多個 CPU。 本文展示了此類pipelines的示例,強調了操作失敗時出現的細微之處,並介紹了乾凈地處理失敗的 ...
  • 在上篇文章中,我們介紹到在多線程環境下,如果編程不當,可能會出現程式運行結果混亂的問題。出現這個原因主要是,JMM 中主記憶體和線程工作記憶體的數據不一致,以及多個線程執行時無序,共同導致的結果。 ...
  • 1、下載安裝包首先、進入官網下載安裝包網址:https://www.python.org/downloads/windows/下載步驟:進入下載地址,根據自己的電腦系統選擇相應的python版本 選擇適配64位操作系統的版本(查看自己的電腦操作系統版本), 點擊下載安裝包 也可以下載我百度雲分享的安 ...
  • 簡介 git-commit-id-maven-plugin 是一個maven 插件,用來在打包的時候將git-commit 信息打進jar中。 這樣做的好處是可以將發佈的某版本和對應的代碼關聯起來,方便查閱和線上項目的維護。至於它的作用,用官方說法,這個功能對於大型分散式項目來說是無價的。 功能 你 ...
  • 序言 在數字時代,圖像生成技術正日益成為人工智慧領域的熱點。 本討論將重點聚焦於兩個備受矚目的模型:DALL-E和其他主流AI繪圖方法。 我們將探討它們的優勢、局限性以及未來的發展方向。通過比較分析,我們期望能夠更全面地瞭解這些技術,為未來的研究和應用提供啟示。 Q: 介紹一下 dall-e Ope ...