并發操作與數據的不一致性

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

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

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

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）結合生活中實例，理解丟失修改、讀臟數據、不可重復讀問題。

個人理解，如果哪里有理解偏差，忘糾正！

下篇博客會總結“鎖”的概念，并解釋“鎖”是如何解決并發造成的數據不一致問題。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com