大型網(wǎng)站應(yīng)用之海量數(shù)據(jù)和高并發(fā)解決方案總結(jié)一二

一、網(wǎng)站應(yīng)用背景

開發(fā)一個網(wǎng)站的應(yīng)用程序，當(dāng)用戶規(guī)模比較小的時候，使用簡單的：一臺應(yīng)用服務(wù)器+一臺數(shù)據(jù)庫服務(wù)器+一臺文件服務(wù)器，這樣的話完全可以解決一部分問題，也可以通過堆硬件的方式來提高網(wǎng)站應(yīng)用的訪問性能，當(dāng)然，也要考慮成本的問題。

當(dāng)問題的規(guī)模在經(jīng)濟條件下通過堆硬件的方式解決不了的時候，我們應(yīng)該通過其他的思路去解決問題，互聯(lián)網(wǎng)發(fā)展至今，已經(jīng)提供了很多成熟的解決方案，但并不是都具有適用性，你把淘寶的技術(shù)全部都搬過來也不一定達到現(xiàn)在淘寶的水平，道理很簡單。

當(dāng)然，很多文章都在強調(diào)，一個網(wǎng)站的發(fā)展水平，是逐漸的演變過來的，并不是一朝一夕的事情。雖然目前的情況互聯(lián)網(wǎng)的泡沫越來越大，但是整個互聯(lián)網(wǎng)技術(shù)的發(fā)展確實為我們提供了方便快捷的上網(wǎng)體驗。下邊是一張早期的淘寶官網(wǎng)的界面：

目前，博主正在跟隨導(dǎo)師做一個創(chuàng)業(yè)項目，使用的技術(shù)是SSM+MySQL+Linux這些，但是由于資金的限制和考慮到用戶群體的特殊性，系統(tǒng)的架構(gòu)無奈的選擇的就是最簡單的方式：一臺應(yīng)用服務(wù)器、一臺數(shù)據(jù)庫服務(wù)器、一臺文件系統(tǒng)服務(wù)器，沒有用到高級的技術(shù)，也沒有用到分布式部署的方案。下邊整理的是一些針對海量數(shù)據(jù)和高并發(fā)情況下的解決方案，技術(shù)水平有限，歡迎留言指導(dǎo)。

二、針對海量數(shù)據(jù)和高并發(fā)的主要解決方案

海量數(shù)據(jù)的解決方案：

• 使用緩存；
• 頁面靜態(tài)化技術(shù)；
• 數(shù)據(jù)庫優(yōu)化；
• 分離數(shù)據(jù)庫中活躍的數(shù)據(jù)；
• 批量讀取和延遲修改；
• 讀寫分離；
• 使用NoSQL和Hadoop等技術(shù)；
• 分布式部署數(shù)據(jù)庫；
• 應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)分離；
• 使用搜索引擎搜索數(shù)據(jù)庫中的數(shù)據(jù)；
• 進行業(yè)務(wù)的拆分；

高并發(fā)情況下的解決方案：

• 應(yīng)用程序和靜態(tài)資源文件進行分離；
• 頁面緩存；
• 集群與分布式；
• 反向代理；
• CDN；

  三、海量數(shù)據(jù)的解決方案

  （1）使用緩存

網(wǎng)站訪問數(shù)據(jù)的特點大多數(shù)呈現(xiàn)為“二八定律”：80%的業(yè)務(wù)訪問集中在20%的數(shù)據(jù)上。

例如：在某一段時間內(nèi)百度的搜索熱詞可能集中在少部分的熱門詞匯上；新浪微博某一時期也可能大家廣泛關(guān)注的主題也是少部分事件。

總的來說就是用戶只用到了總數(shù)據(jù)條目的一小部分，當(dāng)網(wǎng)站發(fā)展到一定規(guī)模，數(shù)據(jù)庫IO操作成為性能瓶頸的時候，使用緩存將這一小部分的熱門數(shù)據(jù)緩存在內(nèi)存中是一個很不錯的選擇，不但可以減輕數(shù)據(jù)庫的壓力，還可以提高整體網(wǎng)站的數(shù)據(jù)訪問速度。

使用緩存的方式可以通過程序代碼將數(shù)據(jù)直接保存到內(nèi)存中，例如通過使用Map或者ConcurrentHashMap；另一種，就是使用緩存框架：Redis、Ehcache、Memcache等。

