如何進(jìn)行memcached的應(yīng)用和兼容程序的分析

如何進(jìn)行memcached的應(yīng)用和兼容程序的分析，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

下面介紹一些mixi的案例和 實(shí)際應(yīng)用上的話題，并介紹一些與memcached兼容的程序。

mixi案例研究

mixi在提供服務(wù)的初期階段就使用了memcached。 隨著網(wǎng)站訪問(wèn)量的急劇增加，單純?yōu)閿?shù)據(jù)庫(kù)添加slave已無(wú)法滿足需要，因此引入了memcached。 此外，我們也從增加可擴(kuò)展性的方面進(jìn)行了驗(yàn)證，證明了memcached的速度和穩(wěn)定性都能滿足需要。 現(xiàn)在，memcached已成為mixi服務(wù)中非常重要的組成部分。

圖1 現(xiàn)在的系統(tǒng)組件

服務(wù)器配置和數(shù)量

mixi使用了許許多多服務(wù)器，如數(shù)據(jù)庫(kù)服務(wù)器、應(yīng)用服務(wù)器、圖片服務(wù)器、 反向代理服務(wù)器等。單單memcached就有將近200臺(tái)服務(wù)器在運(yùn)行。 memcached服務(wù)器的典型配置如下：

• CPU：Intel Pentium 4 2.8GHz

• 內(nèi)存：4GB

• 硬盤：146GB SCSI

• 操作系統(tǒng)：Linux（x86_64）

這些服務(wù)器以前曾用于數(shù)據(jù)庫(kù)服務(wù)器等。隨著CPU性能提升、內(nèi)存價(jià)格下降， 我們積極地將數(shù)據(jù)庫(kù)服務(wù)器、應(yīng)用服務(wù)器等換成了性能更強(qiáng)大、內(nèi)存更多的服務(wù)器。 這樣，可以抑制mixi整體使用的服務(wù)器數(shù)量的急劇增加，降低管理成本。 由于memcached服務(wù)器幾乎不占用CPU，就將換下來(lái)的服務(wù)器用作memcached服務(wù)器了。

memcached進(jìn)程

每臺(tái)memcached服務(wù)器僅啟動(dòng)一個(gè)memcached進(jìn)程。分配給memcached的內(nèi)存為3GB， 啟動(dòng)參數(shù)如下：

/usr/bin/memcached -p 11211 -u nobody -m 3000 -c 30720

由于使用了x86_64的操作系統(tǒng)，因此能分配2GB以上的內(nèi)存。32位操作系統(tǒng)中， 每個(gè)進(jìn)程最多只能使用2GB內(nèi)存。也曾經(jīng)考慮過(guò)啟動(dòng)多個(gè)分配2GB以下內(nèi)存的進(jìn)程， 但這樣一臺(tái)服務(wù)器上的TCP連接數(shù)就會(huì)成倍增加，管理上也變得復(fù)雜， 所以mixi就統(tǒng)一使用了64位操作系統(tǒng)。

另外，雖然服務(wù)器的內(nèi)存為4GB，卻僅分配了3GB，是因?yàn)閮?nèi)存分配量超過(guò)這個(gè)值， 就有可能導(dǎo)致內(nèi)存交換(swap)。連載的第2次中 前坂講解過(guò)了memcached的內(nèi)存存儲(chǔ)“slab allocator”，當(dāng)時(shí)說(shuō)過(guò)，memcached啟動(dòng)時(shí) 指定的內(nèi)存分配量是memcached用于保存數(shù)據(jù)的量，沒(méi)有包括“slab allocator”本身占用的內(nèi)存、 以及為了保存數(shù)據(jù)而設(shè)置的管理空間。因此，memcached進(jìn)程的實(shí)際內(nèi)存分配量要比 指定的容量要大，這一點(diǎn)應(yīng)當(dāng)注意。

mixi保存在memcached中的數(shù)據(jù)大部分都比較小。這樣，進(jìn)程的大小要比 指定的容量大很多。因此，我們反復(fù)改變內(nèi)存分配量進(jìn)行驗(yàn)證， 確認(rèn)了3GB的大小不會(huì)引發(fā)swap，這就是現(xiàn)在應(yīng)用的數(shù)值。

memcached使用方法和客戶端

現(xiàn)在，mixi的服務(wù)將200臺(tái)左右的memcached服務(wù)器作為一個(gè)pool使用。 每臺(tái)服務(wù)器的容量為3GB，那么全體就有了將近600GB的巨大的內(nèi)存數(shù)據(jù)庫(kù)。 客戶端程序庫(kù)使用了本連載中多次提到車的Cache::Memcached::Fast， 與服務(wù)器進(jìn)行交互。當(dāng)然，緩存的分布式算法使用的是 第4次介紹過(guò)的 Consistent Hashing算法。

• Cache::Memcached::Fast - search.cpan.org

應(yīng)用層上memcached的使用方法由開發(fā)應(yīng)用程序的工程師自行決定并實(shí)現(xiàn)。 但是，為了防止車輪再造、防止Cache::Memcached::Fast上的教訓(xùn)再次發(fā)生， 我們提供了Cache::Memcached::Fast的wrap模塊并使用。

