數據庫鎖之樂觀鎖

一、樂觀鎖的介紹

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

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

二、樂觀鎖的代碼示例

  2.1 創建一張表 

    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 插入一條數據

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

 2.3 修改數據

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

三、樂觀鎖的業務使用示例

    事務1

   事務2

    說明：

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

四、悲觀鎖的業務使用示例

   事務1：成功鎖定數據

    事務2：等待鎖的釋放

   事務1：操作鎖定數據并提交，同時釋放鎖定數據

    事務2：獲取數據鎖（最新數據）

說明：

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

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

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

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

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

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

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

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

  如果我們把業務設計得更合理一點，數據為設計更好一點，也許不需要這么麻煩！