在Web服務(wù)開發(fā)中，服務(wù)端緩存是服務(wù)實(shí)現(xiàn)中所常常采用的一種提高服務(wù)性能的方法。其通過記錄某部分計算結(jié)果來嘗試避免再次執(zhí)行得到該結(jié)果所需要的復(fù)雜計算，從而提高了服務(wù)的運(yùn)行效率。

除了能夠提高服務(wù)的運(yùn)行效率之外，服務(wù)端緩存還常常用來提高服務(wù)的擴(kuò)展性。因此一些大規(guī)模的Web應(yīng)用，如Facebook，常常構(gòu)建一個龐大的服務(wù)端緩存。而它們所最常使用的就是Memcached。

在本文中，我們就將對Memcached進(jìn)行簡單地介紹。

[[249450]]

Memcached簡介

在介紹Memcached之前，讓我們首先通過一個示例了解什么是服務(wù)端緩存。

相信大家都玩過一些網(wǎng)絡(luò)聯(lián)機(jī)游戲吧。在我那個年代（03年左右），這些游戲常常添加了對戰(zhàn)功能，并提供了天梯來顯示具有***秀戰(zhàn)績的玩家以及當(dāng) 前玩家在天梯系統(tǒng)中的排名。這是游戲開發(fā)商所常常采用的一種聚攏玩家人氣的手段。而希望在游戲中證明自己的玩家則會由此激發(fā)斗志，進(jìn)而花費(fèi)更多時間來在天 梯中取得更好的成績。

就天梯系統(tǒng)來說，其最主要的功能就是為玩家提供天梯排名的信息，而并不允許玩家對該系統(tǒng)中所記錄的數(shù)據(jù)作任何修改。這樣設(shè)定的結(jié)果就是，整個天 梯系統(tǒng)的讀操作居多，而寫操作很少。反過來，由于一個游戲中的玩家可能有上千萬甚至上億人，而且在線人數(shù)常常達(dá)到上萬人，因此對天梯的訪問也會是非常頻繁 的。這樣的話，即使每秒鐘只有10個人訪問天梯中的排名，對這上億個玩家的天梯排名進(jìn)行讀取及排序也是一件非常消耗性能的事情。

一個自然而然的想法就是：在對天梯排名進(jìn)行一次計算后，我們在服務(wù)端將該天梯排名緩存起來，并在其它玩家訪問的時候直接返回該緩存中所記錄的結(jié) 果。而在一定時間段之后，如一個小時，我們再對緩存中的數(shù)據(jù)進(jìn)行更新。這樣我們就不再需要每個小時執(zhí)行成千上萬次的天梯排名計算了。

而這就是服務(wù)端緩存所提供的最重要功能。其既可以提高單個請求的響應(yīng)速度，又可以降低服務(wù)層及數(shù)據(jù)庫層的壓力。除此之外，多個服務(wù)實(shí)例都可以讀 取該服務(wù)端緩存所緩存的信息，因此我們也不再需要擔(dān)心這些數(shù)據(jù)在各個服務(wù)實(shí)例中都保存了一份進(jìn)而需要彼此同步的問題，也即是提高了擴(kuò)展性。

而Memcached就是一個使用了BSD許可的服務(wù)端緩存實(shí)現(xiàn)。但是與其它服務(wù)端緩存實(shí)現(xiàn)不同的是，其主要由兩部分組成：獨(dú)立運(yùn)行的 Memcached服務(wù)實(shí)例，以及用于訪問這些服務(wù)實(shí)例的客戶端。因此相較于普通服務(wù)端緩存實(shí)現(xiàn)中各個緩存都運(yùn)行在服務(wù)實(shí)例之上的情 況，Memcached服務(wù)實(shí)例則是在服務(wù)實(shí)例之外獨(dú)立運(yùn)行的：

