並行作業與資料的不一致性

來源:互聯網
上載者:User

最近做的《選修課系統》需要考慮這樣一個問題:資料庫的並行作業帶來的資料庫資料不一致問題——因為是全校性選修課,同一時間點大批學生選課,那麼必然存在多名學生同時對同一資料進行操作是的問題,如果這種並行作業不加以控制的話,必會造成資料的不一致。

 

一直知道有這種問題,並且知道這種問題的解決方案——加鎖;但是有些東西之前瞭解的並不是很透徹,於是好好研究了一天,覺得理解的還可以,先總結一部分。

 

1,什麼是並行作業?

資料庫的一個重要特徵是:支援資料共用,也就是說允許多個使用者程式並行地存取資料庫中的資料;那麼,多使用者或多事物可能同時對同一資料進行操作,這成為並行作業。

 

2,並行作業可能帶來的影響?

如果不對並行作業進行控制的話,那麼就會存取不正確的資料,破壞資料的完整性。——為什麼這麼說?下面進行介紹

 

在此之前,先說一下事務的概念。

3,什麼是事務?

對一件完整的事兒,要麼做完整,要麼都不做。例如:學生選課—學生選上課時,需要將選課資訊寫入選課表的同時,更新課程表中的課程餘量;如果在添加選課資訊時,中斷了(不能進行餘量更新),那麼就會交易回復,即,資料復原到沒選課之前。

Begin Transaction

選課表中添加選課資訊;

更新課程表中的課程餘量;

Commit

RollBac

 

事務的SQL語句:

Begin Transaction開始事務

Commit提交事務

RollBack復原

註:事務中的多條SQL語句也是一條條執行的,當所有語句執行完後,提交事務,如果其中一條中斷,則交易回復所有操作回到語句執行之前)

事務的並發主要是為了提高效率,但是,同時它也帶來了一定問題

 

4,並行作業帶來的問題?

之前講過並行作業——多使用者或多事務同時對同一資料進行操作;

因為事務中的語句也是一條條執行的,所以存在多使用者多事務同時對同一資料進行操作的情況;

並行作業帶來的問題:

(1)丟失修改

(2)髒讀

(3)不可重複讀取

 

4.1丟失修改

當兩個或多個事務(或兩個或多個使用者)選擇同一行,然後基於最初選定的值更新該行時,會發生丟失更新問題。每個事務都不知道其它事務的存在(或每個使用者操作時並不會考慮同一時刻是否有別的使用者進行著同樣的操作)。最後的更新將重寫由其它事務所做的更新,這將導致資料丟失。  

 

例子1:事務T1,事務T2,資料庫中資料R=1000

a.t1時刻,事務T1讀取R=1000;

b.過了一會兒 t2時刻,事務T2讀取R=1000;

c.t3時刻,事務T1修改R=R-200(那麼R=800)寫入資料庫(此時,資料庫中R=800);

d.過了一會兒 t4時刻,事務T2修改R=R-100(因為在t2時刻讀到的資料為R=1000,那麼修改後R=900)寫入資料庫(此時,資料庫中R=900)

 

那麼最終,資料庫中R=900;資料對嗎?當然不對,因為T1、T2分別對R進行了-200 -100操作,最終資料應為R=700;事務T2的修改覆蓋了T1的修改——丟失修改問題

 

 

 

例子2:選課:學生A、學生B、課程1的餘量=20

 

a.學生A選擇課程1時,先讀出課程餘量20

b.然而同一時刻(也可是不同時刻,只要在學生A更新資料之前),學生B也讀出了課程1的餘量20,

c.學生A選擇此課程,課程1餘量-1,寫入資料庫,此時課程1的餘量=19;

d.學生B選擇此課程,課程1餘量-1(因為之前讀出的課程1餘量為20,-1後為19),寫入資料庫,此時課程1的餘量=19;

 課程餘量=19資料正確嗎?不正確。實際情況課程餘量應更新為18;——B的修改覆蓋了A的修改—— 丟失修改問題。

 

 

解決辦法:加鎖,只允許並發一個更新事務。

 

4.2髒讀

當一個事務正在訪問資料,並且對資料進行了修改,而這種修改還沒有提交到資料庫中,這時,

另外一個事務也訪問這個資料,然後使用了這個資料。因為這個資料是還沒有提交的資料,那麼另外一個

事務讀到的這個資料是髒資料,依據髒資料所做的操作可能是不正確的。

 

例子1:事務T1,事務T2,資料庫中資料R=1000;

T1:

Begin Transaction開始事務T1

ReadR=1000;(1)

R=R-200;(2)此時R=800

R=R+100;(3)此時R=900

Commit提交事務T1

 

a.當事務T1進行到第(2)後,即,資料庫中的資料R=800時;

b.事務T2開始讀R的值,讀出的值為R=800;但此時事務T1還沒有進行完整,還未提交事務;

c.之後事務T1進行第(3)步R=R+100,此時R=900事務T1提交,此時資料庫中R=900;

 

   那麼在事務T1提交事務之前,事務T2讀出的資料(R=800)為髒資料;

 

例子2:

 a.張三的工資為2000,元老闆把張三的工資改為了8000元(但未提交事務)        

2.張三查看自己的工資 ,發現工資變為了8000元

3.而後老闆發現改錯了,復原了事務,張三的工資又變回了2000元

     那麼,張三讀取的工資8000元就是髒資料。

 

 

解決辦法:如果在第一個事務提交前,任何其他事務不可讀取其修改過的值,則可以避免該問題。

 

 

4.3不可重複讀取

  當第二個事務多次訪問同一行而且每次讀取不同的資料時,會發生不一致的分析問題。不一致的分析與未確認的相關性類似,因為其它事務也是正在更改第二個事務正在讀取的資料。然而,在不一致的分析中,第二個事務讀取的資料是由已進行了更改的事務提交的。而且,不一致的分析涉及多次(兩次或更多)讀取同一行,而且每次資訊都由其它事務更改;因而該行被非重複讀取。

 

      在一個事務中前後兩次讀取的結果並不致,導致了不可重複讀取。

 

 

例子1:事務T1、事務T2、張三的工資=1000

 

a.事務T1中,張三讀取了自己的工資為1000元,操作並沒有完成

 

b.此時(事務T1讀取了張三工資為1000元)事務2中,修改了張三的工資為2000元,並提交了事務.

 

c.此時(事務T1讀取了張三工資為1000元,事務T2修改了張三的工資為2000元)在事務1中,張三再次讀取自己的工資時,工資變為了2000

 

那麼,同一個事務中,前後讀取的資料不一致—— 不可重複讀取問題。

 

解決辦法:如果只有在修改事務完全提交之後才可以讀取資料,則可以避免該問題。

 

 

總結:

(1)事務的並發主要是為了提高效率,但是,同時它也帶來了一定問題——丟失修改、讀髒資料、不可重複讀取

(2)結合生活中執行個體,理解丟失修改、讀髒資料、不可重複讀取問題。

 

個人理解,如果哪裡有理解偏差,忘糾正!

 

下篇部落格會總結“鎖”的概念,並解釋“鎖”是如何解決並發造成的資料不一致問題。

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.