使用緩存框架的時候，我們需要關(guān)心的就是什么時候創(chuàng)建緩存和緩存失效策略。

緩存的創(chuàng)建可以通過很多的方式進行創(chuàng)建，具體也需要根據(jù)自己的業(yè)務(wù)進行選擇。例如，新聞首頁的新聞應(yīng)該在第一次讀取數(shù)據(jù)的時候就進行緩存；對于點擊率比較高的文章，可以將其文章內(nèi)容進行緩存等。

內(nèi)存資源有限，選擇如何創(chuàng)建緩存是一個值得思考的問題。另外，對于緩存的失效機制也是需要好好研究的，可以通過設(shè)置失效時間的方式進行設(shè)置；也可以通過對熱門數(shù)據(jù)設(shè)置優(yōu)先級，根據(jù)不同的優(yōu)先級設(shè)置不同的失效時間等；

需要注意的是，當(dāng)我們刪除一條數(shù)據(jù)的時候，我們要考慮到刪除該條緩存，還要考慮在刪除該條緩存之前該條數(shù)據(jù)是否已經(jīng)到達緩存失效時間等各種情況！

使用緩存的時候還要考慮到緩存服務(wù)器發(fā)生故障時候如何進行容錯處理，是使用N多臺服務(wù)器緩存相同的數(shù)據(jù)，通過分布式部署的方式對緩存數(shù)據(jù)進行控制，當(dāng)一臺發(fā)生故障的時候自動切換到其他的機器上去；還是通過Hash一致性的方式，等待緩存服務(wù)器恢復(fù)正常使用的時候重新指定到該緩存服務(wù)器。Hash一致性的另一個作用就是在分布式緩存服務(wù)器下對數(shù)據(jù)進行定位，將數(shù)據(jù)分布在不用緩存服務(wù)器上。關(guān)于數(shù)據(jù)緩存的Hash一致性也是一個比較打的問題，這里只能大致描述一下

（2）頁面靜態(tài)化技術(shù)

使用傳統(tǒng)的JSP界面，前端界面的顯示是通過后臺服務(wù)器進行渲染后返回給前端游覽器進行解析執(zhí)行，如下圖：

當(dāng)然，現(xiàn)在提倡前后端分離，前端界面基本都是HTML網(wǎng)頁代碼，通過Angular JS或者NodeJS提供的路由向后端服務(wù)器發(fā)出請求獲取數(shù)據(jù)，然后在游覽器對數(shù)據(jù)進行渲染，這樣在很大程度上降低了后端服務(wù)器的壓力。

還可以將這些靜態(tài)的HTML、CSS、JS、圖片資源等放置在緩存服務(wù)器上或者CDN服務(wù)器上，一般使用最多的應(yīng)該是CDN服務(wù)器或者Nginx服務(wù)器提供的靜態(tài)資源功能。

另外，在《高性能網(wǎng)站建設(shè)進階指南-Web開發(fā)者性能優(yōu)化最佳實踐（口碑網(wǎng)前端團隊 翻譯）》這本書中，對網(wǎng)站性能的前端界面提供了一些很寶貴的經(jīng)驗，如下：

因此，在這些靜態(tài)資源的處理上，選擇正確的處理方式還是對整體網(wǎng)站性能還是有很大幫助的！

（3）數(shù)據(jù)庫優(yōu)化

數(shù)據(jù)庫優(yōu)化是整個網(wǎng)站性能優(yōu)化的最基礎(chǔ)的一個環(huán)節(jié)，因為，大多數(shù)網(wǎng)站性能的瓶頸都是開在數(shù)據(jù)庫IO操作上，雖然提供了緩存技術(shù)，但是對數(shù)據(jù)庫的優(yōu)化還是一個需要認(rèn)真的對待。一般公司都有自己的DBA團隊，負責(zé)數(shù)據(jù)庫的創(chuàng)建，數(shù)據(jù)模型的確立等問題，不像我們現(xiàn)在幾個不懂?dāng)?shù)據(jù)庫優(yōu)化的人只能在網(wǎng)上找一篇篇數(shù)據(jù)庫優(yōu)化的文章，自己去摸索，并沒有形成一個系統(tǒng)的數(shù)據(jù)庫優(yōu)化思路。

