海量數據存儲方案

參考原文：http://blog.csdn.net/xlgen157387/article/details/53230138

1、網站應用背景

開發一個網站的應用程序，當用戶規模比較小的時候，使用簡單的：一臺應用服務器+一臺數據庫服務器+一臺文件服務器，這樣的話徹底能夠解決一部分問題，也能夠經過堆硬件的方式來提升網站應用的訪問性能，固然，也要考慮成本的問題。

當問題的規模在經濟條件下經過堆硬件的方式解決不了的時候，咱們應該經過其餘的思路去解決問題，互聯網發展至今，已經提供了不少成熟的解決方案，但並非都具備適用性，你把淘寶的技術所有都搬過來也不必定達到如今淘寶的水平，道理很簡單。

固然，不少文章都在強調，一個網站的發展水平，是逐漸的演變過來的，並非一朝一夕的事情。雖然目前的狀況互聯網的泡沫愈來愈大，可是整個互聯網技術的發展確實爲咱們提供了方便快捷的上網體驗。下邊是一張早期的淘寶官網的界面：

目前，博主正在跟隨導師作一個創業項目，使用的技術是SSM+MySQL+Linux這些，可是因爲資金的限制和考慮到用戶羣體的特殊性，系統的架構無奈的選擇的就是最簡單的方式：一臺應用服務器、一臺數據庫服務器、一臺文件系統服務器，沒有用到高級的技術，也沒有用到分佈式部署的方案。下邊整理的是一些針對海量數據和高併發狀況下的解決方案，技術水平有限，歡迎留言指導。

2、針對海量數據和高併發的主要解決方案

海量數據的解決方案：

1. 使用緩存；
2. 頁面靜態化技術；
3. 數據庫優化；
4. 分離數據庫中活躍的數據；
5. 批量讀取和延遲修改；
6. 讀寫分離；
7. 使用NoSQL和Hadoop等技術；
8. 分佈式部署數據庫；
9. 應用服務和數據服務分離；
10. 使用搜索引擎搜索數據庫中的數據；
11. 進行業務的拆分；

高併發狀況下的解決方案：

1. 應用程序和靜態資源文件進行分離；
2. 頁面緩存；
3. 集羣與分佈式；
4. 反向代理；
5. CDN；

3、海量數據的解決方案

（1）使用緩存

網站訪問數據的特色大多數呈現爲「二八定律」：80%的業務訪問集中在20%的數據上。

例如：在某一段時間內百度的搜索熱詞可能集中在少部分的熱門詞彙上；新浪微博某一時期也可能你們普遍關注的主題也是少部分事件。

總的來講就是用戶只用到了總數據條目的一小部分，當網站發展到必定規模，數據庫IO操做成爲性能瓶頸的時候，使用緩存將這一小部分的熱門數據緩存在內存中是一個很不錯的選擇，不但能夠減輕數據庫的壓力，還能夠提升總體網站的數據訪問速度。

使用緩存的方式能夠經過程序代碼將數據直接保存到內存中，例如經過使用Map或者ConcurrentHashMap；另外一種，就是使用緩存框架：Redis、Ehcache、Memcache等。 
 
使用緩存框架的時候，咱們須要關心的就是何時建立緩存和緩存失效策略。

緩存的建立能夠經過不少的方式進行建立，具體也須要根據本身的業務進行選擇。例如，新聞首頁的新聞應該在第一次讀取數據的時候就進行緩存；對於點擊率比較高的文章，能夠將其文章內容進行緩存等。

內存資源有限，選擇如何建立緩存是一個值得思考的問題。另外，對於緩存的失效機制也是須要好好研究的，能夠經過設置失效時間的方式進行設置；也能夠經過對熱門數據設置優先級，根據不一樣的優先級設置不一樣的失效時間等；

須要注意的是，當咱們刪除一條數據的時候，咱們要考慮到刪除該條緩存，還要考慮在刪除該條緩存以前該條數據是否已經到達緩存失效時間等各類狀況！

