新浪微博宋琦：PHP在微博優化中的「大顯身手」

摘要：2013中國軟件開發者大會編程語言與工具專題論壇中，新浪微博架構師宋琦介紹了PHP在新浪微博中的應用，而且分享了不少微博主站所作的性能優化的工做。

【CSDN報道】 2013中國軟件開發者大會（如下簡稱SDCC）於8月30-31日在北京新雲南皇冠假日酒店舉辦。做爲CSDN和《程序員》雜誌傾力打造、千人規模以上的頂級技術盛會，今年SDCC 2013以「軟件定義將來」爲主題，來自於國內外一線的技術精英，就大數據分析與BI、架構實踐、研發管理、IT基礎設施與運維、產品與設計、開放平臺等專題和參會者進行了深刻的分享和探討。此外，32小時編程馬拉松、CTO論道論壇等量身定製的特點環節也受到了參會者的強烈關注。

31日下午的編程語言與工具專題論壇上，新浪微博主站架構師宋琦與你們分享和探討了關於PHP在新浪微博實際中的應用狀況。

在進入新浪微博以前，宋琦一直在作商業產品，使用的是傳統的LAMP架構。而一般商業產品不涉及到很大流量，只是業務邏輯比較複雜。宋琦說當時他關注的主要是框架、擴展性、安全性方面的話題，對性能關注的較少。「以後選擇作微博，是由於我認爲對於程序員來講，微博產品所帶來的技術挑戰是通常產品沒法比的。在大數據和大訪問量下，任何東西都有可能成爲很是棘手的問題。」宋琦說。

由於微博自己的一些特性，使得傳統的LAMP架構，傳統的框架、模板系統等在微博中變得再也不適用，須要更加深刻了解系統底層，才能應對更多挑戰。

微博海量數據不容小覷

宋琦列了一組數據，微博用戶數大約5.5億，假設每一個人有100條關注關係，那麼總共就有550億條用戶關係，用兩個long也就是16個字節來表示一個關注關係的話，那麼單獨保存這些關注關係就須要800G的存儲空間。「以往在db裏用一個map表就解決的事，放在這個場景下就變得好笑了。」宋琦說。

那麼微博的訪問量有多大呢？宋琦說，在2013年除夕當晚，蛇年第一秒共發出近35000條微博，第一分鐘發出近73萬條微博。這個只是上行的數據量，而下行的數據量是這個的N倍還多。因而可知，這樣的數據量很是驚人。

響應速度關乎用戶體驗

在如此大的數據量和訪問量下，微博對響應速度的要求很是高。有研究數據顯示，若是一個頁面響應速度超過3秒，那麼57%的用戶就會放棄；而在登陸某網站時，若超過5秒，74%的用戶就不會再登陸；亞馬遜的主頁響應時間每延長1秒，每一年就會減小16億美圓的銷售額；而Google搜索結果每慢0.4秒，一天搜索量將減小800萬次。

「總之，這些數據都說明了響應速度的重要性，能夠說響應速度是保障流暢用戶體驗的基礎。咱們Team的主要KPI之一就是提高微博的性能。」宋琦補充道。

數據加載的優化

宋琦指出，微博有不少的配置文件，有幾十個，這些配置每一次請求都要被加載，都要從新申請內存存放這些配置。而配置文件的修改是很是少的，那麼可不能夠只加載一次就能夠一直使用呢？很遺憾PHP是作不到的，PHP腳本中所申請的資源在請求結束後全都會被釋放。「因而咱們一樣使用PHP擴展來解決了它，咱們建立了一個名叫Weibo_Conf的擴展，他在php-fpm啓動階段掃描指定的目錄，將其下的.ini文件加載到內存中，每5分鐘更新一次。這樣服務器每一次接到請求時，不須要從新加載這些配置，而是直接取用，效率提高了很多。」宋琦介紹說。

除了配置外，還有一些須要常駐內存，並且不常變化的東西，可是這些的量更大一些，好比白名單/黑名單，或者切詞服務的字典等。這些東西以往都是放在數據庫或者MC當中，而後經過http開放接口供遠程調用。「由於他們的邏輯都比較簡單或者固定，不太常變化，咱們將他們獨立出來作成單獨的C服務，用的是yar的兄弟yar-c，yar-c所作的工做就是提供一個基於C的RPC框架，幫你完成網絡和進程方面的管理，讓你能夠專一於實現業務邏輯，同時更方便的是，經過PHP的yar擴展能夠直接調用，也就是說PHP端不管是對於基於yar-c的socket RPC服務仍是基於yar的http RPC服務，無需作出改變既能夠通用。」宋琦說道。

緩存優化

衆所周知，對於訪問量巨大的服務來講，緩存是必不可少的，而微博是一個重度依賴緩存的應用。宋琦指出，微博前端展示的數據所有依賴於開放平臺，開放平臺提供的是基於http的RESTFul的接口，響應速度通常，因此爲了提速同時下降對開放平臺形成的負載，微博大量的使用了MC來緩存數據。「可是用MC也不是輕輕鬆鬆就能知足咱們須要的。咱們作個計算，假設咱們每臺服務器上開啓128個php-fpm，總共100臺服務器，若是每一個請求響應時間是1秒，從請求開始就鏈接MC而且等到請求結束後才自動釋放，那麼每一臺MC上至少有上萬的鏈接，實際微博的量比這個還要大的多，這樣MC的效率就會慢下來，同時增長了PHP處理請求的耗時，又進一步加重了鏈接佔用的狀況，很容易形成雪崩效應。」宋琦指出。

 

針對此問題，宋琦展現了兩種解決方案：

一種是引入一個proxy來代理對MC的訪問，twitter採用的是這種方案，經過代理，php-fpm與proxy、proxy與MC之間均可以維持長鏈接，而且請求能夠在proxy上作合併。twitter開源了他們的這個代理twemproxy。能夠看到在加入twemproxy以後，MC集羣的鏈接數大大下降了。

可是在加入了一層proxy以後，由於要經過一層twemproxy，會使得MC請求的響應變慢，因而採用了另一個方案：增長一層緩存作成多級緩存。

 

首先經過會話保持，讓一個用戶的每一次訪問都落到固定的一臺機器上，而後咱們在前端機的本地開啓一個本地緩存，用它來擋在MC集羣以前，下降對MC的訪問。這層本地緩存的實際命中率大概在60%~70%左右，這些請求只須要從本地緩存中獲取數據，就不須要走網絡從MC集羣上獲取數據。

 

 

 

摘自：http://www.csdn.net/article/2013-09-04/2816820-sina