數(shù)據(jù)庫鎖之樂觀鎖

一、樂觀鎖的介紹

   樂觀鎖是相對悲觀鎖而言，也是為了避免數(shù)據(jù)庫幻讀、業(yè)務(wù)處理時間過長等原因引起數(shù)據(jù)處理錯誤的一種機制，但樂觀鎖不會刻意使用數(shù)據(jù)庫本身的鎖機制，而是依據(jù)數(shù)據(jù)本身來保證數(shù)據(jù)的正確性。

  樂觀鎖的機制：對每條數(shù)據(jù)庫加上版本號或時間撮，在每次對數(shù)據(jù)進行操作(尤其是修改操作)時，總會帶上版本號獲取數(shù)據(jù)同時更改后修改版本號。

二、樂觀鎖的代碼示例

  2.1 創(chuàng)建一張表 

    create table em_oplock

    (

      id VARCHAR(100) not null,

      value VARCHAR(100),

      version int(10),

      PRIMARY key(id)

    ) ENGINE=INNODB DEFAULT CHARSET=utf8;

 2.2 插入一條數(shù)據(jù)

    INSERT into em_oplock values('1','1',1);

 2.3 修改數(shù)據(jù)

    update em_oplock set value='2',version=version+1 where id = 1 and version = 1;

三、樂觀鎖的業(yè)務(wù)使用示例

    事務(wù)1

   事務(wù)2

    說明：

   當兩個用戶同時操作ID為1的數(shù)據(jù)或一個用戶未處理完另一個用戶也對此數(shù)據(jù)操作時，兩個用戶獲取數(shù)據(jù)做了一系列的業(yè)務(wù)處理后都認為自己的數(shù)據(jù)判斷是正確的，于是都對同一條數(shù)據(jù)進行修改提交。如果我們不做版本控制的話，后處理的用戶將覆蓋前面用戶的數(shù)據(jù)。如果我們加上版本控制的話，當用戶1處理成功后，用戶2將一條數(shù)據(jù)都不會處理。

四、悲觀鎖的業(yè)務(wù)使用示例

   事務(wù)1：成功鎖定數(shù)據(jù)

    事務(wù)2：等待鎖的釋放

   事務(wù)1：操作鎖定數(shù)據(jù)并提交，同時釋放鎖定數(shù)據(jù)

    事務(wù)2：獲取數(shù)據(jù)鎖（最新數(shù)據(jù)）

說明：

  為了對數(shù)據(jù)處理的正確性，在操作數(shù)據(jù)前先對數(shù)據(jù)進行鎖定(for update)。利用數(shù)據(jù)庫本身的排它鎖機制，保證了數(shù)據(jù)只能一個用戶一個用戶的處理。

五、樂觀鎖與悲觀鎖的比較

  5.1 樂觀鎖需要增加額外的字段來記錄版本號，增加了數(shù)據(jù)庫設(shè)計復(fù)雜度。(樂觀鎖的劣勢)

  5.2 樂觀鎖需要每個修改的地方同時更新版本號，增加了開發(fā)的成本。(樂觀鎖的劣勢)

  5.3 當并發(fā)量大或業(yè)務(wù)時間處理比較長時，就會造成數(shù)據(jù)庫鎖長時間等待，限制并發(fā)量和快速消耗數(shù)據(jù)庫資源。(悲觀鎖的劣勢)

  5.4 悲觀鎖操作時，需要對數(shù)據(jù)庫的鎖機制有一定程度的理解才行。否則，容易造成表鎖或死鎖。(悲觀鎖的劣勢)

六、樂觀鎖與悲觀鎖的選擇

  不論是悲觀鎖還是樂觀鎖，都是為實際業(yè)務(wù)服務(wù)的，都是為了保證數(shù)據(jù)的正確性。選擇樂觀鎖還是悲觀鎖需要根據(jù)具體的業(yè)務(wù)場景、數(shù)據(jù)庫設(shè)計、開發(fā)成本等因素進行權(quán)衡。如果此業(yè)務(wù)涉及的面比較多、開發(fā)人員比較多等，建議用悲觀鎖。如果此業(yè)務(wù)比較單一或數(shù)據(jù)庫操作的地方比較少、并發(fā)量要求很高等情況下，建議用樂觀鎖。 

  如果我們把業(yè)務(wù)設(shè)計得更合理一點，數(shù)據(jù)為設(shè)計更好一點，也許不需要這么麻煩！