首先，我們需要清楚在業務上有什麼要樣的效能需求；
第二步，根據效能的要求去考慮系統的設計，
第三步，系統的開發過程中去關注可能存在的區域性效能問題。
沒有開發過效能敏感系統的團隊，容易犯的錯誤是，不去考慮系統將來有多少人使用，併發訪問有多高，需要存貯多少數量的資料？ 直接就開始做系統的開發，抱著等著出了效能問題再說。系統做出來上線之後，效能的問題就暴露出來。但這時候，要解決好效能問題將要負出沉重的代價，往往是 乙個系統的重寫。 進度的壓力成為了不考質量與效能的理由。造成乙個現象：我們沒有時間去把乙個系統做好，但我們有時間去把同乙個系統做上幾遍。短期是高效率的，但長期是低效率的。
我舉例說明一下：
*廣告投放系統：
10個使用者以對系統有寫的訪問， 1000萬級的使用者對系統有訪問。
廣告主要投放在**上， 乙個頁面往往具有幾個廣告的展現。每天要達到上億的pv。高峰的qps所達到上十億。
廣告每天的資料量在1g以內，沒有歷史資料需要處理。
*互動貼吧：
千萬級的使用者量，並且都進行讀寫操作。
系統在熱門期間，需要支援1億的pv，高峰qps 要達到1250 * 2 = 2500 qps
貼吧的貼子數： 10000貼吧 * 1000主題 * 100 貼子 ＝ 10億個貼子； 乙個貼子平均200個漢字，即有 400g的資料量。
使用者量應具有百萬級.
以每使用者每天平均訪問3次計算，那 100萬 ＊ 2 ＊ 20（平均每次訪問pv數）＝ 4000萬的pv，在高峰期以平均的qps＊2 ＝ 500 ＊2 ＝ 1000 （qps)
「太超前了，現在的業務發展情況遠遠不需要的這樣高的效能業支援，如果以很大的代價來實現，實在是太浪費，並且業務當前所需要的緊急的問題，是功能、是易用性並不是效能。」
這的確是乙個現實的情況，這裡我將在第三部份來計論這個情況，現在假設我們需要應對這些高效能的挑戰吧。
我們面對上千萬級的使用者、幾千的qps、百g以上的資料。 實在沒有辦法以單獨的伺服器來支撐，因此在設計系統時，第乙個要考慮的就是：
大家應很容易就理解和認同這種做法。 但是做起來確並不是簡單的事情，需要根據具體的應用來設計。
假設我們需要5000的qps，那我分解成 500 * 10，使用10組伺服器來支援。 這時我們需要考慮的問題是：
在資料存貯方面，超過千萬級的資料記錄，上10g的資料，就考慮到水平擴充套件的能力。不論是我們常用的mysql還是oracle, 單表處理資料量是有乙個效能拐點的。就需要考慮到折表，單機的資料庫處理能力也是有限的，就要考慮到使用資料量的集群。
系統的水平擴充套件能力是解決效能敏感系統的首要原則，它使得系統具有通過增加更多的硬體裝置來提高效能。
並且需要讓這個擴充套件是容易進行的。
另外，即使我們系統有很好的水平提展能力，提搞單機的qps還是非常必要。 單機的qps太低，使得伺服器的成本變得不可接受。
當面對高效能的訪問時，你分析發現，在網際網路的web應用，使用者的讀寫訪問在一般都會達到100:1，甚至會更高。高併發訪問的效能問題，就會減化為， 如何提高併發的讀訪問速度和保證寫訪問的正確性有及時性。
在開發系統中，我們常常會出現兩種以下的做法：
整個系統的開發追求效能，系統沒有什麼結構，所有的功能的實現都是，直接在頁面拼寫sql來讀寫資料。
全面考慮程式的結構，追求系統的擴充套件性和可維性。
這兩種方法，都有他們適用的範圍，但同時也有他們的不足。
面對不同的要求，我們需要區別對待， 讀寫分離的思路，不僅是程式和程式開發模式的分離，它還意味著：
在越接使用者和越接用具體應用時，緩衝的效率越高。 因此可能考慮在web伺服器來建立一快取。 在快取機制的設計與使用，互動團隊的貼吧系統應是值得學習的專案。當然我們也清楚那些好東西是做快取的必備良藥。 memched,bdb, varnish 需要清楚他們適合解決的問題是什麼，加以利用。
不管cache的機制如何有效，但我們還得保證在無cache的情況下，效能基本滿足業務的需要。因為cache總是有他的命中率的，並且也要考慮到在cache失效後，我們系統還是能正常執行的。
在我的理解，」』cache是效能的放大器。」』
在系統的開發過程的管理，本質上還是以風險驅動的，什麼最可能產生嚴重的問題，就應該去優先去解決。在評估效能後，我們需要的是乙個高效能要求的系統，並且系統一上線，就會馬上遇到這種效能的壓力，那麼我建議如下：
跟據上述的設計原則來指導你設計，並與有經驗的人進行計論
藉著樁的方式，快速搭建系統框架，進行效能測試，確定整體的效能，整體的效能高於區域性的效能。
解決是效能關鍵的子系統或元件的問題，這是解決區域性效能問題。
在提交功能測試前進行效能測試，不要等上線之後才發現效能的問題。
對於進度緊張，並且預期在未來半年內不會遇到效能挑戰，關於上述的第3點可以先不做。但你對於系統的當前狀況一定要清楚。 在系統在效能挑戰出現之後，就可從容的去解決效能的問題。
構建Nginx Cache高效能快取系統
隨著nginx web伺服器得到越來越多的sa的青睞，nginx的cache功能已經具備squid所擁有的web快取加速功能 清除指定url快取的功能。而在效能上，nginx對多核cpu的利用，勝過squid不少。另外，在反向 負載均衡 健康檢查 後端伺服器故障轉移 rewrite重寫 易用性上，n...
構建高效能web
一直想在web效能 可擴充套件性和可用性提公升領域有所深入，但由於這些經驗的沉澱，沒有比較集中的學習資料輔助，並且也一直沒有接觸過有大規模訪問需求的web專案，因此總是在這個領域門外徘徊。上星期讀到一本書，構建高效能web站點 感覺有點如獲至寶，完全可以稱為高效能web的入門寶典，雖然內容不夠深入，...
MySQL 如何構建高效能MySQL系統
一 簡介 最近在壓測新的儲存，正好把工作過程中積累的對高效能mysql相關的知識體系構建起來，做成思維導圖的方式。總結乃一家之言，有不妥之處，望給位讀者朋友指正。二 思維導圖 構建高效能mysql系統涵蓋從單機 硬體，os 檔案系統，記憶體，到mysql 本身的配置，以及schema 設計，索引設計...