高併發的產生

對於web專案，隨著使用者量的增加就有可能產生高併發的問題。高併發簡單的來說就是在同一時刻不同使用者訪問同一資源的問題，專業一點的說法就是在同一時刻有多個執行緒訪問了同一個資料資源。

解決方案

目前對於高併發大部分的解決方案都是通過鎖機制，鎖機制有兩個層面。
一種是程式碼層次上的，如java中的同步鎖，典型的就是同步關鍵字synchronized，這裡我不在做過多的講解，感興趣的可以參考:http://www.cnblogs.com/xiohao/p/4151408.html另外一種是資料庫層次上的，比較典型的就是悲觀鎖和樂觀鎖。這裡我們重點講解的就是悲觀鎖（傳統的物理鎖）和樂觀鎖。我所在的公司是一個汽車電商平臺，所以訂單量非常的大，有時候做個促銷活動、發點優惠卷的時候，高併發就是一個不可忽視的問題。在架構設計設計上，採用的是樂觀鎖機制，通過‘version’版本欄位來控制併發問題，原理我貼一段SQL就清楚了

update t_order set qty=1 and version=version+1 where version=:version

這裡就是在更新操作時驗證當前訂單的版本號時候被其它事務改變否則就已報錯的方式，引導使用者重新查詢然後編輯。這樣講來比較簡單，但是就是這麼簡單就可以處理高併發的問題，對於資料庫和系統性能也不會有什麼影響。以外一種悲觀鎖機制，一般都是通過資料庫的特性來解決，資料庫的四大特性中有一個隔離性，意思就是說在同一個事物內操作的資料會被加上鎖，其它操作不能夠訪問。通過資料庫加鎖這種方式並不好，第一大量的鎖會給資料庫帶來很大的開銷，而且對於使用者而言沒有獲取鎖就不能操作資料，陷入等待的狀態，非常不友好。