如何解決多進程或多線程並發的問題

如何解決多進程或多線程並發問題

有個問題：

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

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

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

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 關鍵字為將來在當前連接上執行的事務設置默認事務級別。 任何客戶端都能自由改變會話隔離級別（甚至在事務的中間），或者為下一個事務設置隔離級別。