使用緩存的時候還要考慮到緩存服務器發生故障時候如何進行容錯處理，是使用N多臺服務器緩存相同的數據，經過分佈式部署的方式對緩存數據進行控制，當一臺發生故障的時候自動切換到其餘的機器上去；仍是經過Hash一致性的方式，等待緩存服務器恢復正常使用的時候從新指定到該緩存服務器。Hash一致性的另外一個做用就是在分佈式緩存服務器下對數據進行定位，將數據分佈在不用緩存服務器上。關於數據緩存的Hash一致性也是一個比較打的問題，這裏只能大體描述一下，關於Hash一致性的瞭解，推薦一篇文章：http://blog.csdn.net/liu765023051/article/details/49408099

（2）頁面靜態化技術

使用傳統的JSP界面，前端界面的顯示是經過後臺服務器進行渲染後返回給前端遊覽器進行解析執行，以下圖： 

固然，如今提倡先後端分離，前端界面基本都是HTML網頁代碼，經過Angular JS或者NodeJS提供的路由向後端服務器發出請求獲取數據，而後在遊覽器對數據進行渲染，這樣在很大程度上下降了後端服務器的壓力。

還能夠將這些靜態的HTML、CSS、JS、圖片資源等放置在緩存服務器上或者CDN服務器上，通常使用最多的應該是CDN服務器或者Nginx服務器提供的靜態資源功能。

另外，在《高性能網站建設進階指南-Web開發者性能優化最佳實踐（口碑網前端團隊 翻譯）》這本書中，對網站性能的前端界面提供了一些很寶貴的經驗，以下：

所以，在這些靜態資源的處理上，選擇正確的處理方式仍是對總體網站性能仍是有很大幫助的！

（3）數據庫優化

數據庫優化是整個網站性能優化的最基礎的一個環節，由於，大多數網站性能的瓶頸都是開在數據庫IO操做上，雖然提供了緩存技術，可是對數據庫的優化仍是一個須要認真的對待。通常公司都有本身的DBA團隊，負責數據庫的建立，數據模型的確立等問題，不像咱們如今幾個不懂數據庫優化的人只能在網上找一篇篇數據庫優化的文章，本身去摸索，並無造成一個系統的數據庫優化思路。

對於數據庫的優化來講，是一種用技術換金錢的方式。數據庫優化的方式不少，常見的能夠分爲：數據庫表結構優化、SQL語句優化、分區、分表、索引優化、使用存儲過程代替直接操做等 。

一、表結構優化

對於數據庫的 開發規範與使用技巧以及設計和優化，前邊的時候總結了一些文章，這裏偷個懶直接放地址，有須要的能夠移步看一下： 
a) MySQL開發規範與使用技巧總結：http://blog.csdn.net/xlgen157387/article/details/48086607 
b) 在一個千萬級的數據庫查尋中，如何提升查詢效率？：http://blog.csdn.net/xlgen157387/article/details/44156679

另外，再設計數據庫表的時候需不須要建立外鍵，使用外鍵的好處之一能夠方便的進行級聯刪除操做，可是如今在進行數據業務操做的時候，咱們都經過事物的方式來保證數據讀取操做的一致性，我感受相比於使用外鍵關聯MySQL自動幫咱們完成級聯刪除的操做來講，仍是本身使用事物進行刪除操做來的更放心一些。固然可能也是有適用的場景，你們若有很好的建議，歡迎留言！

二、SQL優化

對於SQL的優化，主要是針對SQL語句處理邏輯的優化，並且還要根據索引進行配合使用。另外，對於SQL語句的優化咱們能夠針對具體的業務方法進行優化，咱們能夠將執行業務邏輯操做的數據庫執行時間記錄下來，來進行有針對性的優化，這樣的話效果仍是很不錯的！例以下圖，展現了一條數據庫操做執行調用的時間：

關於SQL優化的一些建議，之前整理了一些，還請移步查看：

a) 19個MySQL性能優化要點解析：http://blog.csdn.net/xlgen157387/article/details/50735269

b) MySQL批量SQL插入各類性能優化：http://blog.csdn.net/xlgen157387/article/details/50949930

• 分表

