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">
2,股票交易系統、銀行系統,大數據量你是如何考慮的
首先,股票交易系統的行情表,每幾秒鐘就有一個行情記錄產生,一天下來就有(假定行情3秒一個) 股票數量×20×60*6 條記錄,一月下來這個表記錄數量多大? oracle中一張表的記錄數超過100w後 查詢性能就很差了,如何保證系統性能?
再比如,中國移動有上億的用戶量,表如何設計? 把所有用於存在於一個表麼?
所以,大數量的系統,必須考慮表拆分-(表名字不一樣,但是結構完全一樣),通用的幾種方式:(視情況而定)
1)按業務分,比如 手機號的表,我們可以考慮 130開頭的作爲一個表,131開頭的另外一張表 以此類推
2)利用oracle的表拆分機制做分表
3)如果是交易系統,我們可以考慮按時間軸拆分,當日數據一個表,歷史數據弄到其它表。這裏歷史數據的報表和查詢不會影響當日交易。
當然,表拆分後我們的應用得做相應的適配。單純的or-mapping也許就得改動了。比如部分業務得通過存儲過程等
3)此外,我們還得考慮緩存
這裏的緩存,指的不僅僅是hibernate,hibernate本身提供了一級二級緩存。這裏的緩存獨立於應用,依然是內存的讀取,假如我們能減少數據庫頻繁的訪問,那對系統肯定大大有利的。比如一個電子商務系統的商品搜索,如果某個關鍵字的商品經常被搜,那就可以考慮這部分商品列表存放到緩存(內存中去),這樣不用每次訪問數據庫,性能大大增加。
簡單的緩存大家可以理解爲自己做一個hashmap,把常訪問的數據做一個key,value是第一次從數據庫搜索出來的值,下次訪問就可以從map裏讀取,而不讀數據庫;專業些的目前有獨立的緩存框架 比如memcached 等,可獨立部署成一個緩存服務器。