如何解決多程式或多執行緒併發的問題

如何解決多程式或多執行緒併發問題

有個問題：

一個程式開啟事務對錶的某一行做了修改，但還沒有提交，另一個程式查詢該行資料，獲取到的是原始的，這時候上面的事物提交了，我再用這個原始資料的時候就有問題……

那我們該怎麼解決這個問題呢？

解決多事務併發問題的方法有以下幾種：

1、檔案鎖

如果對該表的更新或插入的操作，都會經過一個統一的檔案，這種方式是可以解決的多程式併發的問題；

實現方式如下：

public static function cbInventoryReserve() {
        $LOCK_FILE_PATH = $_SERVER['DOCUMENT_ROOT']."wmsinventoryapi/inventory/InventoryReserve.php";
        $fp = fopen( $LOCK_FILE_PATH, "r" );
        if (!$fp) {
            die("Failed to open the lock file!");
        }
        flock ( $fp, LOCK_EX );
        
    //需要進行的操作
        $params = Flight::request()->getBody();
        $params = json_decode($params, true);
        if (! is_array($params) || empty($params)) {
            Flight::sendRouteResult(array("error_code" => "40002","error_info" => "params empty"));
        }
        $result = \Inventory\InventoryEngine::getInstance()->inventoryReserve($params);
        
        flock ( $fp, LOCK_UN );
        fclose ( $fp );
        Flight::sendRouteResult($result);
    }

　　函式說明  flock()會依引數operation所指定的方式對引數fd所指的檔案做各種鎖定或解除鎖定的動作。此函式只能鎖定整個檔案，無法鎖定檔案的某一區域。

　　 引數  operation有下列四種情況:

　　 LOCK_SH 建立共享鎖定。多個程式可同時對同一個檔案作共享鎖定。

　 LOCK_EX 建立互斥鎖定。一個檔案同時只有一個互斥鎖定。

　 LOCK_UN 解除檔案鎖定狀態。

　　 LOCK_NB 無法建立鎖定時，此操作可不被阻斷，馬上返回程式。通常與LOCK_SH或LOCK_EX 做OR(|)組合。

　　 單一檔案無法同時建立共享鎖定和互斥鎖定，而當使用dup()或fork()時檔案描述詞不會繼承此種鎖定。

　　 返回值  返回0表示成功，若有錯誤則返回-1，錯誤程式碼存於errno。

換言之：

 

使用共享鎖LOCK_SH，如果是讀取，不需要等待，但如果是寫入，需要等待讀取完成。

 

使用獨佔鎖LOCK_EX，無論寫入/讀取都需要等待。

 

LOCK_UN，無論使用共享/讀佔鎖，使用完後需要解鎖。

 

LOCK_NB，當被鎖定時，不阻塞，而是提示鎖定。

 

為了更好的移植性，對於檔案的開啟與關閉我選擇了fopen和fclose的組合，但flock的第一個引數要求的是int型別的檔案描述符。這裡對fopen返回的FILE型別的檔案指標進行轉換，轉換為int型的檔案描述符 （假設open函式返回的檔案描述符為fd，而fopen返回的檔案指標為*fp，則fd等價於fp->_fileno）.

2、序列化介面（物件序列化）

所有php裡面的值都可以使用函式serialize()來返回一個包含位元組流的字串來表示。unserialize()函式能夠重新把字串變回php原來的值。 序列化一個物件將會儲存物件的所有變數，但是不會儲存物件的方法，只會儲存類的名字。

<?php
// classa.inc:
  
  class A {
      public $one = 1;
    
      public function show_one() {
          echo $this->one;
      }
  }
  
// page1.php:

  include("classa.inc");
  
  $a = new A;
  $s = serialize($a);
  // 把變數$s儲存起來以便檔案page2.php能夠讀到
  file_put_contents('store', $s);

// page2.php:
  
  // 要正確瞭解序列化，必須包含下面一個檔案
  include("classa.inc");

  $s = file_get_contents('store');
  $a = unserialize($s);

  // 現在可以使用物件$a裡面的函式 show_one()
  $a->show_one();
?>

3、select *** for update

Select …forupdate語句是我們經常使用手工加鎖語句。通常情況下，select語句是不會對資料加鎖，妨礙影響其他的DML和DDL操作。同時，在多版本一致讀機制的支援下，select語句也不會被其他型別語句所阻礙。

藉助for update子句，我們可以在應用程式的層面手工實現資料加鎖保護操作。