分表是將一個大表按照必定的規則分解成多張具備獨立存儲空間的實體表，咱們能夠稱爲子表，每一個表都對應三個文件，MYD數據文件，.MYI索引文件，.frm表結構文件。這些子表能夠分佈在同一塊磁盤上，也能夠在不一樣的機器上。數據庫讀寫操做的時候根據事先定義好的規則獲得對應的子表名，而後去操做它。

例如：用戶表 
用戶的角色有不少種，能夠經過枚舉類型的方式將用戶分爲不一樣類別category：學生、教師、企業等 ，這樣的話，咱們就能夠根據類別category來對數據庫進行分表，這樣的話每次查詢的時候現根據用戶的類型鎖定一個較小的範圍。

不過度表以後，若是須要查詢完整的順序就須要使用多表操做了。

• 分區

數據庫分區是一種物理數據庫設計技術，DBA和數據庫建模人員對其至關熟悉。雖然分區技術能夠實現不少效果，但其主要目的是爲了在特定的SQL操做中減小數據讀寫的總量以縮減響應時間。

分區和分表類似，都是按照規則分解表。不一樣在於分表將大表分解爲若干個獨立的實體表，而分區是將數據分段劃分在多個位置存放，能夠是同一塊磁盤也能夠在不一樣的機器。分區後，表面上仍是一張表，但數據散列到多個位置了。數據庫讀寫操做的時候操做的仍是大表名字，DMS自動去組織分區的數據。

當一張表中的數據變得很大的時候，讀取數據，查詢數據的效率很是低下，很容易的就是講數據分到不一樣的數據表中進行保存，可是這樣分表以後會使得操做起來比較麻煩，由於，將同類的數據分別放在不一樣的表中的話，在搜索數據的時候須要便利查詢這些表中的數據。想進行CRUD操做還須要先找到對應的全部表，若是涉及到不一樣的表的話還要進行跨表操做，這樣操做起來仍是很麻煩的。

使用分區的方式能夠解決這個問題，分區是將一張表中的數據按照必定的規則分到不一樣的區中進行保存，這樣進行數據查詢的時候若是數據的範圍在同一個區域內那麼就能夠支隊一個區中的數據進行操做，這樣的話操做起來數據量更少，操做速度更快，並且該方法是對程序透明的，程序不須要進行任何的修改。(PS:上次面試中我提出的，按照行政區做爲數據庫的分區依據)

• 索引優化

索引的大體原理是在數據發生變化的時候就預先按指定字段的順序排列後保存到一個相似表的結構中，這樣在查找索引字段爲條件記錄時就能夠很快地從索引中找到對應記錄的指針並從表中獲取到相應的數據，這樣速度是很快地。

不過，雖然查詢的效率大大提升了，可是在進行增刪改的時候，由於數據的變化都須要更新相應的索引，也是一種資源的浪費。

關於使用索引的問題，對待不一樣的問題，仍是須要進行不一樣的討論，根據具體的業務需求選擇合適的索引對性能的提升效果是很明顯的一個舉措！

推薦文章閱讀：

a) 數據庫索引的做用和優勢缺點以及索引的11中用法：http://blog.csdn.net/xlgen157387/article/details/45030829

b) 數據庫索引原理：http://blog.csdn.net/kennyrose/article/details/7532032

• 使用存儲過程代替直接操做

存儲過程（Stored Procedure）是在大型數據庫系統中，一組爲了完成特定功能的SQL 語句集，存儲在數據庫中，通過第一次編譯後再次調用不須要再次編譯，用戶經過指定存儲過程的名字並給出參數（若是該存儲過程帶有參數）來執行它。存儲過程是數據庫中的一個重要對象，任何一個設計良好的數據庫應用程序都應該用到存儲過程。

在操做過程比較複雜而且調用頻率比較高的業務中，能夠將編寫好的sql語句用存儲過程的方式來代替，使用存儲過程只須要進行一次變異，並且能夠在一個存儲過程裏作一些複雜的操做。

（4）分離數據庫中活躍的數據

正如前邊提到的「二八定律」同樣，網站的數據雖然不少，可是常常被訪問的數據仍是有限的，所以能夠講這些相對活躍的數據進行分離出來單獨進行保存來提升處理效率。

