1. 問題產生的原因？

同步和非同步--資料訪問次數增大-

1. 一般程式中，是如何處理併發和同步的？

1. 程式碼層次上，Java同步鎖-

       一種是程式碼層次上的，如java中的同步鎖，典型的就是同步關鍵字synchronized

1. 資料庫層次上，，比較典型的就是悲觀鎖和樂觀鎖。這裡我們重點講解的就是悲觀鎖（傳統的物理鎖）和樂觀鎖

悲觀鎖：--資料庫鎖機制---多讀少寫的情況下

對資料被外界呼叫使用修改保持保守悲觀的態度；

使整個資料再處理中，將資料處於鎖定狀態下；

往往是依靠資料庫提供的鎖機制

也只有資料庫層提供的鎖機制才能 真正保證資料訪問的排他性，

否則，即使在本系統 中實現了加鎖機制，也無法保證外部系 統不會修改資料

樂觀鎖：---版本記錄機制實現version--少寫，多度的情況下

大多是基於資料版本   Version ）記錄機制實現。何謂資料版本？即為資料增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通

過為資料庫表增加一個 “version” 欄位來 實現。 讀取出資料時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提 交資料的版本資料與資料

3，悲觀和樂觀的區別和聯絡

悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，可以使用版本號等機制。樂觀鎖適用於多讀的應用型別，這樣可以提高吞吐量，像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。

兩種鎖各有優缺點，不可認為一種好於另一種，像樂觀鎖適用於寫比較少的情況下，即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生衝突，上層應用會不斷的進行retry，這樣反倒是降低了效能，所以這種情況下用悲觀鎖就比較合適。

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

1. 常見的提高高併發下訪問的效率的手段

 首先要了解高併發的的瓶頸在哪裡？

     1、可能是伺服器網路頻寬不夠

     2.可能web執行緒連線數不夠

     3.可能資料庫連線查詢上不去。

     根據不同的情況，解決思路也不同。

像第一種情況可以增加網路頻寬，DNS域名解析分發多臺伺服器。

負載均衡，前置代理伺服器nginx、apache等等

資料庫查詢優化，讀寫分離，分表等等

   最後複製一些在高併發下面需要常常需要處理的內容:

儘量使用快取，包括使用者快取，資訊快取等，多花點記憶體來做快取，可以大量減少與資料庫的互動，提高效能。

用jprofiler等工具找出效能瓶頸，減少額外的開銷。

優化資料庫查詢語句，減少直接使用hibernate等工具的直接生成語句（僅耗時較長的查詢做優化）。

優化資料庫結構，多做索引，提高查詢效率。

統計的功能儘量做快取，或按每天一統計或定時統計相關報表，避免需要時進行統計的功能。

能使用靜態頁面的地方儘量使用，減少容器的解析（儘量將動態內容生成靜態html來顯示）。

解決以上問題後，使用伺服器叢集來解決單臺的瓶頸問題。

總 結：其實我們在開發中都很少考慮這種問題，直接都是先將功能實現，當一個程式設計師在幹到1到2年，就會感覺光實現功能不是最主要的，安全效能、質量等等才是 一個開發人員最該關心的。今天我所說的是高併發。

我的解決思路是：

1、採用分散式應用設計

2、分散式快取資料庫

3、程式碼優化