for update子句的預設行為就是自動啟動一個事務，藉助事務的鎖機制將資料進行鎖定。

開啟一個事務使用for update

start transaction;

select sum(quantity) from ws_inventory_item where inventory_item_id=86 for update;

再開啟另一個事務時，做update 操作的時，只能等待上面的事務，commit才能執行；

start transaction;

update ws_inventory_item set quantity = quantity + 1  where inventory_item_id = 86;

MySQL  使用 SELECT … FOR UPDATE 做事務寫入前的確認

以MySQL 的InnoDB 為例，預設的 Tansaction isolation level 為 REPEATABLE READ，在 SELECT 的讀取鎖定主要分為兩種方式:

SELECT … LOCK IN SHARE MODE
SELECT … FOR UPDATE

這兩種方式在事務(Transaction) 進行當中SELECT 到同一個資料表時，都必須等待其它事務資料被提交(Commit)後才會執行。而主要的不同在於LOCK IN SHARE MODE 在有一方事務要Update 同一個表單時很容易造成死鎖 。

簡單的說，如果SELECT 後面若要UPDATE 同一個表單，最好使用 SELECT … UPDATE。

舉個例子：假設商品表單products 內有一個存放商品數量的quantity ，在訂單成立之前必須先確定quantity 商品數量是否足夠(quantity>0) ，然後才把數量更新為1。

不安全的做法：

SELECT quantity FROM products WHERE id=3;
UPDATE products SET quantity = 1 WHERE id=3;

為什麼不安全呢？

少量的狀況下或許不會有問題，但是大量的資料存取「鐵定」會出問題。

如果我們需要在 quantity>0 的情況下才能扣庫存，假設程式在第一行 SELECT 讀到的 quantity 是 2 ，看起來數字沒有錯，但是當MySQL 正準備要UPDATE 的時候，可能已經有人把庫存扣成 0 了，但是程式卻渾然不知，將錯就錯的 UPDATE 下去了。

因此必須透過的事務機制來確保讀取及提交的資料都是正確的。

於是我們在MySQL 就可以這樣測試：(注1)

1    SET AUTOCOMMIT=0;
2    BEGIN WORK;
3    SELECT quantity FROM products WHERE id=3 FOR UPDATE;

此時 products 資料中 id=3 的資料被鎖住(注3)，其它事務必須等待此次事務提交後才能執行 SELECT * FROM products WHERE id=3 FOR UPDATE (注2)如此可以確保 quantity 在別的事務讀到的數字是正確的。

1    UPDATE products SET quantity = '1' WHERE id=3 ;
2    COMMIT WORK;

提交(Commit)寫入資料庫，products 解鎖。

注1：BEGIN/COMMIT 為事務的起始及結束點，可使用二個以上的MySQL Command 視窗來互動觀察鎖定的狀況。

注2：在事務進行當中，只有SELECT … FOR UPDATE 或LOCK IN SHARE MODE 同一筆資料時會等待其它事務結束後才執行，一般SELECT … 則不受此影響。

注3：由於InnoDB 預設為Row-level Lock，資料列的鎖定可參考這篇。

注4：InnoDB 表單儘量不要使用LOCK TABLES 指令，若情非得已要使用，請先看官方對於InnoDB 使用LOCK TABLES 的說明，以免造成系統經常發生死鎖。

 

MySQL SELECT … FOR UPDATE 的 Row Lock 與 Table Lock

上面介紹過SELECT … FOR UPDATE 的用法，不過鎖定(Lock)的資料是判別就得要注意一下了。由於InnoDB 預設是Row-Level Lock，所以只有「明確」地指定主鍵，MySQL 才會執行 Row lock (只鎖住被選取的資料) ，否則MySQL 將會執行 Table Lock (將整個資料表單給鎖住)。

舉個例子:

假設有個表單products ，裡面有id 跟name 二個欄位，id 是主鍵。

例1: (明確指定主鍵，並且有此資料，row lock)

 

     SELECT * FROM products WHERE id='3' FOR UPDATE;

例2: (明確指定主鍵，若查無此資料，無lock)

     SELECT * FROM products WHERE id='-1' FOR UPDATE;

例2: (無主鍵，table lock)

     SELECT * FROM products WHERE name='Mouse' FOR UPDATE;

例3: (主鍵不明確，table lock)

     SELECT * FROM products WHERE id<>'3' FOR UPDATE;

例4: (主鍵不明確，table lock)

     SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;

