舉幾個大資料的例子

標籤：style   color   io   使用   java   ar   for   資料   問題   

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 等，可獨立部署成一個快取服務器。

 

 

舉幾個大資料的例子