PHP構建高性能系統

如何解決系統中可能存在的性能問題呢？

首先，咱們須要清楚在業務上有什麼要樣的性能需求；

第二步，根據性能的要求去考慮系統的設計，

第三步，系統的開發過程當中去關注可能存在的局部性能問題。

評估系統的性能要求：

沒有開發過性能敏感系統的團隊，容易犯的錯誤是，不去考慮系統未來有多少人使用，併發訪問有多高，須要存貯多少數量的數據？ 直接就開始作系統的開發，抱着等着出了性能問題再說。系統作出來上線以後，性能的問題就暴露出來。但這時候，要解決好性能問題將要負出沉重的代價，每每是 一個系統的重寫。 進度的壓力成爲了避免考質量與性能的理由。形成一個現象：咱們沒有時間去把一個系統作好，但咱們有時間去把同一個系統作上幾遍。短時間是高效率的，但長期是低效率的。

在開發一個新系統時，請搞清楚如下的幾個問題：

• 系統的用戶有多少？ 萬級 、 十萬級、百萬級、仍是更多？
• 系統的使用的高峯階段有多少人來使用？ 每鈔能處理多少個請求（QPS）？
• 系統存貯的數據記錄有多少條？ 數據量是G，10G,仍是100G?

我舉例說明一下：

*廣告投放系統：

10個用戶以對系統有寫的訪問， 1000萬級的用戶對系統有訪問。
廣告主要投放在網站上， 一個頁面每每具備幾個廣告的展示。天天要達到上億的PV。高峯的QPS所達到上十億。
廣告天天的數據量在1G之內，沒有歷史數據須要處理。

*互動貼吧：

千萬級的用戶量，而且都進行讀寫操做。
系統在熱門期間，須要支持1億的PV，高峯QPS 要達到1250 * 2 = 2500 QPS
貼吧的貼子數： 10000貼吧 * 1000主題 * 100 貼子 ＝ 10億個貼子； 一個貼子平均200個漢字，即有 400G的數據量。

*B2B網站：

用戶量應具備百萬級.
以每用戶天天平均訪問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，甚至會更高。高併發訪問的性能問題，就會減化爲， 如何提升併發的讀訪問速度和保證寫訪問的正確性有及時性。

在開發系統中，咱們經常會出現兩種如下的作法：

1. 整個系統的開發追求性能，系統沒有什麼結構，全部的功能的實現都是，直接在頁面拼寫SQL來讀寫數據。
2. 全面考慮程序的結構，追求系統的擴展性和可維性。

這兩種方法，都有他們適用的範圍，但同時也有他們的不足。

• 先說第二種方法，面對業務層面和系統層面的複雜性，抽象成爲解決問題的有效手段。在抽象的指導下，封裝、隱藏實現、隔離變化、分層都會出現系統的 設計中，但這樣的設計帶來的問題是間接層過多，在PHP這種動態腳本語言下，更多的代碼、更多的調用層次都是會下降性能。 它適用於邏輯的複雜的系統，但性能要求在50(QPS)如下.
• 第一種方法，有一句來形容」在山頂上速度最快的下山方法就是從山頂上直接跳下來」 用直接數據修改的方法，沒法有效表達抽象，沒法管理各類變化的因素，數據將不在統一的邏輯約束下變動,咱們將對變化失去控制，咱們面對將是一座千瘡百孔的 爛尾樓。 正確性雖着業務屢次的修改，愈來愈得不到保證，這時性能也沒有什麼意義？ 這種方式合適於邏輯簡單的功能。

面對不一樣的要求，咱們須要區別對待， 讀寫分離的思路，不只是程序和程序開發模式的分離，它還意味着：

• 系統的體系結構的影響，創建集中寫（單點寫）、多點讀的模式。 它包括前端服務器的部署、數據存貯和同步方案等。
• 可使得讀的邏輯儘量的簡單，不受寫邏輯的干擾。有價值的放棄對於讀訪問邏輯的抽象，數據不會變動，不須要統一邏輯的約束。 面對性能的要求，咱們能夠棄程序的結構，以致於可重複某些代碼。
• 面對簡單的讀邏輯咱們能夠有更多的性能優化方案。
• 讀寫分離也是解決軍閥割據般的網絡環境（電信、網通）的方法。

舉例說明:
*聯盟的廣告展示代碼不到100行。廣告的展示代碼不到500行(由於定向投放)，其中的邏輯只是讀取本地數據，套展示模版。 全部數據都郵後端推送到前端的WEB服務器。而廣告數據的生成修改，就有很複雜的系統來管理，這基本不考慮性能的問題.
*互動組開發評論系統和貼吧系統，設定的考慮也是讀寫分離的模式，寫邏輯強調代碼的結構良好，讀邏輯追求性能。

考慮使用緩衝數據的機制:

在越接用戶和越接用具體應用時，緩衝的效率越高。 所以可能考慮在WEB服務器來創建一緩存。 在緩存機制的設計與使用，互動團隊的貼吧系統應是值得學習的項目。固然咱們也清楚那些好東西是作緩存的必備良藥。Memched,BDB, varnish 須要清楚他們適合解決的問題是什麼，加以利用。

無論Cache的機制如何有效，但咱們還得保證在無Cache的狀況下，性能基本知足業務的須要。由於Cache老是有他的命中率的，而且也要考慮到在Cache失效後，咱們系統仍是能正常運行的。

在個人理解，」’Cache是性能的放大器。」’

在系統開發過程當中，怎麼考慮處理性能的風險

在系統的開發過程的管理，本質上仍是以風險驅動的，什麼最可能產生嚴重的問題，就應該去優先去解決。在評估性能後，咱們須要的是一個高性能要求的系統，而且系統一上線，就會立刻遇到這種性能的壓力，那麼我建議以下：

1. 跟據上述的設計原則來指導你設計，並與有經驗的人進行計論
2. 藉着樁的方式，快速搭建系統框架，進行性能測試，肯定總體的性能，總體的性能高於局部的性能。
3. 解決是性能關鍵的子系統或組件的問題，這是解決局部性能問題。
4. 在提交功能測試前進行性能測試，不要等上線以後才發現性能的問題。

對於進度緊張，而且預期在將來半年內不會遇到性能挑戰，關於上述的第3點能夠先不作。但你對於系統的當前情況必定要清楚。 在系統在性能挑戰出現以後，就可從容的去解決性能的問題。