PHP 大流量優化？

01-05

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

如果把寫緩存在Redis中,那程序就要承擔數據可能丟失的風險,不關鍵的數據還好,比如文章閱讀次數,頂踩次數,如果是關鍵的數據,比如商品庫存或者用戶餘額,丟了會很麻煩.這也是為什麼資料庫引擎MySQL InnoDB默認會用自動提交的事務實現寫操作(如UPDATE),用事務的ACID確保安全正確地持久化數據.

像Memcached這個服務定位就比較清晰,作者也說過,Memcached不是用來進行寫緩存的,比如不建議用來緩存用戶會話($_SESSION),因為Memcached的LRU機制會在內存不足時會刪除掉近期最少使用的數據,可能會導致寫緩存的數據丟失,所以Memcached的定位就是讀緩存.

而Redis貌似事管得比較多,又是寫緩存,又是持久化.因為要緩存寫,所以不能用LUR,只能noeviction(不回收),內存不夠直接報錯.而Redis如果要實現安全的持久化,那寫的成本跟MySQL無異,性能自然也高不到哪,而人家MySQL InnoDB是多線程和行鎖,事務寫操作性能肯定比單線程的Redis高.感覺Redis有些越俎代庖.不過Redis也確實滿足了一些容許寫緩存丟失一段時間的寫入場景.

如果是覺得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系統搭建――單機到分散式集群

緩存掛了你這數據難道不要了？不是在開玩笑吧。

緩存優化的是讀，寫數據不要走這邪路。

1.緩存

規划下目標數據的更改頻率和讀寫頻率。

讀寫頻率：更改頻率值越大，越適合做緩存；值小的就別做了

2.優化SQL

大部分的初級系統的SQL 優化程度都不高……

索引的使用、單一查詢是否過大、聯表查詢替換為單表查詢

MYISAM替換為INNODB 這類的……

3.優化系統架構

單一頁面中涉及的內容是否太多，是否有不必要的數據展示

能否將很多的功能與系統拆分成不同的業務模塊分開展示

4.靜態化頁面

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

5.緩存數據延時讀取

寫入隊列、緩存暫存數據(比如計數器) 都屬於這種

6.非同步式獲取數據

7.分散式架構

資料庫的讀寫分離，多台資料庫伺服器乃至多台PHP伺服器等

我是來關注問題的，不過。。。現在大部分內存緩存都是對讀做優化的。。。對寫優化的解決方案？？？

我其實是來關注問題的。。

優化不難，但需要對症下藥。

題主，你的問題描述，沒說癥狀，沒查病因，就直接跳躍到制定治療方案：【所有的PHP與mysql脫鉤......】，這真的好？

先應該找出癥結，而不應該盲目優化。

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

你說的「所有的PHP與mysql脫鉤中間加入緩存層」就不太好，其實大部分情況下你所謂的緩存層不過是把mysql的查詢緩存功能廢了自己接管，意義不大。而且像報名這種重要的數據也不適合緩存，一旦緩存丟失，比較麻煩。

有時候的瓶頸不一定在資料庫，先搞清楚是前端還是後端問題。如果是前端就要做各種優化處理，包括緩存靜態文件，合併並且壓縮css, js等文件，盡量減少HTTP request等等。如果是後端資料庫讀寫性能問題就先做下Profiling找下瓶頸在哪。如果真的是要加緩存層建議用Redis，支持數據持久化。另外可以考慮消息隊列非同步處理通信，達到程序解耦的目的。消息隊列可以很好地應付突然的峰值流量，個人推薦RabbitMQ，我們公司也在用。還有就是可以使用獨立的全文搜索引擎，降低資料庫的搜索壓力，Solr, ElasticSearch都好用，我自己用的是Solr。

讀這篇，全部讀懂再說：

編輯於 2014-05-07

最好還是先優化一下讀寫MySQL的業務邏輯，會員註冊報名這種功能都需要加緩存了，那跑起來得多慢

首先讀寫分離！

讓後緩存優化！

寫入做延時和列隊！

寫入的數據先寫入緩存列隊！

然後程序處理列隊！

讀取數據～優先查找緩存！沒有命中的再插資料庫！再緩存！

讀寫分離可以解決寫入鎖的問題！

緩存是利用二八原則～

20%熱點數據～應對80%的流量～

寫用消息隊列，讀用nosql

1.索引

2.緩存

3.讀寫分離

4.縱向分表

5.橫向分表

那個啥，我認為啊，資料庫的讀寫優化可以根據系統本身的情況來判斷，對症下藥。寫入的話，我認為非同步比較好，壓力較小，讀取倒不如使用緩存，就算數據丟失，在讀取一份就好了，至於資料庫緩存我不太建議，以為這種緩存實效的可能太大了

可以考慮負載均衡加主從資料庫

先分析是什麼導致了性能瓶頸再對症下藥一般一個系統肯定讀大於寫考慮讀寫分離讀加redis緩存寫入應該是實時的如果寫瓶頸可以考慮分庫分表

各種NoSQL，CBase及MC常見些

你說的這個中間層叫隊列，可以用redis的list去做