大併發系統設計

架構設計

優化服務器配置。

負載均衡技術。

Web容器採用線程池技術。

數據庫鏈接採用鏈接池技術。

頁面預編譯技術。

緩存設計技術。

高度優化SQL(Select和Update)、索引、分頁等。

數據流壓縮技術。pasting

優化服務器配置

加大內存。

加大併發數。

升級操做系統版本。

正確的磁盤分區技巧。

負載均衡技術

DNS負載均衡技術。

優勢：優勢是經濟簡單易行 ，節點能夠在任意位置。

缺點：更新慢，節點宕機後沒法響應。

交換機負載均衡技術。

優勢：能及時響應節點宕機，速度快。

缺點：對交換機有要求，節點必須在交換機中。

Web容器採用線程池技術。

進程模式的請求響應很是慢。可是比較穩定，一個進程dead後不影響其它進程。

採用線程池技術的後響應速度很是快，數據能夠在線程之間共享。缺點是有可能單個線程會影響其它線程，而且有可能會發生死鎖。

數據庫鏈接採用鏈接池技術

提升了響應時間，尤爲是的SQL比較多的時候更應採用鏈接池技術。

注意：鏈接的釋放。鏈接的事務處理。

頁面預編譯技術

編譯後的代碼執行速度要比腳本語言高出幾個數量級。

Jsp主要是第一次運行時編譯，這樣能夠提升第二次響應請求的時間。

能夠在部署後批量編譯全部動態須要編譯的文件。

緩存設計技術

緩存能大大減小數據量的壓力。

頁面所有緩存

優勢：整個頁面響應速度快。

缺點：更新不及時，沒法單獨刷新某一塊。

單個組件緩存

優勢：執行速度快，能夠很細的控制須要緩存的部分，節省內存空間。

優秀的緩存方案

頁面級緩存技術有：squid、OSCache的taglib技術等

組件級有：MEMCache、OSCache、ECache等

高度優化SQL、索引、分頁

值採用?形式來複用SQL，如：insert into table(f1,f2) values (?,?)。數據庫會緩存這些sql，不會再解析了。

關聯表查詢注意要使用到索引。最好經過他表的主鍵關聯。

採用存貯過程技術。

時間存貯採用時間類型，數據庫對date類型字段都作了優化。

常常要查詢的字段必須建索引，使用到的索引上最好能排除全表的80%的記錄。

若是不能作到，則須要創建聯合索引。一樣索引必須能排除80%以上的記錄。

索引按期優化，重建。

查詢排序最好經過主鍵來排序。

一張表上索引不要超過5個。

儘可能不要Like查詢大字段。

執行時間超過100ms的SQL基本上都有問題，要麼是設計的問題，要麼是SQL沒有優化，要麼是索引沒有使用正確。

數據流壓縮技術

數據流壓縮主要用在web服務器和瀏覽器之間的數據傳送。

如今的瀏覽器基本上都支持gzip和deflate壓縮技術。

注意壓縮比。

不要壓縮jpg、rar、zip等已經壓縮過的文件。不然性能會更低。

解決網站大流量問題的策略

我的博客因爲訪問量過大而引發服務器性能問題，這是不少人的煩惱，有人使用取消RSS的方法來解決問題，顯然是下錯藥，那麼對於網站大流量帶來的問題，正確的解決方法應該是什麼呢？下面是我我的總結的一些經驗，供你們參考。

首先，確認服務器硬件是否足夠支持當前的流量。

普通的P4服務器通常最多能支持天天10萬獨立IP，若是訪問量比這個還要大，那麼必須首先配置一臺更高性能的專用服務器才能解決問題，不然怎麼優化都不可能完全解決性能問題。

其次，優化數據庫訪問。

前臺實現徹底的靜態化固然最好，能夠徹底不用訪問數據庫，不過對於頻繁更新的網站，靜態化每每不能知足某些功能。

緩存技術就是另外一個解決方案，就是將動態數據存儲到緩存文件中，動態網頁直接調用這些文件，而沒必要再訪問數據庫，WordPress和Z-Blog都大量使用這種緩存技術。我本身也寫過一個Z-Blog的計數器插件，也是基於這樣的原理。