注1: FOR UPDATE 僅適用於InnoDB，且必須在事務區塊(BEGIN/COMMIT)中才能生效。

注2: 要測試鎖定的狀況，可以利用MySQL 的Command Mode ，開二個視窗來做測試。

 

4、事務隔離級別

如何解決多程式或多執行緒併發問題

本節轉載，原文地址：http://singo107.iteye.com/blog/1175084

資料庫事務的隔離級別有4個，由低到高依次為Read uncommitted、Read committed、Repeatable read、Serializable，這四個級別可以逐個解決髒讀、不可重複讀、幻讀這幾類問題。

 

√: 可能出現    ×: 不會出現

	髒讀	不可重複讀	幻讀
Read uncommitted	√	√	√
Read committed	×	√	√
Repeatable read	×	×	√
Serializable	×	×	×

 

注意：我們討論隔離級別的場景，主要是在多個事務併發的情況下，因此，接下來的講解都圍繞事務併發。

Read uncommitted 讀未提交

公司發工資了，領導把5000元打到singo的賬號上，但是該事務並未提交，而singo正好去檢視賬戶，發現工資已經到賬，是5000元整，非常高興。可是不幸的是，領導發現發給singo的工資金額不對，是2000元，於是迅速回滾了事務，修改金額後，將事務提交，最後singo實際的工資只有2000元，singo空歡喜一場。

 

出現上述情況，即我們所說的髒讀，兩個併發的事務，“事務A：領導給singo發工資”、“事務B：singo查詢工資賬戶”，事務B讀取了事務A尚未提交的資料。

當隔離級別設定為Read uncommitted時，就可能出現髒讀，如何避免髒讀，請看下一個隔離級別。

Read committed 讀提交

singo拿著工資卡去消費，系統讀取到卡里確實有2000元，而此時她的老婆也正好在網上轉賬，把singo工資卡的2000元轉到另一賬戶，並在singo之前提交了事務，當singo扣款時，系統檢查到singo的工資卡已經沒有錢，扣款失敗，singo十分納悶，明明卡里有錢，為何......

出現上述情況，即我們所說的不可重複讀，兩個併發的事務，“事務A：singo消費”、“事務B：singo的老婆網上轉賬”，事務A事先讀取了資料，事務B緊接了更新了資料，並提交了事務，而事務A再次讀取該資料時，資料已經發生了改變。

當隔離級別設定為Read committed時，避免了髒讀，但是可能會造成不可重複讀。

大多數資料庫的預設級別就是Read committed，比如Sql Server , Oracle。如何解決不可重複讀這一問題，請看下一個隔離級別。

Repeatable read 重複讀

當隔離級別設定為Repeatable read時，可以避免不可重複讀。當singo拿著工資卡去消費時，一旦系統開始讀取工資卡資訊（即事務開始），singo的老婆就不可能對該記錄進行修改，也就是singo的老婆不能在此時轉賬。

雖然Repeatable read避免了不可重複讀，但還有可能出現幻讀。

singo的老婆工作在銀行部門，她時常通過銀行內部系統檢視singo的信用卡消費記錄。有一天，她正在查詢到singo當月信用卡的總消費金額（select sum(amount) from transaction where month = 本月）為80元，而singo此時正好在外面胡吃海塞後在收銀臺買單，消費1000元，即新增了一條1000元的消費記錄（insert transaction ... ），並提交了事務，隨後singo的老婆將singo當月信用卡消費的明細列印到A4紙上，卻發現消費總額為1080元，singo的老婆很詫異，以為出現了幻覺，幻讀就這樣產生了。

注：Mysql的預設隔離級別就是Repeatable read。

Serializable 序列化

Serializable是最高的事務隔離級別，同時代價也花費最高，效能很低，一般很少使用，在該級別下，事務順序執行，不僅可以避免髒讀、不可重複讀，還避免了幻像讀。

 Mysql事務隔離級別設定方式

使用者可以用SET TRANSACTION語句改變單個會話或者所有新進連線的隔離級別。它的語法如下：

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

 

注意：預設的行為（不帶session和global）是為下一個（未開始）事務設定隔離級別。如果你使用GLOBAL關鍵字，語句在全域性對從那點開始建立的所有新連線（除了不存在的連線）設定預設事務級別。你需要SUPER許可權來做這個。使用SESSION 關鍵字為將來在當前連線上執行的事務設定預設事務級別。 任何客戶端都能自由改變會話隔離級別（甚至在事務的中間），或者為下一個事務設定隔離級別。