從上圖中可以看出，由于Memcached緩存實(shí)例是獨(dú)立于各個應(yīng)用服務(wù)器實(shí)例運(yùn)行的，因此應(yīng)用服務(wù)實(shí)例可以訪問任意的緩存實(shí)例。而傳統(tǒng)的緩存則與 特定的應(yīng)用實(shí)例綁定，因此每個應(yīng)用實(shí)例將只能訪問特定的緩存。這種綁定一方面會導(dǎo)致整個應(yīng)用所能夠訪問的緩存容量變得很小，另一方面也可能導(dǎo)致不同的緩存 實(shí)例中存在著冗余的數(shù)據(jù)，從而降低了緩存系統(tǒng)的整體效率。

在運(yùn)行時，Memcached服務(wù)實(shí)例只需要消耗非常少的CPU資源，卻需要使用大量的內(nèi)存。因此在決定如何組織您的服務(wù)端緩存結(jié)構(gòu)之前，您首 先需要搞清當(dāng)前服務(wù)中各個服務(wù)實(shí)例的負(fù)載情況。如果一個服務(wù)器的CPU使用率非常高，卻存在著非常多的空余內(nèi)存，那么我們就完全可以在其上運(yùn)行一個 Memcached實(shí)例。而如果當(dāng)前服務(wù)中的所有服務(wù)實(shí)例都沒有過多的空余內(nèi)存，那么我們就需要使用一系列獨(dú)立的服務(wù)實(shí)例來搭建服務(wù)端緩存。一個大型服務(wù) 常常擁有上百個Memcached實(shí)例。而在這上百個Memcached實(shí)例中所存儲的數(shù)據(jù)則不盡相同。由于這種數(shù)據(jù)的異構(gòu)性，我們需要在訪問由 Memcached所記錄的信息之前決定在該服務(wù)端緩存系統(tǒng)中到底由哪個Memcached實(shí)例記錄了我們所想要訪問的數(shù)據(jù)：

如上圖所示，用戶需要通過一個Memcached客戶端來完成對緩存服務(wù)所記錄信息的訪問。該客戶端知道服務(wù)端緩存系統(tǒng)中所包含的所有 Memcached服務(wù)實(shí)例。在需要訪問具有特定鍵值的數(shù)據(jù)時，該客戶端內(nèi)部會根據(jù)所需要讀取的數(shù)據(jù)的鍵值，如“foo”，以及當(dāng)前Memcached緩 存服務(wù)的配置來計算相應(yīng)的哈希值，以決定到底是哪個Memcached實(shí)例記錄了用戶所需要訪問的信息。在決定記錄了所需要信息的Memcached實(shí)例 之后，Memcached客戶端將從配置中讀取該Memcached服務(wù)實(shí)例所在地址，并向該Memcached實(shí)例發(fā)送數(shù)據(jù)訪問請求，以從該 Memcached實(shí)例中讀取具有鍵值“foo”的信息。在各個論壇的討論中，這被稱為是Memcached的兩階段哈希（Two-stage hash）。

而對數(shù)據(jù)的記錄也使用了類似的流程：假設(shè)用戶希望通過服務(wù)端緩存記錄數(shù)據(jù)“bar”，并為其指定鍵值“foo”。那么Memcached客戶端 將首先對用戶所賦予的鍵值“foo”及當(dāng)前服務(wù)端緩存所記錄的可用服務(wù)實(shí)例個數(shù)執(zhí)行哈希計算，并根據(jù)哈希計算結(jié)果來決定存儲該數(shù)據(jù)的Memcached服 務(wù)實(shí)例。接下來，客戶端就會向該實(shí)例發(fā)送請求，以在其中記錄具有鍵值“foo”的數(shù)據(jù)“bar”。

這樣做的好處則在于，每個Memcached服務(wù)實(shí)例都是獨(dú)立的，而彼此之間并沒有任何交互。在這種情況下，我們可以省略很多復(fù)雜的功能邏輯， 如各個節(jié)點(diǎn)之間的數(shù)據(jù)同步以及結(jié)點(diǎn)之間消息的廣播等等。這種輕量級的架構(gòu)可以簡化很多操作。如在一個節(jié)點(diǎn)失效的時候，我們僅僅需要使用一個新的 Memcached節(jié)點(diǎn)替代老節(jié)點(diǎn)即可。而在對緩存進(jìn)行擴(kuò)容的時候，我們也只需要添加額外的服務(wù)并修改客戶端配置。

