文章轉於 http://www.cnblogs.com/xiohao/p/4385508.html
1、常見併發同步案例分析
案例一:訂票系統案例，某航班只有一張機票，假定有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 等，可獨立部署成一個緩存服務器。
2、常見的提高高併發下訪問的效率的手段
首先要了解高併發的的瓶頸在哪裏？
1、可能是服務器網絡帶寬不夠
2.可能web線程連接數不夠
3.可能數據庫連接查詢上不去。
根據不同的情況，解決思路也不同。
像第一種情況可以增加網絡帶寬，DNS域名解析分發多臺服務器。
負載均衡，前置代理服務器nginx、apache等等
數據庫查詢優化，讀寫分離，分表等等
最後複製一些在高併發下面需要常常需要處理的內容:
儘量使用緩存，包括用戶緩存，信息緩存等，多花點內存來做緩存，可以大量減少與數據庫的交互，提高性能。
用jprofiler等工具找出性能瓶頸，減少額外的開銷。
優化數據庫查詢語句，減少直接使用hibernate等工具的直接生成語句（僅耗時較長的查詢做優化）。
優化數據庫結構，多做索引，提高查詢效率。
統計的功能儘量做緩存，或按每天一統計或定時統計相關報表，避免需要時進行統計的功能。
能使用靜態頁面的地方儘量使用，減少容器的解析（儘量將動態內容生成靜態html來顯示）。
解決以上問題後，使用服務器集羣來解決單臺的瓶頸問題。