其實前邊使用緩存的思想就是一個很明顯的分離數據庫中活躍的數據的使用案例，將熱門數據緩存在內存中。

還有一種場景就是，例如一個網站的所用註冊用戶量很大千萬級別，可是常常登陸的用戶只有百萬級別，剩下的基本都是很長時間都沒有進行登陸操做，若是不把這些「殭屍用戶」單獨分離出去，那麼咱們每次查詢其餘登陸用戶的時候，就白白浪費了這些殭屍用戶的查詢操做。

（5）批量讀取和延遲修改

批量讀取和延遲修改的原理是經過減小操做數據庫的操做來提升效率。

批量讀取是將屢次查詢合併到一次中進行讀取，由於每個數據庫的請求操做都須要連接的創建和連接的釋放，仍是佔用一部分資源的，批量讀取能夠經過異步的方式進行讀取。

延遲修改是對於一些高併發的而且修改頻繁修改的數據，在每次修改的時候首先將數據保存到緩存中，(後期)而後定時將緩存中的數據保存到數據庫中，程序能夠在讀取數據時能夠同時讀取數據庫中和緩存中的數據。

（6） 讀寫分離

讀寫分離的實質是將應用程序對數據庫的讀寫操做分配到多個數據庫服務器上，從而下降單臺數據庫的訪問壓力。

讀寫分離通常經過配置主從數據庫的方式，數據的讀取來自從庫，對數據庫增長修改刪除操做主庫。

相關文章請移步觀看： 
a) MySQL5.6 數據庫主從（Master/Slave）同步安裝與配置詳解：http://blog.csdn.net/xlgen157387/article/details/51331244 
b) MySQL主從複製的常見拓撲、原理分析以及如何提升主從複製的效率總結:http://blog.csdn.net/xlgen157387/article/details/52451613

（7）使用NoSQL和Hadoop等技術

NoSQL是一種非結構化的非關係型數據庫，因爲其靈活性，突破了關係型數據庫的條條框框，能夠靈活的進行操做，另外，由於NoSQL經過多個塊存儲數據的特色，其操做大數據的速度也是至關快的。

（8）分佈式部署數據庫

任何強大的單一服務器都知足不了大型網站持續增加的業務需求。數據庫經過讀寫分離以後將一臺數據庫服務器拆分爲兩臺或者多臺數據庫服務器，可是仍然知足不了持續增加的業務需求。分佈式部署數據庫是將網站數據庫拆分的最後手段，只有在單表數據規模很是龐大的時候才使用。

分佈式部署數據庫是一種很理想的狀況，分佈式數據庫是將表存放在不一樣的數據庫中而後再放到不一樣的數據庫中，這樣在處理請求的時候，若是須要調用多個表，則可讓多臺服務器同時處理，從而提升處理效率。

分佈式數據庫簡單的架構圖以下：

（9）應用服務和數據服務分離

應用服務器和數據庫服務器進行分離的目的是爲了根據應用服務器的特色和數據庫服務器的特色進行底層的優化，這樣的話可以更好的發揮每一臺服務器的特性，數據庫服務器固然是有必定的磁盤空間，而應用服務器相對不須要太大的磁盤空間，這樣的話進行分離是有好處的，也能防止一臺服務器出現問題連帶的其餘服務也不可使用。

（10）使用搜索引擎搜索數據庫中的數據

使用搜索引擎這種非數據庫查詢技術對網站應用的可伸縮分佈式特性具備更好的支持。

常見的搜索引擎如Solr經過一種反向索引的方式，維護關鍵字到文檔的映射關係，相似於咱們使用《新華字典》進行搜索一個關鍵字，首先應該是看字典的目錄進行查找而後定位到具體的位置。

搜索引擎經過維護必定的關鍵字到文檔的映射關係，可以快速的定位到須要查找的數據，相比於傳統的數據庫搜索的方式，效率仍是很高的。

目前一種比較火的ELK stack技術，仍是值得學習的。