若是確實沒法避免對數據庫的訪問，那麼能夠嘗試優化數據庫的查詢SQL.避免使用Select * from這樣的語句，每次查詢只返回本身須要的結果，避免短期內的大量SQL查詢。

第三，禁止外部的盜鏈。

外部網站的圖片或者文件盜鏈每每會帶來大量的負載壓力，所以應該嚴格限制外部對於自身的圖片或者文件盜鏈，好在目前能夠簡單地經過refer來控制盜鏈，Apache本身就能夠經過配置來禁止盜鏈，IIS也有一些第三方的ISAPI能夠實現一樣的功能。固然，僞造refer也能夠經過代碼來實現盜鏈，不過目前蓄意僞造refer盜鏈的還很少，能夠先不去考慮，或者使用非技術手段來解決，好比在圖片上增長水印。

第四，控制大文件的下載。

大文件的下載會佔用很大的流量，而且對於非SCSI硬盤來講，大量文件下載會消耗CPU，使得網站響應能力降低。所以，儘可能不要提供超過2M的大文件下載，若是須要提供，建議將大文件放在另一臺服務器上。

第五，使用不一樣主機分流主要流量

將文件放在不一樣的主機上，提供不一樣的鏡像供用戶下載。好比若是以爲RSS文件佔用流量大，那麼使用FeedBurner或者FeedSky等服務將RSS輸出放在其餘主機上，這樣別人訪問的流量壓力就大多集中在FeedBurner的主機上，RSS就不佔用太多資源了。

第六，使用流量分析統計軟件。

在網站上安裝一個流量分析統計軟件，能夠即時知道哪些地方耗費了大量流量，哪些頁面須要再進行優化，所以，解決流量問題還須要進行精確的統計分析才能夠。我推薦使用的流量分析統計軟件是GoogleAnalytics（Google分析）。我使用過程當中感受其效果很是不錯，稍後我將詳細介紹一下Google Analytics的一些使用常識和技巧。

1、分

咱們知道，對於一個大型網站來講，可伸縮性是很是重要的，怎麼樣在縱向和橫向有良好的可伸縮性，就須要在作架構設計的時候考慮到一個分的原則，我想在多個方面說一下怎麼分：

首先是橫向的分：

1. 大的網站化解爲多個小網站：當咱們一個網站有多個功能的時候，能夠考慮把這個網站拆分紅幾個小模塊，每個模塊能夠是一個網站，這樣的話咱們到時候就能夠很靈活地去把這些網站部署到不一樣的服務器上。

2. 靜態動態分離：靜態文件和動態文件最好分離開成2個網站，咱們知道靜態網站和動態網站對服務器來講壓力的側重不一樣，前者可能重IO後者重CPU，那麼咱們在選擇硬件的時候也能夠有側重，並且靜態和動態內容的緩存策略也不同。典型的應用，咱們通常會有獨立的文件或圖片服務器。

3. 按照功能來分：好比有一個模塊是負責上傳的，上傳操做很消耗時間，若是和其它應用混在一塊兒的話極可能，一點點訪問就會使服務器癱瘓，這種特殊的模塊應該分開。安全的不安全的也要分開，還須要考慮到之後SSL的購買。

4. 咱們不必定要所有用本身的服務器，搜索、報表能夠依靠別人的服務，好比google的搜索和報表服務，本身作的不必定比得過別人，服務器帶寬都省了。

其次是縱向的分：

1. 文件也至關於數據庫，IO的流量可能比數據庫還大，這也算是縱向級別的訪問，上傳的文件圖片必定要和WEB服務器分開。固然，數據庫和網站都放在一個服務器上的不多了，這是最基本的。

2. 對於涉及到數據庫訪問的動態程序來講，咱們可使用一箇中間層（所謂的應用層或邏輯層）來訪問數據庫（部署在獨立的服務器上），最大的好處就是緩存和靈活性。緩存的內存佔用比較大，咱們要把它和網站進程分開，並且這樣作咱們能夠很方便的去改變一些數據訪問的策略，即便到時候數據庫有分佈的話在這裏能夠作一個調配工做，這樣靈活性就很大了。還有好處是中間層能夠作電線網通橋樑，可能網通訪問雙線再訪問電信會比網通直接訪問電信服務器快。

