大數據下高並發的處理詳解

對於我們開發的網站，如果網站的訪問量非常大的話，那么我們就需要考慮相關的並發訪問問題了。而並發問題是絕大部分的程序員頭疼的問題，但話又說回來了，既然逃避不掉，那我們就要想想應對措施，今天我們就一起討論一下常見的並發和同步吧。
首先為了更好的理解並發和同步，我們需要首先明白兩個重要的概念：同步和異步

同步和異步的區別和聯系

所謂同步，就是一個線程執行一個方法或函數的時候，會阻塞其它線程，其他線程要等待它執行完畢才能繼續執行。
異步，就是多個線程之間沒有阻塞，多個線程同時執行。
通俗一點來說，同步就是一件事一件事的做，異步就是做一件事，不影響做其他事情。
例如：吃飯和說話，只能一件一件的來，因為只有一張嘴。
但是吃飯和聽音樂是異步的，可以一起進行，因為聽音樂並不影響我們吃飯。

對於Java程序員來說，Synchronized最為熟悉了，如果它作用於一個類的話，那么就是一個線程訪問類的方法時，其他線程就會阻塞，相反，如果沒有這個關鍵字來修飾的話，不同線程就可以在同一時間訪問同一個方法，這就是異步。

臟讀和不可重復讀

臟讀
臟讀就是指當一個事務正在訪問數據，並且對數據進行了修改，而這種修改還沒有提交到數據庫中，這是，另外一個事務也訪問這個數據，然后使用了這個數據。因為這個數據是還沒有提交的數據，那么另外一個事務讀取的這個數據是臟數據(Dirty Data)，依據臟數據所做的操作可能是不正確的。

不可重復讀
在第一個事務讀取數據后，第二個事務對數據進行了修改，導致第一個事務結束前再訪問這個數據的時候，會發現兩次讀取到的數據是不一樣的，因此稱為不可重復讀。

如何處理並發和同步

今天講的如何處理並發和同同步問題主要是通過鎖機制。
我們需要明白，鎖機制有兩個層面。
一種是代碼層次上的，如果Java中的同步鎖Synchronized，另一種是數據庫層次上的，比較典型的就是悲觀鎖(傳統的物理鎖)和樂觀鎖

悲觀鎖
悲觀鎖，正如其名，它指的是對數據被外界(包括本系統當前的其他事務，以及來自外部系統的事務處理)修改持保守態度。因此，在這個數據處理過程中，將數據處於鎖定狀態。
悲觀鎖的實現，往往依靠數據庫提供的鎖機制(也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據)。
一個典型的倚賴數據庫的悲觀鎖調用：

select * from account where name=”Erica” for update 

這條 sql 語句鎖定了 account 表中所有符合檢索條件（ name=”Erica” ）的記錄。
本次事務提交之前（事務提交時會釋放事務過程中的鎖），外界無法修改這些記錄。
Hibernate 的悲觀鎖，也是基於數據庫的鎖機制實現。
下面的代碼實現了對查詢記錄的加鎖：

1 2 3 4

String hqlStr ="from TUser as user where user.name='Erica'"; Query query = session.createQuery(hqlStr); query.setLockMode("user",LockMode.UPGRADE); // 加鎖 List userList = query.list();// 執行查詢，獲取數據

觀察運行期 Hibernate 生成的 SQL 語句：

1	select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name='Erica' ) for update

這里 Hibernate 通過使用數據庫的 for update 子句實現了悲觀鎖機制。
Hibernate 的加鎖模式有：

1 2 3 4 5 6 7 8 9 10 11 12

LockMode.NONE ： 無鎖機制。 LockMode.WRITE ： Hibernate 在 Insert 和 Update 記錄的時候會自動獲取 LockMode.READ ： Hibernate 在讀取記錄的時候會自動獲取。 以上這三種鎖機制一般由 Hibernate 內部使用，如 Hibernate 為了保證 Update過程中對象不會被外界修改，會在 save 方法實現中自動為目標對象加上 WRITE 鎖。 LockMode.UPGRADE ：利用數據庫的 for update 子句加鎖。 LockMode.UPGRADE_NOWAIT ： Oracle 的特定實現，利用 Oracle 的 for update nowait 子句實現加鎖。 上面這兩種鎖機制是我們在應用層較為常用的，加鎖一般通過以下方法實現： Criteria.setLockMode Query.setLockMode Session.lock