對于數(shù)據(jù)庫的優(yōu)化來說，是一種用技術(shù)換金錢的方式。數(shù)據(jù)庫優(yōu)化的方式很多，常見的可以分為：數(shù)據(jù)庫表結(jié)構(gòu)優(yōu)化、SQL語句優(yōu)化、分區(qū)、分表、索引優(yōu)化、使用存儲過程代替直接操作等 。

（4）表結(jié)構(gòu)優(yōu)化

另外，再設(shè)計數(shù)據(jù)庫表的時候需不需要創(chuàng)建外鍵，使用外鍵的好處之一可以方便的進行級聯(lián)刪除操作，但是現(xiàn)在在進行數(shù)據(jù)業(yè)務(wù)操作的時候，我們都通過事物的方式來保證數(shù)據(jù)讀取操作的一致性，我感覺相比于使用外鍵關(guān)聯(lián)MySQL自動幫我們完成級聯(lián)刪除的操作來說，還是自己使用事物進行刪除操作來的更放心一些。當(dāng)然可能也是有適用的場景，大家如有很好的建議，歡迎留言！

（5）SQL優(yōu)化

對于SQL的優(yōu)化，主要是針對SQL語句處理邏輯的優(yōu)化，而且還要根據(jù)索引進行配合使用。另外，對于SQL語句的優(yōu)化我們可以針對具體的業(yè)務(wù)方法進行優(yōu)化，我們可以將執(zhí)行業(yè)務(wù)邏輯操作的數(shù)據(jù)庫執(zhí)行時間記錄下來，來進行有針對性的優(yōu)化，這樣的話效果還是很不錯的！例如下圖，展示了一條數(shù)據(jù)庫操作執(zhí)行調(diào)用的時間：

（6）分表

分表是將一個大表按照一定的規(guī)則分解成多張具有獨立存儲空間的實體表，我們可以稱為子表，每個表都對應(yīng)三個文件，MYD數(shù)據(jù)文件，.MYI索引文件，.frm表結(jié)構(gòu)文件。這些子表可以分布在同一塊磁盤上，也可以在不同的機器上。數(shù)據(jù)庫讀寫操作的時候根據(jù)事先定義好的規(guī)則得到對應(yīng)的子表名，然后去操作它。

例如：用戶表
用戶的角色有很多種，可以通過枚舉類型的方式將用戶分為不同類別category：學(xué)生、教師、企業(yè)等 ，這樣的話，我們就可以根據(jù)類別category來對數(shù)據(jù)庫進行分表，這樣的話每次查詢的時候現(xiàn)根據(jù)用戶的類型鎖定一個較小的范圍。

不過分表之后，如果需要查詢完整的順序就需要使用多表操作了。

（7）分區(qū)

數(shù)據(jù)庫分區(qū)是一種物理數(shù)據(jù)庫設(shè)計技術(shù)，DBA和數(shù)據(jù)庫建模人員對其相當(dāng)熟悉。雖然分區(qū)技術(shù)可以實現(xiàn)很多效果，但其主要目的是為了在特定的SQL操作中減少數(shù)據(jù)讀寫的總量以縮減響應(yīng)時間。

分區(qū)和分表相似，都是按照規(guī)則分解表。不同在于分表將大表分解為若干個獨立的實體表，而分區(qū)是將數(shù)據(jù)分段劃分在多個位置存放，可以是同一塊磁盤也可以在不同的機器。分區(qū)后，表面上還是一張表，但數(shù)據(jù)散列到多個位置了。數(shù)據(jù)庫讀寫操作的時候操作的還是大表名字，DMS自動去組織分區(qū)的數(shù)據(jù)。

當(dāng)一張表中的數(shù)據(jù)變得很大的時候，讀取數(shù)據(jù)，查詢數(shù)據(jù)的效率非常低下，很容易的就是講數(shù)據(jù)分到不同的數(shù)據(jù)表中進行保存，但是這樣分表之后會使得操作起來比較麻煩，因為，將同類的數(shù)據(jù)分別放在不同的表中的話，在搜索數(shù)據(jù)的時候需要便利查詢這些表中的數(shù)據(jù)。想進行CRUD操作還需要先找到對應(yīng)的所有表，如果涉及到不同的表的話還要進行跨表操作，這樣操作起來還是很麻煩的。

