【文章內(nèi)容簡(jiǎn)介】 ble做初始化，對(duì)應(yīng)的hash操作包括：assoc_find()、assoc_expand()、assoc_move_next_bucket()、assoc_insert()、assoc_delete()，對(duì)應(yīng)于item的讀寫操作。其中assoc_find()是根據(jù)key和key長(zhǎng)尋找對(duì)應(yīng)的item地址的函數(shù)（注意在C中，很多時(shí)候都是同時(shí)直接傳入字符串和字符串長(zhǎng)度，而不是在函數(shù)內(nèi)部做strlen），返回的是item結(jié)構(gòu)指針，它的數(shù)據(jù)地址在slab中的某個(gè)chunk上。，每一個(gè)完整的item包括幾個(gè)部分，在item_make_header()中定義為：key：鍵nkey：鍵長(zhǎng)flags：用戶定義的flag（其實(shí)這個(gè)flag在memcached中沒有啟用）nbytes：值長(zhǎng)（包括換行符號(hào)\r\n）suffix：后綴Buffernsuffix：后綴長(zhǎng)一個(gè)完整的item長(zhǎng)度是鍵長(zhǎng)＋值長(zhǎng)＋后綴長(zhǎng)＋item結(jié)構(gòu)大?。?2字節(jié)），item操作就是根據(jù)這個(gè)長(zhǎng)度來(lái)計(jì)算slab的classid的。hashtable中的每一個(gè)桶上掛著一個(gè)雙鏈表，item_init()的時(shí)候已經(jīng)初始化了heads、tails、sizes三個(gè)數(shù)組為0，這三個(gè)數(shù)組的大小都為常量LARGEST_ID（默認(rèn)為255，這個(gè)值需要配合factor來(lái)修改），在每次item_assoc()的時(shí)候，它會(huì)首先嘗試從slab中獲取一塊空閑的chunk，如果沒有可用的chunk，會(huì)在鏈表中掃描50次，以得到一個(gè)被LRU踢掉的item，將它unlink，然后將需要插入的item插入鏈表中。注意item的refcount成員。item被unlink之后只是從鏈表上摘掉，不是立刻就被free的，只是將它放到刪除隊(duì)列中（item_unlink_q()函數(shù)）。item對(duì)應(yīng)一些讀寫操作，包括remove、update、replace，當(dāng)然最重要的就是alloc操作。item還有一個(gè)特性就是它有過期時(shí)間，這是memcached的一個(gè)很有用的特性，很多應(yīng)用都是依賴于memcached的item過期，比如session存儲(chǔ)、操作鎖等。item_flush_expired()函數(shù)就是掃描表中的item，對(duì)過期的item執(zhí)行unlink操作，當(dāng)然這只是一個(gè)回收動(dòng)作，實(shí)際上在get的時(shí)候還要進(jìn)行時(shí)間判斷：CODE:/* expires items that are more recent than the oldest_live setting. */void item_flush_expired() { int i。 item *iter, *next。 if (! ) return。 for (i = 0。 i LARGEST_ID。 i++) { /* The LRU is sorted in decreasing time order, and an item’s timestamp * is never newer than its last access time, so we only need to walk * back until we hit an item older than the oldest_live time. * The oldest_live checking will autoexpire the remaining items. */ for (iter = heads[i]。 iter != NULL。 iter = next) { if (itertime = ) { next = iternext。 if ((iterit_flags amp。 ITEM_SLABBED) == 0) { item_unlink(iter)。 } } else { /* We’ve hit the first old item. Continue to the next queue. */ break。 } } }} CODE:/* wrapper around assoc_find which does the lazy expiration/deletion logic */item *get_item_notedeleted(char *key, size_t nkey, int *delete_locked) { item *it = assoc_find(key, nkey)。 if (delete_locked) *delete_locked = 0。 if (it amp。amp。 (itit_flags amp。 ITEM_DELETED)) { /* it’s flagged as deletelocked. let’s see if that condition is past due, and the 5second delete_timer just hasn’t gotten to it yet… */ if (! item_delete_lock_over(it)) { if (delete_locked) *delete_locked = 1。 it = 0。 } } if (it amp。amp。 amp。amp。 = current_time amp。amp。 ittime = ) { item_unlink(it)。 it = 0。 } if (it amp。amp。 itexptime amp。amp。 itexptime = current_time) { item_unlink(it)。 it = 0。 } return it。}Memcached的內(nèi)存管理方式是非常精巧和高效的，它很大程度上減少了直接alloc系統(tǒng)內(nèi)存的次數(shù)，降低函數(shù)開銷和內(nèi)存碎片產(chǎn)生幾率，雖然這種方式會(huì)造成一些冗余浪費(fèi)，但是這種浪費(fèi)在大型系統(tǒng)應(yīng)用中是微不足道的?！騇emcached的理論參數(shù)計(jì)算方式影響 memcached 工作的幾個(gè)參數(shù)有： 常量REALTIME_MAXDELTA 60*60*24*30最大30天的過期時(shí)間conn_init()中的freetotal（=200）最大同時(shí)連接數(shù)常量KEY_MAX_LENGTH 250最大鍵長(zhǎng)（=）factor將影響chunk的步進(jìn)大?。?1024）最大軟連接（=48）一個(gè)保守估計(jì)的key+value長(zhǎng)度，用來(lái)生成id1中的chunk長(zhǎng)度（）。id1的chunk長(zhǎng)度等于這個(gè)數(shù)值加上item結(jié)構(gòu)體的長(zhǎng)度（32），即默認(rèn)的80字節(jié)。常量POWER_SMALLEST 1最小classid（）常量POWER_LARGEST 200最大classid（）常量POWER_BLOCK 1048576默認(rèn)slab大小常量CHUNK_ALIGN_BYTES (sizeof(void *))保證chunk大小是這個(gè)數(shù)值的整數(shù)倍，防止越界（void *的長(zhǎng)度在不同系統(tǒng)上不一樣，在標(biāo)準(zhǔn)32位系統(tǒng)上是4）常量ITEM_UPDATE_INTERVAL 60隊(duì)列刷新間隔常量LARGEST_ID 255最大item鏈表數(shù)（這個(gè)值不能比最大的classid?。┳兞縣ashpower（）決定hashtable的大小根據(jù)上面介紹的內(nèi)容及參數(shù)設(shè)定，可以計(jì)算出的一些結(jié)果：在memcached中可以保存的item個(gè)數(shù)是沒有軟件上限的，之前我的100萬(wàn)的說法是錯(cuò)誤的。假設(shè)NewHash算法碰撞均勻，查找item的循環(huán)次數(shù)是item總數(shù)除以hashtable大?。ㄓ蒱ashpower決定），是線性的。Memcached限制了可以接受的最大item是1MB，大于1MB的數(shù)據(jù)不予理會(huì)。Memcached的空間利用率和數(shù)據(jù)特性有很大的關(guān)系，又與DONT_PREALLOC_SLABS常量有關(guān)。 在最差情況下，有198個(gè)slab會(huì)被浪費(fèi)（所有item都集中在一個(gè)slab中，199個(gè)id全部分配滿）。 ◎Memcached的定長(zhǎng)優(yōu)化根據(jù)上面幾節(jié)的描述，多少對(duì)memcached有了一個(gè)比較深入的認(rèn)識(shí)。在深入認(rèn)識(shí)的基礎(chǔ)上才好對(duì)它進(jìn)行優(yōu)化。Memcached本身是為變長(zhǎng)數(shù)據(jù)設(shè)計(jì)的，根據(jù)數(shù)據(jù)特性，可以說它是“面向大眾”的設(shè)計(jì)，但是很多時(shí)候，我們的數(shù)據(jù)并不是這樣的“普遍”，典型的情況中，一種是非均勻分布，即數(shù)據(jù)長(zhǎng)度集中在幾個(gè)區(qū)域內(nèi)（如保存用戶 Session）；另一種更極端的狀態(tài)是等長(zhǎng)數(shù)據(jù)（如定長(zhǎng)鍵值，定長(zhǎng)數(shù)據(jù)，多見于訪問、在線統(tǒng)計(jì)或執(zhí)行鎖）。這里主要研究一下定長(zhǎng)數(shù)據(jù)的優(yōu)化方案（），集中分布的變長(zhǎng)數(shù)據(jù)僅供參考，實(shí)現(xiàn)起來(lái)也很容易。解決定長(zhǎng)數(shù)據(jù)，首先需要解決的是slab的分配問題，第一個(gè)需要確認(rèn)的是我們不需要那么多不同chunk長(zhǎng)度的slab，為了最大限度地利用資源，最好chunk和item等長(zhǎng)，所以首先要計(jì)算item長(zhǎng)度。在之前已經(jīng)有了計(jì)算item長(zhǎng)度的算法，需要注意的是，除了字符串長(zhǎng)度外，還要加上item結(jié)構(gòu)的長(zhǎng)度32字節(jié)。假設(shè)我們已經(jīng)計(jì)算出需要保存200字節(jié)的等長(zhǎng)數(shù)據(jù)。接下來(lái)是要修改slab的classid和chunk長(zhǎng)度的關(guān)系。在原始版本中，chunk長(zhǎng)度和classid是有對(duì)應(yīng)關(guān)系的，現(xiàn)在如果把所有的chunk都定為200個(gè)字節(jié)，那么這個(gè)關(guān)系就不存在了，我們需要重新確定這二者的關(guān)系。一種方法是，整個(gè)存儲(chǔ)結(jié)構(gòu)只使用一個(gè)固定的id，即只使用199個(gè)槽中的1個(gè)，在這種條件下，就一定要定義DONT_PREALLOC_SLABS來(lái)避免另外的預(yù)分配浪費(fèi)。另一種方法是建立一個(gè)hash關(guān)系，來(lái)從item確定classid，不能使用長(zhǎng)度來(lái)做鍵，可以使用key的NewHash結(jié)果等不定數(shù)據(jù)，或者直接根據(jù)key來(lái)做hash（定長(zhǎng)數(shù)據(jù)的key也一定等長(zhǎng)）。這里簡(jiǎn)單起見，選擇第一種方法，這種方法的不足之處在于只使用一個(gè)id，在數(shù)據(jù)量非常大的情況下，slab鏈會(huì)很長(zhǎng)（因?yàn)樗袛?shù)據(jù)都擠在一條鏈上了），遍歷起來(lái)的代價(jià)比較高。前面介紹了三種空間冗余，設(shè)置chunk長(zhǎng)度等于item長(zhǎng)度，解決了第一種空間浪費(fèi)問題，不預(yù)申請(qǐng)空間解決了第二種空間浪費(fèi)問題，那么對(duì)于第一種問題（slab內(nèi)剩余）如何解決呢，這就需要修改POWER_BLOCK常量，使得每一個(gè)slab大小正好等于chunk長(zhǎng)度的整數(shù)倍，這樣一個(gè)slab就可以正好劃分成n個(gè)chunk。這個(gè)數(shù)值應(yīng)該比較接近1MB，過大的話同樣會(huì)造成冗余，過小的話會(huì)造成次數(shù)過多的alloc，根據(jù)chunk長(zhǎng)度為200，選擇1000000作為POWER_BLOCK的值，這樣一個(gè)slab就是100萬(wàn)字節(jié)，不是1048576。三個(gè)冗余問題都解決了，空間利用率會(huì)大大提升。修改 slabs_clsid 函數(shù)，讓它直接返回一個(gè)定值（比如 1 ）：CODE:unsigned int slabs_clsid(size_t size) { return 1。}修改slabs_init函數(shù)，去掉循環(huán)創(chuàng)建所有classid屬性的部分，直接添加slabclass[1]：CODE:slabclass[1].size = 200。 //每chunk200字節(jié)slabclass[1].perslab = 5000。 //1000000/200◎Memcached客戶端Memcached是一個(gè)服務(wù)程序，使用的時(shí)候可以根據(jù)它的協(xié)議，連接到memcached服務(wù)器上，發(fā)送命令給服務(wù)進(jìn)程，就可以操作上面的數(shù)據(jù)。為了方便使用，memcached有很多個(gè)客戶端程序可以使用，對(duì)應(yīng)于各種語(yǔ)言，有各種語(yǔ)言的客戶端?；贑語(yǔ)言的有l(wèi)ibmemcache、APR_Memcache；基于Perl的有Cache::Memcached；另外還有Python、Ruby、Java、C等語(yǔ)言的支持。PHP的客戶端是最多的，不光有mcache和PECL memcache兩個(gè)擴(kuò)展，還有大把的由PHP編寫的封裝類，下面介紹一下在PHP中使用memcached的方法：mcache擴(kuò)展是基于libmemcache再封裝的。libmemcache一直沒有發(fā)布stable版本，可以在這里找到。libmemcache有一個(gè)很不好的特性，就是會(huì)向stderr寫很多錯(cuò)誤信息，一般的，作為lib使用的時(shí)候，stderr一般都會(huì)被定向到其它地方，比如Apache的錯(cuò)誤日志，而且libmemcache會(huì)自殺，可能會(huì)導(dǎo)致異常，不過它的性能還是很好的。，作者大概是離職了，不光停止更新，連網(wǎng)站也打不開了（~_~），只能到其它地方去獲取這個(gè)不負(fù)責(zé)的擴(kuò)展了。解壓后安裝方法如常：phpize amp。 configure amp。 make amp。 make install，一定要先安裝libmemcache。使用這個(gè)擴(kuò)展很簡(jiǎn)單：CODE:?php$mc = memcache()。