如何處理并發(fā)和同步？
??主要是通過鎖機制。
悲觀鎖：指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當前的其他事務(wù)，以及來自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度.雖然這樣保證了線程安全的問題，但是，如果是在“高并發(fā)”的場景中。也就是說，會很多這樣的修改請求，每個請求都需要等待“鎖”，某些線程可能永遠都沒有機會搶到這個“鎖”，這種請求就會死在那里。同時，這種請求會很多，瞬間增大系統(tǒng)的平均響應(yīng)時間，結(jié)果是可用連接數(shù)被耗盡，系統(tǒng)陷入異常。
樂觀鎖：相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數(shù)情況下依靠數(shù)據(jù)庫的鎖機制實現(xiàn)，以保證操作最大程度的獨占性。但隨之而來的就是數(shù)據(jù)庫性能的大量開銷，特別是對長事務(wù)而言，這樣的開銷往往無法承受。
如一個金融系統(tǒng)，當某個操作員讀取用戶的數(shù)據(jù)，并在讀出的用戶數(shù)據(jù)的基礎(chǔ)上進行修改時（如更改用戶帳戶余額），如果采用悲觀鎖機制，也就意味著整個操作過程中（從操作員讀出數(shù)據(jù)、開始修改直至提交修改結(jié)果的全過程，甚至還包括操作員中途去煮咖啡的時間），數(shù)據(jù)庫記錄始終處于加鎖狀態(tài)，可以想見，如果面對幾百上千個并發(fā)，這樣的情況將導(dǎo)致怎樣的后果。
樂觀鎖機制在一定程度上解決了這個問題。
樂觀鎖，大多是基于數(shù)據(jù)版本Version記錄機制實現(xiàn)。數(shù)據(jù)版本，為數(shù)據(jù)增加一個版本標識，在基于數(shù)據(jù)庫表的版本解決方案中，一般是給數(shù)據(jù)庫表增加一個 “version” 字段來實現(xiàn)。
假設(shè)數(shù)據(jù)庫中帳戶信息表中有一個 version 字段，當前值為 1 ；而當前帳戶余額字段（ balance ）為 50（
50 ）。
- 在操作員 A 操作的過程中，操作員 B 也讀入此用戶信息（ version=1 ），并 從其帳戶余額中扣除
100-$20 ）。
- 操作員 A 完成了修改工作，將數(shù)據(jù)版本號加一（version=2），連同帳戶扣除后余額（balance=$50），提交至數(shù)據(jù)庫更新，此時由于提交數(shù)據(jù)版本大于數(shù)據(jù)庫記錄當前版本，數(shù)據(jù)被更新，數(shù)據(jù)庫記錄 version 更新為 2 。
- 操作員 B 完成了操作，也將版本號加一（version=2)試圖向數(shù)據(jù)庫提交數(shù)據(jù)（balance=$80），但此時比對數(shù)據(jù)庫記錄版本時發(fā)現(xiàn)，操作員 B提交的數(shù)據(jù)版本號為2，數(shù)據(jù)庫記錄當前版本也為2，不滿足“交版本必須大于記錄當前版本才能執(zhí)行更新 “的樂觀鎖策略，因此，操作員B的提交被駁回。這樣，就避免了操作員 B 用基于version=1 的舊數(shù)據(jù)修改的結(jié)果覆蓋操作 員 A 的操作結(jié)果的可能。 從上面的例子可以看出，樂觀鎖機制避免了長事務(wù)中的數(shù)據(jù)庫加鎖開銷（操作員A和操作員B操作過程中，都沒有對數(shù)據(jù)庫數(shù)據(jù)加鎖），大大提升了大并發(fā)量下的系統(tǒng)整體性能表現(xiàn)。
臟數(shù)據(jù)
??臟讀就是指當一個事務(wù)正在訪問數(shù)據(jù)，并且對數(shù)據(jù)進行了修改，而這種修改還沒有提交到數(shù)據(jù)庫中，這時，另外一個事務(wù)也訪問這個數(shù)據(jù)，然后使用了這個數(shù)據(jù)。因為這個數(shù)據(jù)是還沒有提交的數(shù)據(jù)，那么另外一個事務(wù)讀到的這個數(shù)據(jù)是臟數(shù)據(jù)(Dirty Data)，依據(jù)臟數(shù)據(jù)所做的操作可能是不正確的。 `
事務(wù)
??在關(guān)系數(shù)據(jù)庫中，一個事務(wù)可以是一條SQL語句，一組SQL語句或整個程序。