使用分區(qū)的方式可以解決這個問題，分區(qū)是將一張表中的數(shù)據(jù)按照一定的規(guī)則分到不同的區(qū)中進行保存，這樣進行數(shù)據(jù)查詢的時候如果數(shù)據(jù)的范圍在同一個區(qū)域內(nèi)那么就可以支隊一個區(qū)中的數(shù)據(jù)進行操作，這樣的話操作起來數(shù)據(jù)量更少，操作速度更快，而且該方法是對程序透明的，程序不需要進行任何的修改。

（8）索引優(yōu)化

索引的大致原理是在數(shù)據(jù)發(fā)生變化的時候就預(yù)先按指定字段的順序排列后保存到一個類似表的結(jié)構(gòu)中，這樣在查找索引字段為條件記錄時就可以很快地從索引中找到對應(yīng)記錄的指針并從表中獲取到相應(yīng)的數(shù)據(jù)，這樣速度是很快地。

不過，雖然查詢的效率大大提高了，但是在進行增刪改的時候，因為數(shù)據(jù)的變化都需要更新相應(yīng)的索引，也是一種資源的浪費。

關(guān)于使用索引的問題，對待不同的問題，還是需要進行不同的討論，根據(jù)具體的業(yè)務(wù)需求選擇合適的索引對性能的提高效果是很明顯的一個舉措！

（9）使用存儲過程代替直接操作

存儲過程（Stored Procedure）是在大型數(shù)據(jù)庫系統(tǒng)中，一組為了完成特定功能的SQL 語句集，存儲在數(shù)據(jù)庫中，經(jīng)過第一次編譯后再次調(diào)用不需要再次編譯，用戶通過指定存儲過程的名字并給出參數(shù)（如果該存儲過程帶有參數(shù)）來執(zhí)行它。存儲過程是數(shù)據(jù)庫中的一個重要對象，任何一個設(shè)計良好的數(shù)據(jù)庫應(yīng)用程序都應(yīng)該用到存儲過程。

在操作過程比較復(fù)雜并且調(diào)用頻率比較高的業(yè)務(wù)中，可以將編寫好的sql語句用存儲過程的方式來代替，使用存儲過程只需要進行一次變異，而且可以在一個存儲過程里做一些復(fù)雜的操作。

（10）分離數(shù)據(jù)庫中活躍的數(shù)據(jù)

正如前邊提到的“二八定律”一樣，網(wǎng)站的數(shù)據(jù)雖然很多，但是經(jīng)常被訪問的數(shù)據(jù)還是有限的，因此可以講這些相對活躍的數(shù)據(jù)進行分離出來單獨進行保存來提高處理效率。

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

還有一種場景就是，例如一個網(wǎng)站的所用注冊用戶量很大千萬級別，但是經(jīng)常登錄的用戶只有百萬級別，剩下的基本都是很長時間都沒有進行登錄操作，如果不把這些“僵尸用戶”單獨分離出去，那么我們每次查詢其他登錄用戶的時候，就白白浪費了這些僵尸用戶的查詢操作。

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

批量讀取和延遲修改的原理是通過減少操作數(shù)據(jù)庫的操作來提高效率。

批量讀取是將多次查詢合并到一次中進行讀取，因為每一個數(shù)據(jù)庫的請求操作都需要鏈接的建立和鏈接的釋放，還是占用一部分資源的，批量讀取可以通過異步的方式進行讀取。

延遲修改是對于一些高并發(fā)的并且修改頻繁修改的數(shù)據(jù)，在每次修改的時候首先將數(shù)據(jù)保存到緩存中，然后定時將緩存中的數(shù)據(jù)保存到數(shù)據(jù)庫中，程序可以在讀取數(shù)據(jù)時可以同時讀取數(shù)據(jù)庫中和緩存中的數(shù)據(jù)。

例如：我現(xiàn)在在編寫這份博客，我一開始寫了一寫內(nèi)容然后點擊發(fā)布了，在次回到Markdown進行修改操作，我有一個習(xí)慣，沒寫一些東西總是按一下上邊的 “保存”按鈕，然后我在另一個頁面打開這篇博客查看，我的修改已經(jīng)被更新，但是我還在 編輯！

