java 高併發如何優化
- 問題產生的原因?
同步和非同步--資料訪問次數增大-
- 一般程式中,是如何處理併發和同步的?
- 程式碼層次上,Java同步鎖-
一種是程式碼層次上的,如java中的同步鎖,典型的就是同步關鍵字synchronized
- 資料庫層次上,,比較典型的就是悲觀鎖和樂觀鎖。這裡我們重點講解的就是悲觀鎖(傳統的物理鎖)和樂觀鎖
悲觀鎖:--資料庫鎖機制---多讀少寫的情況下
對資料被外界呼叫使用修改保持保守悲觀的態度;
使整個資料再處理中,將資料處於鎖定狀態下;
往往是依靠資料庫提供的鎖機制
也只有資料庫層提供的鎖機制才能 真正保證資料訪問的排他性,
否則,即使在本系統 中實現了加鎖機制,也無法保證外部系 統不會修改資料
樂觀鎖:---版本記錄機制實現version--少寫,多度的情況下
大多是基於資料版本 Version )記錄機制實現。何謂資料版本?即為資料增加一個版本標識,在基於資料庫表的版本解決方案中,一般是通
過為資料庫表增加一個 “version” 欄位來 實現。 讀取出資料時,將此版本號一同讀出,之後更新時,對此版本號加一。此時,將提 交資料的版本資料與資料
3,悲觀和樂觀的區別和聯絡
悲觀鎖(Pessimistic Lock), 顧名思義,就是很悲觀,每次去拿資料的時候都認為別人會修改,所以每次在拿資料的時候都會上鎖,這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖。
樂觀鎖(Optimistic Lock), 顧名思義,就是很樂觀,每次去拿資料的時候都認為別人不會修改,所以不會上鎖,但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料,可以使用版本號等機制。樂觀鎖適用於多讀的應用型別,這樣可以提高吞吐量,像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。
兩種鎖各有優缺點,不可認為一種好於另一種,像樂觀鎖適用於寫比較少的情況下,即衝突真的很少發生的時候,這樣可以省去了鎖的開銷,加大了系統的整個吞吐量。但如果經常產生衝突,上層應用會不斷的進行retry,這樣反倒是降低了效能,所以這種情況下用悲觀鎖就比較合適。
- 案例分析
案例一:訂票系統案例,某航班只有一張機票,假定有1w個人開啟你的網站來訂票,問你如何解決併發問題(可擴充套件到任何高併發網站要考慮
的併發讀寫問題)
問題,1w個人來訪問,票沒出去前要保證大家都能看到有票,不可能一個人在看到票的時候別人就不能看了。到底誰能搶到,那得看這個人的“運氣”(網
絡快慢等)
其次考慮的問題,併發,1w個人同時點選購買,到底誰能成交?總共只有一張票。
首先我們容易想到和併發相關的幾個方案 :
鎖同步同步更多指的是應用程式的層面,多個執行緒進來,只能一個一個的訪問,java中指的是syncrinized關鍵字。鎖也有2個層面,一個是java中談到的對
象鎖,用於執行緒同步;另外一個層面是資料庫的鎖;如果是分散式的系統,顯然只能利用資料庫端的鎖來實現。
假定我們採用了同步機制或者資料庫物理鎖機制,如何保證1w個人還能同時看到有票,顯然會犧牲效能,在高併發網站中是不可取的。使用hibernate後我們
提出了另外一個概念:樂觀鎖、悲觀鎖(即傳統的物理鎖);
採用樂觀鎖即可解決此問題。樂觀鎖意思是不鎖定表的情況下,利用業務的控制來解決併發問題,這樣即保證資料的併發可讀性又保證儲存資料的排他性,保
證效能的同時解決了併發帶來的髒資料問題。
hibernate中如何實現樂觀鎖:
前提:在現有表當中增加一個冗餘欄位,version版本號, long型別
原理:
1)只有當前版本號》=資料庫表版本號,才能提交
2)提交成功後,版本號version ++
實現很簡單:在ormapping增加一屬性optimistic-lock="version"即可,以下是樣例片段
<hibernate-mapping>
<class name="com.insigma.stock.ABC" optimistic-lock="version" table="T_Stock" schema="STOCK">
案例二、股票交易系統、銀行系統,大資料量你是如何考慮的
首先,股票交易系統的行情表,每幾秒鐘就有一個行情記錄產生,一天下來就有(假定行情3秒一個) 股票數量×20×60*6 條記錄,一月下來這個表記錄數
量多大? oracle中一張表的記錄數超過100w後 查詢效能就很差了,如何保證系統性能?
再比如,中國移動有上億的使用者量,表如何設計?把所有用於存在於一個表麼?
所以,大數量的系統,必須考慮表拆分-(表名字不一樣,但是結構完全一樣),通用的幾種方式:(視情況而定)
1)按業務分,比如 手機號的表,我們可以考慮 130開頭的作為一個表,131開頭的另外一張表 以此類推
2)利用oracle的表拆分機制做分表
3)如果是交易系統,我們可以考慮按時間軸拆分,當日資料一個表,歷史資料弄到其它表。這裡歷史資料的報表和查詢不會影響當日交易。
當然,表拆分後我們的應用得做相應的適配。單純的or-mapping也許就得改動了。比如部分業務得通過儲存過程等
此外,我們還得考慮快取
這裡的快取,指的不僅僅是hibernate,hibernate本身提供了一級二級快取。這裡的快取獨立於應用,依然是記憶體的讀取,假如我們能減少資料庫頻繁的訪
問,那對系統肯定大大有利的。比如一個電子商務系統的商品搜尋,如果某個關鍵字的商品經常被搜,那就可以考慮這部分商品列表存放到快取(記憶體中
去),這樣不用每次訪問資料庫,效能大大增加。
簡單的快取大家可以理解為自己做一個hashmap,把常訪問的資料做一個key,value是第一次從資料庫搜尋出來的值,下次訪問就可以從map裡讀取,而不
讀資料庫;專業些的目前有獨立的快取框架比如memcached 等,可獨立部署成一個快取伺服器。
- 常見的提高高併發下訪問的效率的手段
首先要了解高併發的的瓶頸在哪裡?
1、可能是伺服器網路頻寬不夠
2.可能web執行緒連線數不夠
3.可能資料庫連線查詢上不去。
根據不同的情況,解決思路也不同。
像第一種情況可以增加網路頻寬,DNS域名解析分發多臺伺服器。
負載均衡,前置代理伺服器nginx、apache等等
資料庫查詢優化,讀寫分離,分表等等
最後複製一些在高併發下面需要常常需要處理的內容:
儘量使用快取,包括使用者快取,資訊快取等,多花點記憶體來做快取,可以大量減少與資料庫的互動,提高效能。
用jprofiler等工具找出效能瓶頸,減少額外的開銷。
優化資料庫查詢語句,減少直接使用hibernate等工具的直接生成語句(僅耗時較長的查詢做優化)。
優化資料庫結構,多做索引,提高查詢效率。
統計的功能儘量做快取,或按每天一統計或定時統計相關報表,避免需要時進行統計的功能。
能使用靜態頁面的地方儘量使用,減少容器的解析(儘量將動態內容生成靜態html來顯示)。
解決以上問題後,使用伺服器叢集來解決單臺的瓶頸問題。
總 結:其實我們在開發中都很少考慮這種問題,直接都是先將功能實現,當一個程式設計師在幹到1到2年,就會感覺光實現功能不是最主要的,安全效能、質量等等才是 一個開發人員最該關心的。今天我所說的是高併發。
我的解決思路是:
1、採用分散式應用設計
2、分散式快取資料庫
3、程式碼優化