這些記錄在服務(wù)端緩存中的數(shù)據(jù)是全局可見的。也就是說，一旦在Memcached服務(wù)端緩存中成功添加了一條新的記錄，那么其它使用該緩存服務(wù)的應(yīng)用實(shí)例將同樣可以訪問該記錄：

在Memcached中，每條記錄都由四部分組成：記錄的鍵，有效期，一系列可選的標(biāo)記以及表示記錄內(nèi)容的數(shù)據(jù)。由于記錄內(nèi)容的數(shù)據(jù)中并不包含任何數(shù)據(jù)結(jié)構(gòu)，因此我們在Memcached中所記錄的數(shù)據(jù)需要是經(jīng)過序列化之后的表示。

內(nèi)存管理

在使用緩存時，我們不得不考慮的一個問題就是如何對這些緩存數(shù)據(jù)的生存期進(jìn)行管理。這其中包括如何使一個記錄在緩存中的數(shù)據(jù)過期，如何在緩存空間不夠時執(zhí)行數(shù)據(jù)的替換等。因此在本節(jié)中，我們將對Memcached的內(nèi)存管理機(jī)制進(jìn)行介紹。

首先我們來看一看Memcached的內(nèi)存管理模型。通常情況下，一個內(nèi)存管理算法所最需要考慮的問題就是內(nèi)存的碎片化 （Fragmentation）：在長時間地分配及回收之后，被系統(tǒng)所使用的內(nèi)存將趨向于散落在不連續(xù)的空間中。這使得系統(tǒng)很難找到連續(xù)內(nèi)存空間，一方面 增大了內(nèi)存分配失敗的概率，另一方面也使得內(nèi)存分配工作變得更為復(fù)雜，降低了運(yùn)行效率。

為了解決這個問題，Memcached使用了一種叫Slab的結(jié)構(gòu)。在該分配算法中，內(nèi)存將按照1MB的大小劃分為頁，而該頁內(nèi)存則會繼續(xù)被分割為一系列具有相同大小的內(nèi)存塊：

因此Memcached并不是直接根據(jù)需要記錄的數(shù)據(jù)的大小來直接分配相應(yīng)大小的內(nèi)存。在一條新的記錄到來時，Memcached會首先檢查該記錄 的大小，并根據(jù)記錄的大小選擇記錄所需要存儲到的Slab類型。接下來，Memcached就會檢查其內(nèi)部所包含的該類型Slab。如果這些Slab中有 空余的塊，那么Memcached就會使用該塊記錄該條信息。如果已經(jīng)沒有Slab擁有空閑的具有合適大小的塊，那么Memcached就會創(chuàng)建一個新的 頁，并將該頁按照目標(biāo)Slab的類型進(jìn)行劃分。

一個需要考慮的特殊情況就是對記錄的更新。在對一個記錄進(jìn)行更新的時候，記錄的大小可能會發(fā)生變化。在這種情況下，其所對應(yīng)的Slab類型也可能會發(fā)生變化。因此在更新時，記錄在內(nèi)存中的位置可能會發(fā)生變化。只不過從用戶的角度來說，這并不可見。

Memcached使用這種方式來分配內(nèi)存的好處則在于，其可以降低由于記錄的多次讀寫而導(dǎo)致的碎片化。反過來，由于Memcached是根據(jù) 記錄的大小選擇需要插入到的塊類型，因此為每個記錄所分配的塊的大小常常大于該記錄所實(shí)際需要的內(nèi)存大小，進(jìn)而造成了內(nèi)存的浪費(fèi)。當(dāng)然，您可以通過 Memcached的配置文件來指定各個塊的大小，從而盡可能地減少內(nèi)存的浪費(fèi)。