一篇關於Solr與MySQL查詢性能對比文章： 
Solr與MySQL查詢性能對比：http://www.cnblogs.com/luxiaoxun/p/4696477.html?utm_source=tuicool&utm_medium=referral

（11） 進行業務的拆分

爲何進行業務的拆分，歸根結底上仍是使用的仍是講不通的業務數據表部署到不用的服務器上，分別查找對應的數據以知足網站的需求。各個應用之間用過指定的URL鏈接獲取不一樣的服務，

例如一個大型的購物網站就會將首頁、商鋪、訂單、買家、賣家等拆分爲不通的子業務，一方面將業務模塊分歸爲不一樣的團隊進行開發，另一方面不一樣的業務使用的數據庫表部署到不通的服務器上，體現到拆分的思想，當一個業務模塊使用的數據庫服務器發生故障也不會影響其餘業務模塊的數據庫正常使用。另外，當其中一個模塊的訪問量激增的時候還能夠動態的擴展這個模塊使用到的數據庫的數量從而知足業務的需求。

高併發狀況下的解決方案

（1）應用程序和靜態資源文件進行分離

所謂的靜態資源就是咱們網站中用到的Html、Css、Js、Image、Video、Gif等靜態資源。應用程序和靜態資源文件進行分離也是常見的先後端分離的解決方案，應用服務只提供相應的數據服務，靜態資源部署在指定的服務器上（Nginx服務器或者是CDN服務器上），前端界面經過Angular JS或者Node JS提供的路由技術訪問應用服務器的具體服務獲取相應的數據在前端遊覽器上進行渲染。這樣能夠在很大程度上減輕後端服務器的壓力。

例如，百度主頁使用的圖片就是單獨的一個域名服務器上進行部署的

（2）頁面緩存

頁面緩存是將應用生成的不多發生數據變化的頁面緩存起來，這樣就不須要每次都從新生成頁面了，從而節省大量CPU資源，若是將緩存的頁面放到內存中速度就更快。

可使用Nginx提供的緩存功能，或者可使用專門的頁面緩存服務器Squid。

（3）集羣與分佈式

（4）反向代理

參考文章請移步至： 
http://blog.csdn.net/xlgen157387/article/details/49781487

（5）CDN

CDN服務器實際上是一種集羣頁面緩存服務器，其目的就是儘早的返回用戶所須要的數據，一方面加速用戶訪問速度，另外一方面也減輕後端服務器的負載壓力。

CDN的全稱是Content Delivery Network，即內容分發網絡。其基本思路是儘量避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。

CDN經過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統可以實時地根據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容，解決 Internet網絡擁擠的情況，提升用戶訪問網站的響應速度。

也就是說CDN服務器是部署在網絡運行商的機房，提供的離用戶最近的一層數據訪問服務，用戶在請求網站服務的時候，能夠從距離用戶最近的網絡提供商機房獲取數據。電信的用戶會分配電信的節點，聯通的會分配聯通的節點。

CDN分配請求的方式是特殊的，不是普通的負載均衡服務器來分配的那種，而是用專門的CDN域名解析服務器在解析與名的時候就分配好的。

CDN結構圖以下所示：

總結

文章提到的幾點並無詳細的介紹，如須要對其中的一種方式進行研究，能夠自行去找資源學習研究，這裏只起到拋磚引玉的做用。固然對於大型網站應用之海量數據和高併發解決方案不侷限於這些技巧或技術，還有不少成熟的解決方案，有須要的能夠自行了解。

特此說明：本文的配圖來自《網站架構及其演變過程–韓路彪》，多謝原做者提供的精美配圖，而且文章的結構大體也參考了做者的思路，只不過內容是本身的一些經驗和學習到的東西進行整理的。

---

參考書籍或文章：

一、《網站架構及其演變過程–韓路彪》 
二、《大型網站技術架構之核心原理與參考案例–李智慧》 
三、部分專業名詞簡介來自百度百科 
四、http://cio.chinabyte.com/428/13106928.shtml 
五、http://blog.codinglabs.org/articles/consistent-hashing.html

還有一些在整理的時候，忘記記錄鏈接，還請你們見諒！