有人說我不分，我能夠作負載均衡，對，是能夠的，可是若是分的話，一樣的10臺機器確定比不分10臺機器能夠承受更多的訪問量，並且對硬件的需求可能不會很高，由於知道須要哪一個硬件特別好。爭取讓每個服務期都不空閒，又都不是太忙，合理進行組合調整和擴充，這樣的系統伸縮性就高了，能根據訪問量來調整的前提就是以前有考慮到分，分的好處是靈活性、伸縮性、隔離性以及安全性。

對服務器來講，咱們有幾點是要長期觀察的，任何一點均可能是瓶頸：

1. CPU：動態文件的解析須要比較多的CPU，CPU出現瓶頸就要看是否是哪一個功能過長時間佔用線程，若是是就分出去。或者就是每個請求處理時間不長，可是訪問量很高，那麼就加服務器。CPU是好東西，不能讓他乾等，不作事情。

2. 內存：緩存從IIS進程獨立出去，通常對WEB服務器來講內存不夠的狀況不是不少。內存比磁盤快，要合理利用。

3. 磁盤IO：用性能監視器找到哪些文件IO特別大，找到了就分到獨立的一組文件服務器上去，或者直接作CDN。磁盤慢，大規模讀取數據的應用靠緩存，大規模寫入數據的應用能夠靠隊列來下降突發的併發。

4. 網絡：咱們知道，網絡的通信是比較慢的，比磁盤還慢，若是是作分佈式緩存，分佈式計算的話，要考慮到物理服務器之間網絡通信的時間，固然，在流量大了之後，這能夠提升系統的接納能力一個等級。靜態內容能夠藉助CSD分擔一部分，在作服務器假設的時候還要考慮中國特點的電信網通狀況以及防火牆。

對SQL SERVER數據庫服務器來講[UPDATE]：

其實仍是水平分割和縱向分割，一個二維表，水平分割就是橫過來切一刀，縱向分割就是豎直切一刀：

一、縱向分割就是，咱們不一樣的應用能夠分到不一樣的DB中，不一樣的實例中，或者說把某個擁有不少字段的表拆分紅小表。

二、橫向分割就是，某些應用可能不負載，好比用戶註冊，可是用戶表會很是大，能夠把大表分開。能夠採用表分區，數據存儲在不一樣文件上，而後再部署到獨立物理服務器增長IO吞吐以改善讀寫性能，土一點的作法就是本身按期把老的數據存檔。表分區的另一個優點能夠增長數據查詢速度，由於咱們的頁索引能夠有多層了，就像一個文件夾中的文件不要太多，多分幾層文件夾同樣。

三、還能夠經過數據庫鏡像、複製訂閱、事物日誌，把讀寫分開到不一樣的鏡像物理數據庫上，通常來講夠用，若是還不行能夠用硬件來實現數據庫的負載均衡。固然，對於BI，咱們可能還會有數據倉庫。

架構上考慮到了這些以後，流量大了，就能夠在這個的基礎上再去調整或者作WEB服務器或者應用服務器的負載均衡。不少時候咱們都是在重複發現問題-》找到瓶頸-》解決這個過程。

典型的架構以下：

動態WEB服務器配好點的CPU，靜態WEB服務器和文件服務器磁盤好點,應用服務器內存大點，緩存服務器也是，數據庫服務器固然內存和CPU都要好

2、並

爲何要分？是由於咱們但願經過分來提升系統的承載能力，那並又是並什麼呢？我想了一下有幾個方面能夠並：

1. 合併用戶請求，最基本的就是合併CSS/圖片/腳本，還能夠合併頁面。不過合併就可能產生流量的浪費，須要有一個平衡點。

2. 合併接口的粒度，若是作分佈式應用的話，咱們可能不會直接訪問數據庫而是調用應用層提供的接口，因爲是網絡調用，代價比較大，所以在設計的時候儘可能提供粒度比較粗的接口，一次調用返回比較多的數據，而不是細化到添加刪除修改的層次。

