如何進(jìn)行memcached的應(yīng)用和兼容程序的分析，針對這個(gè)問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。
創(chuàng)新互聯(lián)堅(jiān)信：善待客戶，將會成為終身客戶。我們能堅(jiān)持多年，是因?yàn)槲覀円恢笨芍档眯刨?。我們從不忽悠初訪客戶，我們用心做好本職工作，不忘初心，方得始終。10多年網(wǎng)站建設(shè)經(jīng)驗(yàn)創(chuàng)新互聯(lián)是成都老牌網(wǎng)站營銷服務(wù)商,為您提供網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、H5開發(fā)、網(wǎng)站制作、品牌網(wǎng)站制作、微信小程序定制開發(fā)服務(wù),給眾多知名企業(yè)提供過好品質(zhì)的建站服務(wù)。
下面介紹一些mixi的案例和 實(shí)際應(yīng)用上的話題，并介紹一些與memcached兼容的程序。
mixi在提供服務(wù)的初期階段就使用了memcached。 隨著網(wǎng)站訪問量的急劇增加，單純?yōu)閿?shù)據(jù)庫添加slave已無法滿足需要，因此引入了memcached。 此外，我們也從增加可擴(kuò)展性的方面進(jìn)行了驗(yàn)證，證明了memcached的速度和穩(wěn)定性都能滿足需要。 現(xiàn)在，memcached已成為mixi服務(wù)中非常重要的組成部分。
圖1 現(xiàn)在的系統(tǒng)組件
mixi使用了許許多多服務(wù)器，如數(shù)據(jù)庫服務(wù)器、應(yīng)用服務(wù)器、圖片服務(wù)器、 反向代理服務(wù)器等。單單memcached就有將近200臺服務(wù)器在運(yùn)行。 memcached服務(wù)器的典型配置如下：
CPU：Intel Pentium 4 2.8GHz
內(nèi)存：4GB
硬盤：146GB SCSI
操作系統(tǒng)：Linux（x86_64）
這些服務(wù)器以前曾用于數(shù)據(jù)庫服務(wù)器等。隨著CPU性能提升、內(nèi)存價(jià)格下降， 我們積極地將數(shù)據(jù)庫服務(wù)器、應(yīng)用服務(wù)器等換成了性能更強(qiáng)大、內(nèi)存更多的服務(wù)器。 這樣，可以抑制mixi整體使用的服務(wù)器數(shù)量的急劇增加，降低管理成本。 由于memcached服務(wù)器幾乎不占用CPU，就將換下來的服務(wù)器用作memcached服務(wù)器了。
每臺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)考慮過啟動(dòng)多個(gè)分配2GB以下內(nèi)存的進(jìn)程， 但這樣一臺服務(wù)器上的TCP連接數(shù)就會成倍增加，管理上也變得復(fù)雜， 所以mixi就統(tǒng)一使用了64位操作系統(tǒng)。
另外，雖然服務(wù)器的內(nèi)存為4GB，卻僅分配了3GB，是因?yàn)閮?nèi)存分配量超過這個(gè)值， 就有可能導(dǎo)致內(nèi)存交換(swap)。連載的第2次中 前坂講解過了memcached的內(nèi)存存儲“slab allocator”，當(dāng)時(shí)說過，memcached啟動(dòng)時(shí) 指定的內(nèi)存分配量是memcached用于保存數(shù)據(jù)的量，沒有包括“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的大小不會引發(fā)swap，這就是現(xiàn)在應(yīng)用的數(shù)值。
現(xiàn)在，mixi的服務(wù)將200臺左右的memcached服務(wù)器作為一個(gè)pool使用。 每臺服務(wù)器的容量為3GB，那么全體就有了將近600GB的巨大的內(nèi)存數(shù)據(jù)庫。 客戶端程序庫使用了本連載中多次提到車的Cache::Memcached::Fast， 與服務(wù)器進(jìn)行交互。當(dāng)然，緩存的分布式算法使用的是 第4次介紹過的 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模塊并使用。
Cache::Memcached的情況下，與memcached的連接（文件句柄）保存在Cache::Memcached包內(nèi)的類變量中。 在mod_perl和FastCGI等環(huán)境下，包內(nèi)的變量不會像CGI那樣隨時(shí)重新啟動(dòng)， 而是在進(jìn)程中一直保持。其結(jié)果就是不會斷開與memcached的連接， 減少了TCP連接建立時(shí)的開銷，同時(shí)也能防止短時(shí)間內(nèi)反復(fù)進(jìn)行TCP連接、斷開 而導(dǎo)致的TCP端口資源枯竭。
但是，Cache::Memcached::Fast沒有這個(gè)功能，所以需要在模塊之外 將Cache::Memcached::Fast對象保持在類變量中，以保證持久連接。
重慶分公司
重慶分公司
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; ## 用于保持對象
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對象保存到類變量$fast中。
諸如mixi的主頁上的新聞這樣的所有用戶共享的緩存數(shù)據(jù)、設(shè)置信息等數(shù)據(jù)， 會占用許多頁，訪問次數(shù)也非常多。在這種條件下，訪問很容易集中到某臺memcached服務(wù)器上。 訪問集中本身并不是問題，但是一旦訪問集中的那臺服務(wù)器發(fā)生故障導(dǎo)致memcached無法連接， 就會產(chǎn)生巨大的問題。
連載的第4次 中提到，Cache::Memcached擁有rehash功能，即在無法連接保存數(shù)據(jù)的服務(wù)器的情況下， 會再次計(jì)算hash值，連接其他的服務(wù)器。
但是，Cache::Memcached::Fast沒有這個(gè)功能。不過，它能夠在連接服務(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ù)會自動(dòng)保存到多臺memcached服務(wù)器中， 取得時(shí)從中僅選取一臺服務(wù)器。創(chuàng)建該函數(shù)庫后，就可以使memcached服務(wù)器故障 不再產(chǎn)生其他影響。
到此為止介紹了memcached內(nèi)部構(gòu)造和函數(shù)庫，接下來介紹一些其他的應(yīng)用經(jīng)驗(yàn)。
通常情況下memcached運(yùn)行得相當(dāng)穩(wěn)定，但mixi現(xiàn)在使用的最新版1.2.5 曾經(jīng)發(fā)生過幾次memcached進(jìn)程死掉的情況。架構(gòu)上保證了即使有幾臺memcached故障 也不會影響服務(wù)，不過對于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腳本來啟動(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
mixi使用了名為“nagios”的開源監(jiān)視軟件來監(jiān)視memcached。
Nagios: Home
在nagios中可以簡單地開發(fā)插件，可以詳細(xì)地監(jiān)視memcached的get、add等動(dòng)作。 不過mixi僅通過stats命令來確認(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é)果通過rrdtool轉(zhuǎn)化成圖形，進(jìn)行性能監(jiān)視， 并將每天的內(nèi)存使用量做成報(bào)表，通過郵件與開發(fā)者共享。
連載中已介紹過，memcached的性能十分優(yōu)秀。我們來看看mixi的實(shí)際案例。 這里介紹的圖表是服務(wù)所使用的訪問最為集中的memcached服務(wù)器。
圖2 請求數(shù)
圖3 流量
圖4 TCP連接數(shù)
從上至下依次為請求數(shù)、流量和TCP連接數(shù)。請求數(shù)最大為15000qps， 流量達(dá)到400Mbps，這時(shí)的連接數(shù)已超過了10000個(gè)。 該服務(wù)器沒有特別的硬件，就是開頭介紹的普通的memcached服務(wù)器。 此時(shí)的CPU利用率為：
圖5 CPU利用率
可見，仍然有idle的部分。因此，memcached的性能非常高， 可以作為Web應(yīng)用程序開發(fā)者放心地保存臨時(shí)數(shù)據(jù)或緩存數(shù)據(jù)的地方。
memcached的實(shí)現(xiàn)和協(xié)議都十分簡單，因此有很多與memcached兼容的實(shí)現(xiàn)。 一些功能強(qiáng)大的擴(kuò)展可以將memcached的內(nèi)存數(shù)據(jù)寫到磁盤上，實(shí)現(xiàn)數(shù)據(jù)的持久性和冗余。 連載第3次 介紹過，以后的memcached的存儲層將變成可擴(kuò)展的（pluggable），逐漸支持這些功能。
這里介紹幾個(gè)與memcached兼容的應(yīng)用程序。
repcached
為memcached提供復(fù)制(replication)功能的patch。
Flared
存儲到QDBM。同時(shí)實(shí)現(xiàn)了異步復(fù)制和fail over等功能。
memcachedb
存儲到BerkleyDB。還實(shí)現(xiàn)了message queue。
Tokyo Tyrant
將數(shù)據(jù)存儲到Tokyo Cabinet。不僅與memcached協(xié)議兼容，還能通過HTTP進(jìn)行訪問。
mixi使用了上述兼容應(yīng)用程序中的Tokyo Tyrant。Tokyo Tyrant是平林開發(fā)的 Tokyo Cabinet DBM的網(wǎng)絡(luò)接口。它有自己的協(xié)議，但也擁有memcached兼容協(xié)議， 也可以通過HTTP進(jìn)行數(shù)據(jù)交換。Tokyo Cabinet雖然是一種將數(shù)據(jù)寫到磁盤的實(shí)現(xiàn)，但速度相當(dāng)快。
mixi并沒有將Tokyo Tyrant作為緩存服務(wù)器，而是將它作為保存鍵值對組合的DBMS來使用。 主要作為存儲用戶上次訪問時(shí)間的數(shù)據(jù)庫來使用。它與幾乎所有的mixi服務(wù)都有關(guān)， 每次用戶訪問頁面時(shí)都要更新數(shù)據(jù)，因此負(fù)荷相當(dāng)高。MySQL的處理十分笨重， 單獨(dú)使用memcached保存數(shù)據(jù)又有可能會丟失數(shù)據(jù)，所以引入了Tokyo Tyrant。 但無需重新開發(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)用和兼容程序的分析問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。
