目錄sql
高併發,大流量
: 須要面對高併發用戶,大流量訪問,Google日均PV數爲35億,日均IP訪問數爲3億,2011年騰訊QQ最大用戶在線數1.4億,淘寶2012年雙11活動一天交易額191億,活動開始第一分鐘獨立訪問用戶達1000萬數據庫
拓展: PV、UV、IV的概念緩存
PV: PV訪問量(Page View),即頁面訪問量,每打開一次頁面PV計數+1,刷新頁面也是。安全
UV: UV訪問數(Unique Visitor)指獨立訪客訪問數,一臺電腦終端爲一個訪客。服務器
IV: IV是IP訪問數指獨立IP訪問數,計算是以一個獨立的IP在一個計算時段內訪問網站計算爲1次IP訪問數。在同一個計算時段內無論這個IP訪問多少次均計算爲1次。計算時段有以1天爲一個計算時段,也有以1個小時爲一個計算時段。網絡
高可用
: 7 * 24小時不間斷提供服務。大型網站的宕機通常會成爲焦點,例如2010年百度域名被黑客劫持事件,雙11淘寶宕機事件,12306網站併發數太高的宕機事件,微博流量明星宕機事件。架構
海量數據
: 須要存儲管理海量的數據,同時須要大量服務器,Facebook 每週上傳的照片數目接近10億,百度收錄的網站有百億,Google有接近百萬臺服務器爲全球用戶提供服務。併發
用戶分佈普遍,網絡狀況複雜
:許多大型互聯網公司都是爲全球用戶提供服務,各地網絡狀況千差萬別,在國內,還有各個運營商網絡互通難的問題,而中美光纜的數次故障,也讓不少互聯網公司不得不考慮在海外創建數據中心。負載均衡
安全環境惡劣
: 因爲互聯網的開放性,使大型互聯網公司更易遭到黑客的攻擊,例如facebook用戶泄漏事件。
nosql
需求快速變動,發佈頻繁
: 和傳統的企業級應用不一樣,互聯網公司爲快速適應市場,知足用戶需求,其產品發佈頻率是極高的。至於中小型互聯網公司的發佈頻率,那就更高了,有時候一天會發布十幾回
漸進式發展
: 與傳統行業一開始規劃好所有的功能和非功能的需求不一樣,不少大型互聯網公司都是從小公司開始作起,漸進的發展起來的。Facebook的創始人扎克伯克在哈佛的宿舍開發出來的,阿里巴巴是誕生在馬雲家的客廳的,好的互聯網產品都是迭代出來的,不是一開始就發展的很好的。
大型網站都是從小型網站發展起來的,網站架構也是同樣,網站剛開始搭建處於雛形階段,訪問量小,一臺服務器徹底夠用,也是大部分企業級應用的選擇
應用程序,數據庫,文件都部署在一臺服務器的,一般服務器選用Linux,應用程序選用PHP,而後部署在Apache 上,數據庫使用MySQL,聚集各類開源軟件以及一架廉價的服務器就能夠進行開發
隨着業務的發展,一臺服務器不能知足業務需求:愈來愈多的用戶訪問致使性能愈來愈差,愈來愈多的數據致使服務器存儲空間不足,這就須要將應用和數據分離。應用和數據分離後整個網站使用三臺服務器,應用服務器,文件服務器,數據庫服務器
應用和數據分離後,不一樣特性的服務器承擔不一樣的服務角色,網站的併發處理能力和數據存儲都獲得了很大的改善,支持業務的進一步發展。可是隨着業務的增多,訪問量增大,網站又一次面臨挑戰,數據庫壓力太多致使訪問延遲,進而影響整個網站的性能,用戶體驗收到影響
網站訪問特色和現實世界的財富分配一般符合二八定律: 80%的業務訪問集中在20% 的數據上,淘寶買家瀏覽的商品集中在少部分紅交數多、評價良好的商品上;百度搜索的關鍵詞集中在少部分熱門詞彙上,搜索出來的詞條你也會瀏覽前兩頁的內容。
既然大部分的瀏覽都只會放在一小部分數據上,那麼是否能把這些數據緩存起來放在內存中,是否是就能夠減小數據庫的壓力,從而提升整個網站的數據訪問速度,改善數據庫的寫入性能了呢?
網站的緩存分爲兩種
: 緩存在本地服務器
上的本地緩存,緩存在遠程服務器
上的遠程緩存,本地緩存的訪問速度要比遠程緩存的更快。可是受應用服務器的內存限制,每每會存在本地緩存和應用程序競爭內存的狀況,這種狀況在遠程服務器
上就不會存在,遠程分佈式緩存可使用集羣的方式,部署大內存的服務器使用專門的緩存服務器,理論上能夠作到不受內存限制的緩存服務
使用緩存後,有效的改善了數據庫訪問的壓力,可是單一應用程序的服務器可以處理的鏈接有限,在網站訪問的高峯期間,應用服務器會成爲網站的瓶頸
使用集羣是解決高併發,海量數據問題的關鍵手段,當一臺服務器的處理能力、存儲空間不足的時候,不要嘗試去更換一臺存儲量更大的服務器,而是考慮集羣
部署,由於對於大型網站而言,無論多麼強大的服務器,都知足不了網站持續增加的業務。
應用服務器集羣部署,使用負載均衡服務器作負載控制,可以改善流量峯值對應用服務器的壓力,避免單一服務器承擔更多的請求壓力。若是還有更多的請求,那麼就在現有的基礎上增長更多的應用服務器。
使用緩存後,可以改善一部分的數據庫訪問壓力,使絕大多數數據讀操做訪問不用經過數據庫就能完成,可是仍有一部分讀(緩存訪問不命中,緩存過時)和所有的寫操做都會直接訪問數據庫,在網站到達必定的規模後,也會增大數據庫的壓力
目前大部分主流數據庫都提供主從熱備功能,經過配置兩臺數據庫搭建主從
關係,能夠將一臺數據庫服務器的數據更新同步
到另外一臺服務器上,網站能夠利用這一特性,實現數據庫的讀寫分離
的功能,從而改善數據庫的壓力。
應用在寫數據的時候,訪問主服務器,在讀數據的時候,訪問從服務器,主數據庫經過主從複製的功能將數據同步更新到從服務器,這樣當有讀操做的時候,就會直接訪問從服務器,當有寫操做的時候,會直接訪問主服務器,爲了便於應用程序訪問讀寫分離後的數據庫,一般在應用服務器端使用專門的數據訪問模塊,使數據庫讀寫分離對應用透明
隨着網站規模不斷擴大,用戶規模愈來愈大,因爲國內網絡狀況複雜,不一樣地區的用戶訪問網站時,速度差異也極大。有研究代表,網站訪問延遲和用戶流失率正相關,網站訪問越慢,用戶的流失率越快,因此爲了更好的用戶體驗,留住用戶,網站須要更快的訪問速度,主要手段有使用CDN和反向代理
CDN和反向代理的基本原理都是緩存,區別在於CDN部署在網絡提供商的機房,使用戶在請求網站服務時,能夠從距離本身最近
的機房獲取數據;而CDN則部署在網站的中心機房,當用戶請求到達中心機房後,首先訪問的服務器是反向代理服務器
,若是反向代理服務器緩存着資源,就會直接返回給用戶
使用CDN的目的都是儘早返回數據給用戶,一方面可以加快訪問速度,一方面都能減輕服務器的壓力
任何強大的單一服務器都知足不了大型網站持續增加的業務需求。數據庫通過讀寫分離後,從一臺服務器拆分紅兩臺服務器,可是隨着網站業務的發展不能知足業務的需求,須要使用分佈式的存儲服務器
,文件系統可以也是同樣,須要使用分佈式文件系統。
分佈式數據庫是網站數據庫拆分的重要手段,只有在單表數據很是龐大的時候才使用。不到不得已時,網站最經常使用的數據庫拆分手段是業務分庫。將不一樣業務的數據部署在不一樣的服務器上。
隨着網站業務的擴大,對數據存儲和檢索的要求也愈來愈高,網站須要採用一些非關係型數據庫技術如NoSQL和非數據庫查詢技術和搜索引擎
NoSQL和搜索引擎都是源自互聯網的技術手段,對可伸縮的分佈式特性具備更好的支持。應用服務器則經過一個統一數據訪問模塊訪問各類數據。減輕應用程序管理諸多數據源的麻煩
大型網站爲了應對日益繁雜的業務場景,經過使用分而治之的方式將整個網站的業務拆分紅不一樣的產品線,如大型購物交易網站就會將首頁、商鋪、訂單、買家、賣家等拆分紅不一樣的產品線,分歸不一樣的業務部門負責管理。
具體到技術上,也會根據產品線劃分產品,將一個產品拆分紅不一樣的應用。每一個應用獨立部署和維護,應用之間能夠經過超連接簡歷關係,也能夠經過消息隊列
進行數據分發,固然最多的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統。
隨着業務拆分愈來愈小,存儲系統愈來愈大,應用系統的總體複雜度呈指數增加,部署愈來愈困難。因爲全部的應用都要和數據庫系統鏈接。在數萬臺服務器規模的網站中,這些鏈接的數目是服務器規模的平方。致使存數據庫鏈接資源不足。拒絕服務。
既然每個應用系統都須要執行許多相同的業務操做,能夠把相同的
業務提取出來。由這些可服用的業務鏈接數據庫。提供公用業務服務。
大型網站演化到這裏,基本上大多數的技術問題均可以解決,諸如跨數據中心的實時數據同步和具體網站業務相關的問題均可以經過組合改進現有的技術架構來解決。
大型網站
架構技術的核心價值不是從無到有
搭建一個大型的網站,而是可以伴隨小型網站業務的逐步發展,慢慢演化成一個大型網站。在這個過程當中,不須要放棄什麼,不須要推翻什麼,技術選型都是很是重要的,全部的大公司例如FaceBook、Google、淘寶無不遵循這樣一條發展路線
創新的業務發展模式對網站架構提出了更高的要求,才使得創新的網站架構得以發展成熟。是業務成就了技術,是事業成就了人。而不是相反。
1. 盲目追隨大公司的解決方案
2. 爲了技術而技術
3.企圖用技術解決全部問題
文章來源
《大型網站技術架構:核心原理與案例分析》