但是需要注意的是，由于默認(rèn)情況下Memcached中每頁的大小為1MB，因此其單個塊***為1MB。除此之外，Memcached還限制每個數(shù)據(jù)所對應(yīng)的鍵的長度不能超過250個字節(jié)。

一般來說，Slab中各個塊的大小以及塊大小的遞增倍數(shù)可能會對記錄所載位置的選擇及內(nèi)存利用率有很大的影響。例如在當(dāng)前的實(shí)現(xiàn)下，各個 Slab中塊的大小默認(rèn)情況下是按照1.25倍的方式來遞增的。也就是說，在一個Memcached實(shí)例中，某種類型Slab所提供的塊的大小是80K， 而提供稍大一點(diǎn)空間的Slab類型所提供的塊的大小就將是100K。如果現(xiàn)在我們需要插入一條81K的記錄，那么Memcached就會選擇具有100K 塊大小的Slab，并嘗試找到一個具有空閑塊的Slab以存入該記錄。

同時您也需要注意到，我們使用的是100K塊大小的Slab來記錄具有81K大小的數(shù)據(jù)，因此記錄該數(shù)據(jù)所導(dǎo)致的內(nèi)存浪費(fèi)是19K，即19%的 浪費(fèi)。而在需要存儲的各條記錄的大小平均分布的情況下，這種內(nèi)存浪費(fèi)的幅度也在9%左右。該幅度實(shí)際上取決于我們剛剛提到的各個Slab中塊大小的遞增倍 數(shù)。在Memcached的初始實(shí)現(xiàn)中，各個Slab塊的遞增倍數(shù)在默認(rèn)情況下是2，而不是現(xiàn)在的1.25，從而導(dǎo)致了平均25%左右的內(nèi)存浪費(fèi)。而在今 后的各個版本中，該遞增倍數(shù)可能還會發(fā)生變化，以優(yōu)化Memcached的實(shí)際性能。

如果您一旦知道了您所需要緩存的數(shù)據(jù)的特征，如通常情況下數(shù)據(jù)的大小以及各個數(shù)據(jù)的差異幅度，那么您就可以根據(jù)這些數(shù)據(jù)的特征來設(shè)置上面所提到 的各個參數(shù)。如果數(shù)據(jù)在通常情況下都比較小，那么我們就需要將最小塊的大小調(diào)整得小一些。如果數(shù)據(jù)的大小變動不是很大，那么我們可以將塊大小的遞增倍數(shù)設(shè) 置得小一些，從而使得各個塊的大小盡量地貼近需要存儲的數(shù)據(jù)，以提高內(nèi)存的利用率。

還有一個值得注意的事情就是，由于Memcached在計算到底哪個服務(wù)實(shí)例記錄了具有特定鍵的數(shù)據(jù)時并不會考慮用來組成緩存系統(tǒng)中各個服務(wù)器 的差異性。如果每個服務(wù)器上只安裝了一個Memcached實(shí)例，那么各個Memcached實(shí)例所擁有的可用內(nèi)存將存在著數(shù)倍的差異。但是由于各個實(shí)例 被選中的概率基本相同，因此具有較大內(nèi)存的Memcached實(shí)例將無法被充分利用。我們可以通過在具有較大內(nèi)存的服務(wù)器上部署多個Memcached實(shí) 例來解決這個問題：

例如上圖所展示的緩存系統(tǒng)是由兩個服務(wù)器組成。這兩個服務(wù)器中的內(nèi)存大小并不相同。***個服務(wù)器的內(nèi)存大小為32G，而第二個服務(wù)器的內(nèi)存大小僅僅 有8G。為了能夠充分利用這兩個服務(wù)器的內(nèi)存，我們在具有32G內(nèi)存的服務(wù)器上部署了4個Memcached實(shí)例，而在只有8G內(nèi)存的服務(wù)器上部署了1個 Memcached實(shí)例。在這種情況下，32G內(nèi)存服務(wù)器上的4個Memcached實(shí)例將總共得到4倍于8G服務(wù)器所得到的負(fù)載，從而充分地利用了 32G內(nèi)存服務(wù)器上的內(nèi)存。