通過(guò)Cache::Memcached::Fast維持連接

Cache::Memcached的情況下，與memcached的連接（文件句柄）保存在Cache::Memcached包內(nèi)的類變量中。 在mod_perl和FastCGI等環(huán)境下，包內(nèi)的變量不會(huì)像CGI那樣隨時(shí)重新啟動(dòng)， 而是在進(jìn)程中一直保持。其結(jié)果就是不會(huì)斷開與memcached的連接， 減少了TCP連接建立時(shí)的開銷，同時(shí)也能防止短時(shí)間內(nèi)反復(fù)進(jìn)行TCP連接、斷開 而導(dǎo)致的TCP端口資源枯竭。

但是，Cache::Memcached::Fast沒(méi)有這個(gè)功能，所以需要在模塊之外 將Cache::Memcached::Fast對(duì)象保持在類變量中，以保證持久連接。

package Gihyo::Memcached;

use strict;
use warnings;
use Cache::Memcached::Fast;

my @server_list = qw/192.168.1.1:11211 192.168.1.1:11211/;
my $fast;  ## 用于保持對(duì)象

sub new {
    my $self  = bless {}, shift;
    if ( !$fast ) {
        $fast = Cache::Memcached::Fast->new({ servers => \@server_list });
    }
    $self->{_fast} = $fast;
    return $self;
}

sub get {
   my $self = shift;
   $self->{_fast}->get(@_);
}

上面的例子中，Cache::Memcached::Fast對(duì)象保存到類變量$fast中。

公共數(shù)據(jù)的處理和rehash

諸如mixi的主頁(yè)上的新聞這樣的所有用戶共享的緩存數(shù)據(jù)、設(shè)置信息等數(shù)據(jù)， 會(huì)占用許多頁(yè)，訪問(wèn)次數(shù)也非常多。在這種條件下，訪問(wèn)很容易集中到某臺(tái)memcached服務(wù)器上。 訪問(wèn)集中本身并不是問(wèn)題，但是一旦訪問(wèn)集中的那臺(tái)服務(wù)器發(fā)生故障導(dǎo)致memcached無(wú)法連接， 就會(huì)產(chǎn)生巨大的問(wèn)題。

連載的第4次 中提到，Cache::Memcached擁有rehash功能，即在無(wú)法連接保存數(shù)據(jù)的服務(wù)器的情況下， 會(huì)再次計(jì)算hash值，連接其他的服務(wù)器。

但是，Cache::Memcached::Fast沒(méi)有這個(gè)功能。不過(guò)，它能夠在連接服務(wù)器失敗時(shí)， 短時(shí)間內(nèi)不再連接該服務(wù)器的功能。

my $fast = Cache::Memcached::Fast->new({
    max_failures     => 3,
    failure_timeout  => 1
});

在failure_timeout秒內(nèi)發(fā)生max_failures以上次連接失敗，就不再連接該memcached服務(wù)器。 我們的設(shè)置是1秒鐘3次以上。

此外，mixi還為所有用戶共享的緩存數(shù)據(jù)的鍵名設(shè)置命名規(guī)則， 符合命名規(guī)則的數(shù)據(jù)會(huì)自動(dòng)保存到多臺(tái)memcached服務(wù)器中， 取得時(shí)從中僅選取一臺(tái)服務(wù)器。創(chuàng)建該函數(shù)庫(kù)后，就可以使memcached服務(wù)器故障 不再產(chǎn)生其他影響。

memcached應(yīng)用經(jīng)驗(yàn)

到此為止介紹了memcached內(nèi)部構(gòu)造和函數(shù)庫(kù)，接下來(lái)介紹一些其他的應(yīng)用經(jīng)驗(yàn)。

通過(guò)daemontools啟動(dòng)

通常情況下memcached運(yùn)行得相當(dāng)穩(wěn)定，但mixi現(xiàn)在使用的最新版1.2.5 曾經(jīng)發(fā)生過(guò)幾次memcached進(jìn)程死掉的情況。架構(gòu)上保證了即使有幾臺(tái)memcached故障 也不會(huì)影響服務(wù)，不過(guò)對(duì)于memcached進(jìn)程死掉的服務(wù)器，只要重新啟動(dòng)memcached， 就可以正常運(yùn)行，所以采用了監(jiān)視memcached進(jìn)程并自動(dòng)啟動(dòng)的方法。 于是使用了daemontools。

daemontools是qmail的作者DJB開發(fā)的UNIX服務(wù)管理工具集， 其中名為supervise的程序可用于服務(wù)啟動(dòng)、停止的服務(wù)重啟等。

• daemontools

這里不介紹daemontools的安裝了。mixi使用了以下的run腳本來(lái)啟動(dòng)memcached。

#!/bin/sh

if [ -f /etc/sysconfig/memcached ];then
        . /etc/sysconfig/memcached
fi