不知道CSDN的技術(shù)是不是在我沒有點擊發(fā)布之前，這些數(shù)據(jù)都是先放到緩存里邊的。

（12） 讀寫分離

讀寫分離的實質(zhì)是將應(yīng)用程序?qū)?shù)據(jù)庫的讀寫操作分配到多個數(shù)據(jù)庫服務(wù)器上，從而降低單臺數(shù)據(jù)庫的訪問壓力。

讀寫分離一般通過配置主從數(shù)據(jù)庫的方式，數(shù)據(jù)的讀取來自從庫，對數(shù)據(jù)庫增加修改刪除操作主庫。

（13）使用NoSQL和Hadoop等技術(shù)

NoSQL是一種非結(jié)構(gòu)化的非關(guān)系型數(shù)據(jù)庫，由于其靈活性，突破了關(guān)系型數(shù)據(jù)庫的條條框框，可以靈活的進行操作，另外，因為NoSQL通過多個塊存儲數(shù)據(jù)的特點，其操作大數(shù)據(jù)的速度也是相當(dāng)快的。

（14）分布式部署數(shù)據(jù)庫

任何強大的單一服務(wù)器都滿足不了大型網(wǎng)站持續(xù)增長的業(yè)務(wù)需求。數(shù)據(jù)庫通過讀寫分離之后將一臺數(shù)據(jù)庫服務(wù)器拆分為兩臺或者多臺數(shù)據(jù)庫服務(wù)器，但是仍然滿足不了持續(xù)增長的業(yè)務(wù)需求。分布式部署數(shù)據(jù)庫是將網(wǎng)站數(shù)據(jù)庫拆分的最后手段，只有在單表數(shù)據(jù)規(guī)模非常龐大的時候才使用。

分布式部署數(shù)據(jù)庫是一種很理想的情況，分布式數(shù)據(jù)庫是將表存放在不同的數(shù)據(jù)庫中然后再放到不同的數(shù)據(jù)庫中，這樣在處理請求的時候，如果需要調(diào)用多個表，則可以讓多臺服務(wù)器同時處理，從而提高處理效率。

分布式數(shù)據(jù)庫簡單的架構(gòu)圖如下：

（15）應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)分離

應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器進行分離的目的是為了根據(jù)應(yīng)用服務(wù)器的特點和數(shù)據(jù)庫服務(wù)器的特點進行底層的優(yōu)化，這樣的話能夠更好的發(fā)揮每一臺服務(wù)器的特性，數(shù)據(jù)庫服務(wù)器當(dāng)然是有一定的磁盤空間，而應(yīng)用服務(wù)器相對不需要太大的磁盤空間，這樣的話進行分離是有好處的，也能防止一臺服務(wù)器出現(xiàn)問題連帶的其他服務(wù)也不可以使用。

（16）使用搜索引擎搜索數(shù)據(jù)庫中的數(shù)據(jù)

使用搜索引擎這種非數(shù)據(jù)庫查詢技術(shù)對網(wǎng)站應(yīng)用的可伸縮分布式特性具有更好的支持。

常見的搜索引擎如Solr通過一種反向索引的方式，維護關(guān)鍵字到文檔的映射關(guān)系，類似于我們使用《新華字典》進行搜索一個關(guān)鍵字，首先應(yīng)該是看字典的目錄進行查找然后定位到具體的位置。

搜索引擎通過維護一定的關(guān)鍵字到文檔的映射關(guān)系，能夠快速的定位到需要查找的數(shù)據(jù)，相比于傳統(tǒng)的數(shù)據(jù)庫搜索的方式，效率還是很高的。

目前一種比較火的ELK stack技術(shù)，還是值得學(xué)習(xí)的。

（17）進行業(yè)務(wù)的拆分

為什么進行業(yè)務(wù)的拆分，歸根結(jié)底上還是使用的還是講不通的業(yè)務(wù)數(shù)據(jù)表部署到不用的服務(wù)器上，分別查找對應(yīng)的數(shù)據(jù)以滿足網(wǎng)站的需求。各個應(yīng)用之間用過指定的URL連接獲取不同的服務(wù)，