當(dāng)然，由于緩存系統(tǒng)擁有有限的資源，因此其會在某一時刻被服務(wù)所產(chǎn)生的數(shù)據(jù)填滿。如果此時緩存系統(tǒng)再次接收到一個緩存數(shù)據(jù)的請求，那么它就會根 據(jù)LRU（Least recently used）算法以及數(shù)據(jù)的過期時間來決定需要從緩存系統(tǒng)中移除的數(shù)據(jù)。而Memcached所使用的過期算法比較特殊，又被稱為延遲過期（Lazy expiration）：當(dāng)用戶從Memcached實(shí)例中讀取數(shù)據(jù)的時候，其將首先通過配置中所設(shè)置的過期時間來決定該數(shù)據(jù)是否過期。如果是，那么在下 一次寫入數(shù)據(jù)卻沒有足夠空間的時候，Memcached會選擇該過期數(shù)據(jù)所在的內(nèi)存塊作為新數(shù)據(jù)的目標(biāo)地址。如果在寫入時沒有相應(yīng)的記錄被標(biāo)記為過期，那 么LRU算法才被執(zhí)行，從而找到最久沒有被使用的需要被替換的數(shù)據(jù)。

這里的LRU是在Slab范圍內(nèi)的，而不是全局的。假設(shè)Memcached緩存系統(tǒng)中的最常用的數(shù)據(jù)都存儲在100K的塊中，而該系統(tǒng)中還存在 著另外一種類型的Slab，其塊大小是300K，但是存在于其中的數(shù)據(jù)并不常用。當(dāng)需要插入一條99K的數(shù)據(jù)而Memcached已經(jīng)沒有足夠的內(nèi)存再次 分配一個Slab實(shí)例的時候，其并不會釋放具有300K塊大小的Slab，而是在100K塊大小的各個Slab中找到需要釋放的塊，并將新數(shù)據(jù)添加到該塊 中。

高可用性

在企業(yè)級應(yīng)用中，我們常常強(qiáng)調(diào)一個系統(tǒng)需要擁有高可用性和高可靠性。而對于一個組成而言，其需要能夠穩(wěn)定地運(yùn)行，并在出現(xiàn)異常的時候盡量使得異 常的影響限制在某個特定的范圍內(nèi)，而不會導(dǎo)致整個系統(tǒng)不能正常工作。而且在出現(xiàn)異常之后，該組成需要能較為容易地恢復(fù)到正常的工作狀態(tài)。

那么Memcached需要什么樣的高可用性呢？在講解這個問題之前，我們先來看看在一個大型服務(wù)中Memcached所組成的服務(wù)端緩存是什么樣的：

從上圖中可以看到，在一個大型服務(wù)中，由Memcached所組成的服務(wù)端緩存實(shí)際上是由非常多的Memcached實(shí)例組成的。在前面我們已經(jīng) 介紹過，Memcached實(shí)例實(shí)際上是完全獨(dú)立的，不存在Memcached實(shí)例之間的相互交互。因此在其中一個發(fā)生了故障的時候，其它的各個 Memcached服務(wù)實(shí)例并不會受到影響。如果一個擁有了16個Memcached實(shí)例的服務(wù)端緩存系統(tǒng)中的一個Memcached實(shí)例發(fā)生了故障，那 么整個系統(tǒng)將還有93.75%的緩存容量可以繼續(xù)工作。雖然緩存容量的減少會略微增加其后的各個服務(wù)實(shí)例的壓力，但是一個應(yīng)用所經(jīng)歷的負(fù)載波動常常比這個 大得多，因此該服務(wù)應(yīng)該還是能夠正常工作的。