exec 2>&1
exec /usr/bin/memcached -p $PORT -u $USER  -m $CACHESIZE -c $MAXCONN $OPTIONS

監(jiān)視

mixi使用了名為“nagios”的開源監(jiān)視軟件來(lái)監(jiān)視memcached。

• Nagios: Home

在nagios中可以簡(jiǎn)單地開發(fā)插件，可以詳細(xì)地監(jiān)視memcached的get、add等動(dòng)作。 不過(guò)mixi僅通過(guò)stats命令來(lái)確認(rèn)memcached的運(yùn)行狀態(tài)。

define command {
command_name                   check_memcached
command_line                   $USER1$/check_tcp -H $HOSTADDRESS$ -p 11211 -t 5 -E -s 'stats\r\nquit\r\n' -e 'uptime' -M crit
}

此外，mixi將stats目錄的結(jié)果通過(guò)rrdtool轉(zhuǎn)化成圖形，進(jìn)行性能監(jiān)視， 并將每天的內(nèi)存使用量做成報(bào)表，通過(guò)郵件與開發(fā)者共享。

memcached的性能

連載中已介紹過(guò)，memcached的性能十分優(yōu)秀。我們來(lái)看看mixi的實(shí)際案例。 這里介紹的圖表是服務(wù)所使用的訪問(wèn)最為集中的memcached服務(wù)器。

圖2 請(qǐng)求數(shù)

圖3 流量

圖4 TCP連接數(shù)

從上至下依次為請(qǐng)求數(shù)、流量和TCP連接數(shù)。請(qǐng)求數(shù)最大為15000qps， 流量達(dá)到400Mbps，這時(shí)的連接數(shù)已超過(guò)了10000個(gè)。 該服務(wù)器沒(méi)有特別的硬件，就是開頭介紹的普通的memcached服務(wù)器。 此時(shí)的CPU利用率為：

圖5 CPU利用率

可見(jiàn)，仍然有idle的部分。因此，memcached的性能非常高， 可以作為Web應(yīng)用程序開發(fā)者放心地保存臨時(shí)數(shù)據(jù)或緩存數(shù)據(jù)的地方。

兼容應(yīng)用程序

memcached的實(shí)現(xiàn)和協(xié)議都十分簡(jiǎn)單，因此有很多與memcached兼容的實(shí)現(xiàn)。 一些功能強(qiáng)大的擴(kuò)展可以將memcached的內(nèi)存數(shù)據(jù)寫到磁盤上，實(shí)現(xiàn)數(shù)據(jù)的持久性和冗余。 連載第3次 介紹過(guò)，以后的memcached的存儲(chǔ)層將變成可擴(kuò)展的（pluggable），逐漸支持這些功能。

這里介紹幾個(gè)與memcached兼容的應(yīng)用程序。

• repcached

• 為memcached提供復(fù)制(replication)功能的patch。

• Flared

• 存儲(chǔ)到QDBM。同時(shí)實(shí)現(xiàn)了異步復(fù)制和fail over等功能。

• memcachedb

• 存儲(chǔ)到BerkleyDB。還實(shí)現(xiàn)了message queue。

• Tokyo Tyrant

• 將數(shù)據(jù)存儲(chǔ)到Tokyo Cabinet。不僅與memcached協(xié)議兼容，還能通過(guò)HTTP進(jìn)行訪問(wèn)。

Tokyo Tyrant案例

mixi使用了上述兼容應(yīng)用程序中的Tokyo Tyrant。Tokyo Tyrant是平林開發(fā)的 Tokyo Cabinet DBM的網(wǎng)絡(luò)接口。它有自己的協(xié)議，但也擁有memcached兼容協(xié)議， 也可以通過(guò)HTTP進(jìn)行數(shù)據(jù)交換。Tokyo Cabinet雖然是一種將數(shù)據(jù)寫到磁盤的實(shí)現(xiàn)，但速度相當(dāng)快。

mixi并沒(méi)有將Tokyo Tyrant作為緩存服務(wù)器，而是將它作為保存鍵值對(duì)組合的DBMS來(lái)使用。 主要作為存儲(chǔ)用戶上次訪問(wèn)時(shí)間的數(shù)據(jù)庫(kù)來(lái)使用。它與幾乎所有的mixi服務(wù)都有關(guān)， 每次用戶訪問(wèn)頁(yè)面時(shí)都要更新數(shù)據(jù)，因此負(fù)荷相當(dāng)高。MySQL的處理十分笨重， 單獨(dú)使用memcached保存數(shù)據(jù)又有可能會(huì)丟失數(shù)據(jù)，所以引入了Tokyo Tyrant。 但無(wú)需重新開發(fā)客戶端，只需原封不動(dòng)地使用Cache::Memcached::Fast即可， 這也是優(yōu)點(diǎn)之一。

• mixi Engineers' Blog - Tokyo Tyrantによる耐高負(fù)荷DBの構(gòu)築

• mixi Engineers' Blog - Tokyo (Cabinet|Tyrant)の新機(jī)能

關(guān)于如何進(jìn)行memcached的應(yīng)用和兼容程序的分析問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。