注意，只有在查詢開始之前（也就是 Hiberate 生成 SQL 之前）設定加鎖，才會真正通過數據庫的鎖機制進行加鎖處理，否則，數據已經通過不包含 for update子句的 Select SQL 加載進來，所謂數據庫加鎖也就無從談起。

為了更好的理解select… for update的鎖表的過程，本人將要以mysql為例，進行相應的講解
開啟兩個測試窗口，其中一個窗口A執行命令：

1 2 3 4 5 6 7 8 9 10 11

mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> select * from empinfo for update; +--------+----------+------+---------+ | Fempno | Fempname | Fage | Fsalary | +--------+----------+------+---------+ | 1233 | sdfs | NULL | NULL | | 324234 | sdf | 38 | 12121 | +--------+----------+------+---------+ 2 rows in set (0.00 sec)

這個時候打開窗口B執行更新或插入操作：

1	mysql> update empinfo set Fage=12 where Fempno=1233;

這個時候窗口B的更新或插入操作不會執行，會一直在等待，直到A窗口的事務提交了：

1 2	mysql> commit; Query OK, 0 rows affected (0.00 sec)

B窗口的更新才開始執行。
那么for update到底鎖定表還是行呢？

由於InnoDB預設是Row-Level Lock，所以只有「明確」的指定主鍵，MySQL才會執行Row lock (只鎖住被選取的資料例) ，否則MySQL將會執行Table Lock (將整個資料表單給鎖住)。
例1: (明確指定主鍵，並且有此筆資料，row lock)

1 2 3

SELECT * FROM products WHERE id='3' FOR UPDATE; SELECT * FROM products WHERE id='3' and type=1 FOR UPDATE;

例2: (明確指定主鍵，若查無此筆資料，無lock)

SELECT * FROM products WHERE id='-1' FOR UPDATE; 

例3: (無主鍵，table lock)

SELECT * FROM products WHERE name='Mouse' FOR UPDATE; 

例4: (主鍵不明確，table lock)

SELECT * FROM products WHERE id<>'3' FOR UPDATE; 

例5: (主鍵不明確，table lock)

SELECT * FROM products WHERE id LIKE '3' FOR UPDATE; 

