PHP 大流量最佳化？

現在網站流量大幅上升 我們技術組基本的思路是 所有的PHP與mysql脫鉤 中間加入緩衝層 比如會員報名先寫入伺服器記憶體 然後統一的時間一起寫入資料庫 請問中間的緩衝層會用到哪些技術 對這個重來沒有接觸過

回複內容：

如果是覺得mysql的讀和寫是瓶頸的話（mysql的查詢和寫入耗時很長，或者量級比較大），的確可以引入中間緩衝。
搭建mysql和PHP之間的緩衝，推薦直接使用redis作為中間快取服務。

不過，還是需要分析下為什麼是mysql的讀和寫耗時很長，才能夠真正解決你系統的問題，可以開啟mysql的慢查詢日誌分析下。
讀和寫如果有問題，可以往這幾個方面做下嘗試：
（1）sql語句是不是合理的，是否帶有太多的表join等操作？
（2）table的記錄是否太多了，好幾百萬的資料，是否需要分庫分表或者分區？
（3）是否使用了合適的索引，sql查詢語句是否有充分利用索引欄位？
（4）可以通過調整mysql配置參數，來最佳化mysql讀和寫的效能，例如增大innodb_buffer_pool_size，提高緩衝的命中率等。
（5）mysql如果是單台部署，可以考慮主從分離，或者搭建主主互備。
... ...

如果覺得mysql在上述最佳化之後，仍然存在一些瓶頸，再引入redis作為中間cache也並不遲。

其實，我上面寫的只是冰山一角，可以最佳化的地方還有非常多哈。
早期寫的一篇文章：
億級Web系統搭建――單機到分布式叢集 最佳化不難，但需要對症下藥。

題主，你的問題描述，沒說癥狀，沒查病因，就直接跳躍到制定治療方案：【所有的PHP與mysql脫鉤......】，這真的好？我是來關注問題的，不過。。。現在大部分記憶體緩衝都是對讀做最佳化的。。。對寫最佳化的解決方案？？？

我其實是來關注問題的。。先應該找出癥結，而不應該盲目最佳化。

常見的寫入引起系統速度慢通常是計數這種頻繁寫入的情境，比如：每訪問頁面一次，pv欄位+1，頻繁寫入導致MySQL的查詢快取剛建立就馬上失效，相當於沒發揮作用。這種情況是很適合搞個緩衝區（寫入極頻繁、無資料一致性要求），來存放新增的pv的，當緩衝區滿了，再一次性寫入。

你說的“ 所有的PHP與mysql脫鉤 中間加入緩衝層”就不太好，其實大部分情況下你所謂的緩衝層不過是把mysql的查詢快取功能廢了自己接管，意義不大。而且像報名這種重要的資料也不適合緩衝，一旦緩衝丟失，比較麻煩。你說的這個中介層 叫隊列，可以用redis的list去做最好還是先最佳化一下讀寫MySQL的商務邏輯，會員註冊報名這種功能都需要加緩衝了，那跑起來得多慢緩衝掛了你這資料難道不要了？不是在開玩笑吧。
緩衝最佳化的是讀，寫資料不要走這邪路。1.緩衝
規划下目標資料的更改頻率和讀寫頻率。
讀寫頻率：更改頻率 值越大，越適合做緩衝；值小的就別做了

2.最佳化SQL
大部分的初級系統的SQL 最佳化程度都不高……
索引的使用、單一查詢是否過大、聯表查詢替換為單表查詢
MYISAM替換為INNODB 這類的……

3.最佳化系統架構
單一頁面中涉及的內容是否太多，是否有不必要的資料展示
能否將很多的功能與系統拆分成不同的業務模組 分開展示

4.靜態化頁面
靜態頁面比起動態網頁面來自然會消耗小的多

5.快取資料延時讀取
寫入隊列、緩衝暫存資料(比如計數器) 都屬於這種

6.非同步式擷取資料

7.分布式架構
資料庫的讀寫分離 ， 多台資料庫伺服器 乃至 多台PHP伺服器 等讀這篇，全部讀懂再說：
編輯於 2014-05-07有時候的瓶頸不一定在資料庫，先搞清楚是前端還是後端問題。如果是前端就要做各種最佳化處理，包括緩衝靜態檔案，合并並且壓縮css, js等檔案，盡量減少HTTP request等等。如果是後端資料庫讀寫效能問題就先做下Profiling找下瓶頸在哪。如果真的是要加緩衝層建議用Redis， 支援資料持久化。另外可以考慮訊息佇列非同步處理通訊，達到程式解耦的目的。訊息佇列可以很好地應付 突然的峰值流量，個人推薦RabbitMQ，我們公司也在用。還有就是可以使用獨立的全文檢索搜尋引擎，降低資料庫的搜尋壓力，Solr, Elasticsearch都好用，我自己用的是Solr。

