【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集群上獲取數據。
（文/蒲婧 責編/魏兵）
本文為CSDN原創文章，未經允許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)