3. 合併接口的部署，對於頻繁的跨機器調用能夠考慮有一些數據冗餘，把跨網絡的服務編程進程間通信，甚至轉到客戶端來作。好比論壇發貼時候髒詞的過濾，直接調用應用層提供的接口（跨機器）是能夠的，可是可能代價比較大，能夠把這個接口使用IPC方式部署在本機。

3、換

時間換空間，空間換時間是常見的作法，具體一點說：

1. 緩存。緩存的重要性早計算機的硬件中就有重要的體現。對於網站，有不少種緩存，能夠是客戶端資源的緩存，能夠是頁面輸出緩存，也能夠是應用層的數據緩存，目的都是同樣的，或是減小了服務器請求次數，或是減小了請求的處理過程，或是減小了數據庫的訪問次數。固然，生成靜態文件也能夠算是一種緩存。不訪問磁盤當然不可能，可是咱們要極大限度下降磁盤訪問的機會。

2. 有的時候爲了獲取極快的響應，咱們還會不惜代價採用重複計算。好比，咱們的某個操做極可能會因爲網絡問題等緣由響應比較慢，在設計的時候能夠有一個統一的處理接口，由這個接口分發到不一樣的服務器去異步實現這個操做，哪一個服務器先返回告終果咱們就用這個結果，而後殺死其餘服務器的冗餘操做。

3. 網站通常追求比較快的響應，通常不太會在比較高的層次用時間來換取空間，可是在一些用戶獨有數據的處理算法上可能仍是會考慮到空間的節省問題。

4. 有的時候咱們會用一些聚合表來存放聚合數據，也就是進行一些預計算提升複雜計算（好比報表）的性能。固然，對於數據分析，構建多維數據庫也是一種不錯的選擇。

有不少網友留言說說的比較粗，沒有什麼具體的東西。我以爲架構這個東西很難去說具體怎麼作，由於具體實施的時候要看狀況去應用的，因爲沒有完美的東西，因此作架構一般是去作一個平衡，極可能某一個側重不一樣會影響到架構的實施。但願個人這些文章能給你們一個提示的做用，看了以後若是你以爲「這點我倒沒有考慮到，之後要注意」那或許就是最大的幫助了，下面我想說一些其它方面的問題，每一條都很零散，算是一個補充吧：

1. 究竟是採用已有的東西仍是本身去作須要詳細考慮的，採用別人的東西可能比較穩定，可是本身的控制少了一點，採用本身作的東西能夠很靈活，可是可能會問題比較多。無論怎麼樣，咱們在採用一個第三方框架的時候務必要進行縝密的調查，看到他的不足，不然項目極可能在後期被這個框架制約，反之，決定本身去作一個框架的時候也要看到本身須要什麼其餘框架不能提供的東西。

2. 數據傳輸的時候能夠作壓縮，但要考慮到壓縮解壓縮須要CPU資源，在IO（磁盤，帶寬，傳輸能力）和CPU之間有一個平衡的考慮。

3. 理想的可伸縮性架構是能夠自由增長或替換服務器，無需去停機維護或作很大的調整。在使用一個統一的調度中心來調度這些服務器，分配請求的時候，咱們要考慮一下調度服務器能承受多少流量。

4. 使用大量的廉價服務器仍是少許的高配服務器？如何根據需求來組合服務器發揮最大做用。

5. 對於分佈式構架，咱們儘可能讓每個節點保持簡單的邏輯，儘可能減小同一層次節點之間的依賴，另外。須要有統一的地方來管理全部的節點。

6. 功能分解、使用異步進行整合、故障轉移、失效保護。

7. 軟件的架構升級和計算機硬件的架構升級很像，可能有一段時期，咱們是在慢慢提升總體能力，2年也才提升了幾倍，以後發現只有經過某種完全的架構改變才能提升數十倍的能力，升級以後，咱們或許又會遇到其餘問題。就像CPU，是簡單提升主頻仍是完全更換架構。

8. 數據方面，讀寫分離、數據庫分隔、功能劃分、緩存、鏡像。

9. 硬件網絡上的架構很重要，但軟件開發中的一些細節不可忽略，好的架構不意味着不須要代碼審閱。

pasting