併發問題處理方式

如何處理併發和同步？

  主要是通過鎖機制。

悲觀鎖：指的是對資料被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度.雖然這樣保證了執行緒安全的問題，但是，如果是在“高併發”的場景中。也就是說，會很多這樣的修改請求，每個請求都需要等待“鎖”，某些執行緒可能永遠都沒有機會搶到這個“鎖”，這種請求就會死在那裡。同時，這種請求會很多，瞬間增大系統的平均響應時間，結果是可用連線數被耗盡，系統陷入異常。

樂觀鎖：相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依靠資料庫的鎖機制實現，以保證操作最大程度的獨佔性。但隨之而來的就是資料庫效能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。

如一個金融系統，當某個操作員讀取使用者的資料，並在讀出的使用者資料的基礎上進行修改時（如更改使用者帳戶餘額），如果採用悲觀鎖機制，也就意味著整個操作過程中（從操作員讀出資料、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對幾百上千個併發，這樣的情況將導致怎樣的後果。
樂觀鎖機制在一定程度上解決了這個問題。
樂觀鎖，大多是基於資料版本Version記錄機制實現。資料版本，為資料增加一個版本標識，在基於資料庫表的版本解決方案中，一般是給資料庫表增加一個 “version” 欄位來實現。

假設資料庫中帳戶資訊表中有一個 version 欄位，當前值為 1 ；而當前帳戶餘額欄位（ balance ）為 50（ 50 ）。

• 在操作員 A 操作的過程中，操作員 B 也讀入此使用者資訊（ version=1 ），並 從其帳戶餘額中扣除 100-$20 ）。
• 操作員 A 完成了修改工作，將資料版本號加一（version=2），連同帳戶扣除後餘額（balance=$50），提交至資料庫更新，此時由於提交資料版本大於資料庫記錄當前版本，資料被更新，資料庫記錄 version 更新為 2 。
• 操作員 B 完成了操作，也將版本號加一（version=2)試圖向資料庫提交資料（balance=$80），但此時比對資料庫記錄版本時發現，操作員 B提交的資料版本號為2，資料庫記錄當前版本也為2，不滿足“交版本必須大於記錄當前版本才能執行更新 “的樂觀鎖策略，因此，操作員B的提交被駁回。這樣，就避免了操作員 B 用基於version=1 的舊資料修改的結果覆蓋操作 員 A 的操作結果的可能。 從上面的例子可以看出，樂觀鎖機制避免了長事務中的資料庫加鎖開銷（操作員A和操作員B操作過程中，都沒有對資料庫資料加鎖），大大提升了大併發量下的系統整體效能表現。

---

髒資料
  髒讀就是指當一個事務正在訪問資料，並且對資料進行了修改，而這種修改還沒有提交到資料庫中，這時，另外一個事務也訪問這個資料，然後使用了這個資料。因為這個資料是還沒有提交的資料，那麼另外一個事務讀到的這個資料是髒資料(Dirty Data)，依據髒資料所做的操作可能是不正確的。 `
事務
  在關聯式資料庫中，一個事務可以是一條SQL語句，一組SQL語句或整個程式。