而這也恰恰表明了Memcached所具有的獨(dú)立性的正確性。由于Memcached本身致力于創(chuàng)建一個高效而且簡單，卻具有較強(qiáng)擴(kuò)展性的緩存 組件，因此其并沒有強(qiáng)調(diào)數(shù)據(jù)的安全性。一旦其中的一個Memcached實(shí)例發(fā)生了故障，那么我們還可以從數(shù)據(jù)庫及服務(wù)端再次計算得到該數(shù)據(jù)，并將其記錄 在其它可用的Memcached實(shí)例上。

我想您讀到這里一定會想：“不，還有一個問題，那就是由于Memcached實(shí)例的個數(shù)變化會導(dǎo)致哈希計算的結(jié)果發(fā)生變化，從而導(dǎo)致所有對數(shù)據(jù) 的請求會導(dǎo)向到不正確的Memcached實(shí)例，使得由Memcached實(shí)例集群所提供的緩存服務(wù)全部失效，從而導(dǎo)致數(shù)據(jù)庫的壓力驟增。”

是的，這也是我曾經(jīng)有所顧慮的地方。而且這不僅僅在服務(wù)端緩存失效的時候存在。只要服務(wù)端緩存中Memcached實(shí)例的數(shù)量發(fā)生了變化，那么該問題就會發(fā)生。

Memcached所使用的解決方法就是Consistent Hashing。在該算法的幫助下，Memcached實(shí)例數(shù)量的變化將只可能導(dǎo)致其中的一小部分鍵的哈希值發(fā)生改變。那該算法到底是怎么運(yùn)行的呢？

首先請考慮一個圓，在該圓上分布了多個點(diǎn)，以表示整數(shù)0到1023。這些整數(shù)平均分布在整個圓上：

而在上圖中，我們則突出地顯示了6個藍(lán)點(diǎn)。這六個藍(lán)點(diǎn)基本上將該圓進(jìn)行了六等分。而它們所對應(yīng)的就是在當(dāng)前Memcached緩存系統(tǒng)中所包含的三個 Memcached實(shí)例m1，m2以及m3。好，接下來我們則對當(dāng)前需要存儲的數(shù)據(jù)執(zhí)行哈希計算，并找到該哈希結(jié)果900在該圓上所對應(yīng)的點(diǎn)：

可以看到，該點(diǎn)在順時針距離上離表示0的那個藍(lán)點(diǎn)最近，因此這個具有哈希值900的數(shù)據(jù)將記錄在Memcached實(shí)例m1中。

如果其中的一個Memcached實(shí)例失效了，那么需要由該實(shí)例所記錄的數(shù)據(jù)將暫時失效，而其它實(shí)例所記錄的數(shù)據(jù)仍然還在：

從上圖中可以看到，在Memcached實(shí)例m1失效的情況下，值為900的數(shù)據(jù)將失效，而其它的值為112和750的數(shù)據(jù)將仍然記錄在 Memcached實(shí)例m2及m3上。也就是說，一個節(jié)點(diǎn)的失效現(xiàn)在將只會導(dǎo)致一部分?jǐn)?shù)據(jù)不再在緩存系統(tǒng)中存在，而并沒有導(dǎo)致其它實(shí)例上所記錄的數(shù)據(jù)的目 標(biāo)實(shí)例發(fā)生變化。

但是我們還不得不考慮另一個問題，那就是在一個服務(wù)的服務(wù)端緩存僅僅由一個或幾個Memcached實(shí)例組成的情況。在這種情況下，其中一個 Memcached實(shí)例失效是較為致命的，因為數(shù)據(jù)庫以及服務(wù)器實(shí)例將接收到大量的需要進(jìn)行復(fù)雜計算的請求，并將最終導(dǎo)致服務(wù)器實(shí)例和數(shù)據(jù)庫過載。因此在 設(shè)計服務(wù)端緩存時，我們常常采取超出需求容量的方法來定義這些緩存。例如在服務(wù)實(shí)際需要5個Memcached結(jié)點(diǎn)時我們設(shè)計一個包含6個節(jié)點(diǎn)的服務(wù)端緩 存系統(tǒng)，以增加整個系統(tǒng)的容錯能力。