如果你翻閱過一些關(guān)于大型網(wǎng)站擴(kuò)展（Scaling）的資料，那么你可能聽說過一個(gè)叫memcached的東西。memcached是一個(gè)高性能、分布式的內(nèi)存對象緩存系統(tǒng)。我們Facebook可能是世界上最大的memcached用戶了。我們利用memcached來減輕數(shù)據(jù)庫的負(fù)擔(dān)。memcached確實(shí)很快，但是我們還要讓他更快、更高效。我們使用了超過800臺服務(wù)器，提供超過28TB的內(nèi)存來服務(wù)于用戶。在過去的一年里，隨著Facebook的用戶量直線上升，我們遇到了一系列的擴(kuò)展問題。日益增長的需求使得我們必須對操作系統(tǒng)和memcached進(jìn)行一些修改，以獲得足夠的性能來為我們的用戶提供最好的體驗(yàn)。
因?yàn)槲覀冇泻脦浊_機(jī)器，每個(gè)都運(yùn)行了幾百個(gè)Apache進(jìn)程甚至更多，最終導(dǎo)致到memcached進(jìn)程的TCP鏈接有幾十萬個(gè)。這些鏈接本身并不是什么大問題，但是memcached為每個(gè)TCP鏈接分配內(nèi)存的方法卻很成問題。memcached為每個(gè)鏈接使用單獨(dú)的緩存進(jìn)行數(shù)據(jù)的讀寫。當(dāng)達(dá)到幾十萬鏈接的時(shí)候，這些累計(jì)起來達(dá)好幾個(gè)G——這些內(nèi)存其實(shí)可以更好地用于存儲用戶數(shù)據(jù)。為了收復(fù)這些內(nèi)存，我們實(shí)現(xiàn)了一個(gè)針對TCP和UDP套接字的每線程共享的鏈接緩存池。這個(gè)改變使每個(gè)服務(wù)器可以收回幾個(gè)G的內(nèi)存。
雖然TCP上我們改進(jìn)了內(nèi)存的使用效率，但我們還是轉(zhuǎn)向了UDP，目的是讓get（獲取）操作能降低網(wǎng)絡(luò)流量、讓multi-get（同時(shí)并行地獲取幾百個(gè)鍵值）能實(shí)現(xiàn)應(yīng)用程序級別的流量控制。我們發(fā)現(xiàn)Linux上到了一定負(fù)載之后，UDP的性能下降地很厲害。這是由于，當(dāng)從多個(gè)線程通過單個(gè)套接字傳遞數(shù)據(jù)時(shí)，在UDP套接字鎖上產(chǎn)生的大量鎖競爭導(dǎo)致的。要通過分離鎖來修復(fù)內(nèi)核恐怕不太容易。所以，我們使用了分離的UDP套接字來傳遞回復(fù)（每個(gè)線程用一個(gè)答復(fù)套接字）。這樣改動(dòng)之后，我們就可以部署UDP同時(shí)后端性能不打折。
另一個(gè)Linux中的問題是到了一定負(fù)載后，某個(gè)核心可能因進(jìn)行網(wǎng)絡(luò)軟終端處理會(huì)飽和而限制了網(wǎng)絡(luò)IO。在Linux中，網(wǎng)絡(luò)中斷只會(huì)總是傳遞給某個(gè)核心，因此所有的接受軟終端的網(wǎng)絡(luò)處理都發(fā)生在該內(nèi)核上。另外，我們還發(fā)現(xiàn)某些網(wǎng)卡有過高的中斷頻率。我們通過引入網(wǎng)絡(luò)接口的“投機(jī)”輪詢解決了這兩個(gè)問題。在該模型中，我們組合了中斷驅(qū)動(dòng)和輪詢驅(qū)動(dòng)的網(wǎng)絡(luò)IO。一旦進(jìn)入網(wǎng)絡(luò)驅(qū)動(dòng)（通常是傳輸一個(gè)數(shù)據(jù)包時(shí)）以及在進(jìn)程調(diào)度器的空閑循環(huán)的時(shí)候，對網(wǎng)絡(luò)接口進(jìn)行輪詢。另外，我們也用到了中斷（來控制延遲），不過網(wǎng)絡(luò)中斷用到的數(shù)量大大減少（一般通過大幅度提升中斷聯(lián)結(jié)閾值interrupt coalescing thresholds）。由于我們在每個(gè)核心上進(jìn)行網(wǎng)絡(luò)傳輸，同時(shí)由于在調(diào)度器的空閑循環(huán)中對網(wǎng)絡(luò)IO進(jìn)行輪詢，我們將網(wǎng)絡(luò)處理均勻地分散到每個(gè)核心上。
最后，當(dāng)開始部署8核機(jī)器的時(shí)候，我們在測試中發(fā)現(xiàn)了新的瓶頸。首先，memcached的stat工具集依賴于一個(gè)全局鎖。這在4核上已經(jīng)很令人討厭了，在8核上，這個(gè)鎖可以占用20-30%的CPU使用率。我們通過將stats工具集移入每個(gè)線程，并且需要的時(shí)候?qū)⒔Y(jié)果聚合起來。其次，我們發(fā)現(xiàn)隨著傳遞UDP數(shù)據(jù)包的線程數(shù)量的增加，性能卻在降低。最后在保護(hù)每個(gè)網(wǎng)絡(luò)設(shè)備的傳送隊(duì)列的鎖上發(fā)現(xiàn)了嚴(yán)重的爭用。數(shù)據(jù)包是由設(shè)備驅(qū)動(dòng)進(jìn)行入隊(duì)傳輸和出隊(duì)。該隊(duì)列由Linux的“netdevice”層來管理，它位于IP和設(shè)備驅(qū)動(dòng)之間。每次只能有一個(gè)數(shù)據(jù)包加入或移出隊(duì)列，這造成了嚴(yán)重的爭用。我們當(dāng)中的一位工程師修改了出隊(duì)算法，實(shí)現(xiàn)了傳輸?shù)呐砍鲫?duì)，去掉了隊(duì)列鎖，然后批量傳送數(shù)據(jù)包。這個(gè)更正將請求鎖的開銷平攤到了多個(gè)數(shù)據(jù)包，顯著地減少了鎖爭用，這樣我們就能在8核系統(tǒng)上將memcached伸展至8線程。
做了這些修改之后，我們可以將memcached提升到每秒處理20萬個(gè)UDP請求，平均延遲降低為173微秒。可以達(dá)到的總吞吐量為30萬UDP請求/s，不過在這個(gè)請求速度上的延遲太高，因此在我們的系統(tǒng)中用處不大。對于普通版本的Linux和memcached上的50,000 UDP請求/s而言，這是個(gè)了不起的提升。
我們希望盡快將我們的修改集成到官方的memcached倉庫中去，我們決定在這之前，先將我們對memcached的修改發(fā)布到github上。