例如一個大型的購物網(wǎng)站就會將首頁、商鋪、訂單、買家、賣家等拆分為不通的子業(yè)務(wù)，一方面將業(yè)務(wù)模塊分歸為不同的團隊進行開發(fā)，另外一方面不同的業(yè)務(wù)使用的數(shù)據(jù)庫表部署到不通的服務(wù)器上，體現(xiàn)到拆分的思想，當(dāng)一個業(yè)務(wù)模塊使用的數(shù)據(jù)庫服務(wù)器發(fā)生故障也不會影響其他業(yè)務(wù)模塊的數(shù)據(jù)庫正常使用。另外，當(dāng)其中一個模塊的訪問量激增的時候還可以動態(tài)的擴展這個模塊使用到的數(shù)據(jù)庫的數(shù)量從而滿足業(yè)務(wù)的需求。

四、高并發(fā)情況下的解決方案

（1）應(yīng)用程序和靜態(tài)資源文件進行分離

所謂的靜態(tài)資源就是我們網(wǎng)站中用到的Html、Css、Js、Image、Video、Gif等靜態(tài)資源。應(yīng)用程序和靜態(tài)資源文件進行分離也是常見的前后端分離的解決方案，應(yīng)用服務(wù)只提供相應(yīng)的數(shù)據(jù)服務(wù)，靜態(tài)資源部署在指定的服務(wù)器上（Nginx服務(wù)器或者是CDN服務(wù)器上），前端界面通過Angular JS或者Node JS提供的路由技術(shù)訪問應(yīng)用服務(wù)器的具體服務(wù)獲取相應(yīng)的數(shù)據(jù)在前端游覽器上進行渲染。這樣可以在很大程度上減輕后端服務(wù)器的壓力。

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

（2）頁面緩存

頁面緩存是將應(yīng)用生成的很少發(fā)生數(shù)據(jù)變化的頁面緩存起來，這樣就不需要每次都重新生成頁面了，從而節(jié)省大量CPU資源，如果將緩存的頁面放到內(nèi)存中速度就更快。

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

（3）集群與分布式

（4）反向代理

（5）CDN

CDN服務(wù)器其實是一種集群頁面緩存服務(wù)器，其目的就是盡早的返回用戶所需要的數(shù)據(jù)，一方面加速用戶訪問速度，另一方面也減輕后端服務(wù)器的負載壓力。

CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。其基本思路是盡可能避開互聯(lián)網(wǎng)上有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內(nèi)容傳輸?shù)母?、更穩(wěn)定。

CDN通過在網(wǎng)絡(luò)各處放置節(jié)點服務(wù)器所構(gòu)成的在現(xiàn)有的互聯(lián)網(wǎng)基礎(chǔ)之上的一層智能虛擬網(wǎng)絡(luò)，CDN系統(tǒng)能夠?qū)崟r地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點的連接、負載狀況以及到用戶的距離和響應(yīng)時間等綜合信息將用戶的請求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點上。其目的是使用戶可就近取得所需內(nèi)容，解決 Internet網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度。

也就是說CDN服務(wù)器是部署在網(wǎng)絡(luò)運行商的機房，提供的離用戶最近的一層數(shù)據(jù)訪問服務(wù)，用戶在請求網(wǎng)站服務(wù)的時候，可以從距離用戶最近的網(wǎng)絡(luò)提供商機房獲取數(shù)據(jù)。電信的用戶會分配電信的節(jié)點，聯(lián)通的會分配聯(lián)通的節(jié)點。

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

CDN結(jié)構(gòu)圖如下所示：

五、總結(jié)

文章提到的幾點并沒有詳細的介紹，如需要對其中的一種方式進行研究，可以自行去找資源學(xué)習(xí)研究，這里只起到拋磚引玉的作用。當(dāng)然對于大型網(wǎng)站應(yīng)用之海量數(shù)據(jù)和高并發(fā)解決方案不局限于這些技巧或技術(shù)，還有很多成熟的解決方案，有需要的可以自行了解。

特此說明：本文的配圖來自《網(wǎng)站架構(gòu)及其演變過程–韓路彪》，多謝原作者提供的精美配圖，并且文章的結(jié)構(gòu)大致也參考了作者的思路，只不過內(nèi)容是自己的一些經(jīng)驗和學(xué)習(xí)到的東西進行整理的。