架構的演化路線

 

演變路線總結

1. 單機Mysql的美好時代
2. 緩存+mysql+垂直拆分
3. mysql主從讀寫分離
4. 分表分庫+水平拆分+mysql集羣
5. 大數據狀態（淘寶等網站架構）

 

1.單機mysql

 

 

瓶頸

1. 數據量總大小，一個機器放不下時
2. 數據的索引（B+Tree) ，一個機器的內存和磁盤放不下時
3. 訪問量（讀寫混合），一個實例不能承受時（單表300萬數據，就要開始進入下一階段）

2.緩存+mysql+垂直拆分（單單分表）

相比第一個架構，作了如下優化：

1. 緩存技術緩解數據庫壓力
2. 優化數據庫的結構和索引

 

瓶頸

讀寫集中在一個數據庫上，漸漸也會到達瓶頸，由於緩存只能緩解數據庫的讀取壓力

3.mysql主從複製+讀寫分離 

相比第二個架構，作了如下優化：

1. 主從複製+讀寫分離=>數據有備份更安全了，讀寫更快了

 

瓶頸

1. 主庫寫壓力出現瓶頸 

4.分表分庫+水平拆分+mysql集羣

相比第三個架構，作了如下優化：

1. 用InnoDB引擎（行鎖）替代MyISAM（表鎖）
2. 分表分庫+水平拆分
   注：垂直拆分與水平拆分
3. 用算法作導航，通常把高度活躍數據放在一個庫，冷門的放另外一個庫
4. mysql集羣
   注：分佈式，集羣，子系統  
   　　分佈式：不一樣的多臺服務器上面部署不一樣服務模塊（工程）,他們之間經過RPC/Rmi之間通訊和調用，對外提供服務和組內協做
   　　集羣：不一樣的多臺的服務器上部署相同的服務模塊，經過分佈式調度軟件進行統一的調度，對外提供服務和訪問
   　　子系統：不一樣的多臺服務器上部署不一樣服務模塊，而且每一個子系統都是一個單獨完善的系統

 

5.大數據高流量網站架構

1. 集羣分類（例如專門放圖片的集羣，專門放流媒體的一個集羣）

 

 擴展：大數據分析的起源=>數據倉庫的背景

基本上，架構到了必定規模以後。就意味着數據量大，這就須要充分利用這些數據以產生經濟效益，這時候就得多部署一個「數據倉庫」
數據倉庫和數據庫的區別：
數據庫：傳統的關係型數據庫的主要應用，主要是基本的、平常的事務處理，例如銀行交易。
數據倉庫：數據倉庫系統的主要應用主要是OLAP（On-Line Analytical Processing），支持複雜的分析操做，側重決策支持，而且提供直觀易懂的查詢結果

基本每家電商公司都會經歷，從只須要業務數據庫到要數據倉庫的階段。

• 電商早期啓動很是容易，入行門檻低。找個外包團隊，作了一個能夠下單的網頁前端 + 幾臺服務器 + 一個MySQL，就能開門迎客了。這比如手工做坊時期。

• 第二階段，流量來了，客戶和訂單都多起來了，普通查詢已經有壓力了，這個時候就須要升級架構變成多臺服務器和多個業務數據庫（量大+分庫分表），這個階段的業務數字和指標還能夠勉強從業務數據庫裏查詢。初步進入工業化。

• 第三個階段，通常須要 3-5 年左右的時間，隨着業務指數級的增加，數據量的會陡增，公司角色也開始多了起來，開始有了 CEO、CMO、CIO，你們須要面臨的問題愈來愈複雜，愈來愈深刻。高管們關心的問題，從最初很是粗放的：「昨天的收入是多少」、「上個月的 PV、UV 是多少」，逐漸演化到很是精細化和具體的用戶的集羣分析，特定用戶在某種使用場景中，例如「20~30歲女性用戶在過去五年的第一季度化妝品類商品的購買行爲與公司進行的促銷活動方案之間的關係」。

這類很是具體，且可以對公司決策起到關鍵性做用的問題，基本很難從業務數據庫從調取出來。緣由在於：

1. 業務數據庫中的數據結構是爲了完成交易而設計的，不是爲了而查詢和分析的便利設計的。
2. 業務數據庫大可能是讀寫優化的，即又要讀（查看商品信息），也要寫（產生訂單，完成支付）。所以對於大量數據的讀（查詢指標，通常是複雜的只讀類型查詢）是支持不足的。

而怎麼解決這個問題，此時咱們就須要創建一個數據倉庫了，公司也算開始進入信息化階段了。數據倉庫的做用在於：

1. 數據結構爲了分析和查詢的便利；
2. 只讀優化的數據庫，即不須要它寫入速度多麼快，只要作大量數據的複雜查詢的速度足夠快就好了。

那麼在這裏前一種業務數據庫（讀寫都優化）的是業務性數據庫，後一種是分析性數據庫，即數據倉庫。