注1: FOR UPDATE僅適用於InnoDB，且必須在交易區塊(BEGIN/COMMIT)中才能生效。
注2: 要測試鎖定的狀況，可以利用MySQL的Command Mode ，開二個視窗來做測試。在MySql 5.0中測試確實是這樣的
另外：MyAsim 只支持表級鎖，InnerDB支持行級鎖 添加了(行級鎖/表級鎖)鎖的數據不能被其它事務再鎖定，也不被其它事務修改(修改、刪除） 。是表級鎖時，不管是否查詢到記錄，都會鎖定表。
到這里，悲觀鎖機制你應該了解一些了吧~

樂觀鎖
相對悲觀鎖而言，樂觀鎖機制采取了更加寬松的加鎖機制。悲觀鎖大多數情況下依 靠數據庫的鎖機制實現，以保證操作最大程度的獨占性。但隨之而來的就是數據庫 性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數據的基礎上進 行修改時（如更改用戶帳戶余額），如果采用悲觀鎖機制，也就意味着整個操作過 程中（從操作員讀出數據、開始修改直至提交修改結果的全過程，甚至還包括操作 員中途去煮咖啡的時間），數據庫記錄始終處於加鎖狀態，可以想見，如果面對幾 百上千個並發，這樣的情況將導致怎樣的后果。樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於數據版本 Version ）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基於數據庫表的版本解決方案中，一般是通過為數據庫表增加一個 “version” 字段來 實現。 讀取出數據時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提 交數據的版本數據與數據庫表對應記錄的當前版本信息進行比對，如果提交的數據 版本號大於數據庫表當前版本號，則予以更新，否則認為是過期數據。
假如數據庫中賬戶余額為100，version為1，操作員A讀出余額，並修改為50，而在A操作的同時操作員B也讀出了賬戶余額100，並修改為80，A完成了操作錄入系統，version從1加上1變為2，余額修改為50，操作員B也提交了記錄，version也變為2，余額則是80，但是此時數據庫發現，B提交的version為2，當前版本也是2，不滿足 “ 提交版本必須大於記 錄當前版本才能執行更新 “ 的樂觀鎖策略。因此，操作員 B 的提交被駁回。 這樣，就避免了操作員 B 用基於version=1 的舊數據修改的結果覆蓋操作 員 A 的操作結果的可能。 從上面的例子可以看出，樂觀鎖機制避免了長事務中的數據庫加鎖開銷（操作員 A和操作員 B 操作過程中，都沒有對數據庫數據加鎖），大大提升了大並發量下的系 統整體性能表現。 需要注意的是，樂觀鎖機制往往基於系統中的數據存儲邏輯，因此也具備一定的局 限性，如在上例中，由於樂觀鎖機制是在我們的系統中實現，來自外部系統的用戶 余額更新操作不受我們系統的控制，因此可能會造成臟數據被更新到數據庫中。在 系統設計階段，我們應該充分考慮到這些情況出現的可能性，並進行相應調整（如 將樂觀鎖策略在數據庫存儲過程中實現，對外只開放基於此存儲過程的數據更新途 徑，而不是將數據庫表直接對外公開）。 Hibernate 在其數據訪問引擎中內置了樂觀鎖實現。如果不用考慮外部系統對數 據庫的更新操作，利用 Hibernate 提供的透明化樂觀鎖實現，將大大提升我們的 生產力。

Hibernate使用樂觀鎖我只說一下注解的方式：
在Entity中加入以下代碼

1 2 3 4 5 6 7 8 9 10

private int version; @Version @Column(name = "version",length = 11) public int getVersion() { return version; } public void setVersion(int version) { this.version = version; }

這樣就可以輕松實現hibernate樂觀鎖方式。

常見並發同步案例分析

案例一:訂票系統案例
某航班只有一張機票，假定有1w個人打開你的網站來訂票，問你如何解決並發問題(可擴展到任何高並發網站要考慮的並發讀寫問題)
問題，1w個人來訪問，票沒出去前要保證大家都能看到有票，不可能一個人在看到票的時候別人就不能看了。到底誰能搶到，那得看這個人的“運氣”（網絡快慢等）
其次考慮的問題，並發，1w個人同時點擊購買，到底誰能成交？總共只有一張票。
首先我們容易想到和並發相關的幾個方案 ：
鎖同步同步更多指的是應用程序的層面，多個線程進來，只能一個一個的訪問，java中指的是syncrinized關鍵字。鎖也有2個層面，一個是java中談到的對象鎖，用於線程同步；另外一個層面是數據庫的鎖；如果是分布式的系統，顯然只能利用數據庫端的鎖來實現。
假定我們采用了同步機制或者數據庫物理鎖機制，如何保證1w個人還能同時看到有票，顯然會犧牲性能，在高並發網站中是不可取的。使用hibernate后我們提出了另外一個概念：樂觀鎖、悲觀鎖（即傳統的物理鎖）；
采用樂觀鎖即可解決此問題。樂觀鎖意思是不鎖定表的情況下，利用業務的控制來解決並發問題，這樣即保證數據的並發可讀性又保證保存數據的排他性，保證性能的同時解決了並發帶來的臟數據問題。
hibernate中如何實現樂觀鎖：
前提：在現有表當中增加一個冗余字段，version版本號, long類型
原理：
1）只有當前版本號》=數據庫表版本號，才能提交
2）提交成功后，版本號version ++

閱讀全文：http://click.aliyun.com/m/14341/