【正文】 try]。 rv = apr_memcache_getp(mc_groups[try], p, (const char *) key, amp。value, amp。value_l, 0)。 if (APR_SUCCESS == rv) { RETURN_STRING(value, 1)。 } } } RETURN_FALSE。} CODE:/*** Random group id* For mc_get()*/apr_int32_t random_group(){ struct timeval tv。 struct timezone tz。 int usec。 gettimeofday(amp。tv, amp。tz)。 usec = 。 int curr = usec % count_group()。 return (apr_int32_t) curr。}BSM_Memcache的使用方式和其它的client類似：CODE:?php$g1 = mc_add_group()。 // 添加第一個組$g2 = mc_add_group()。 // 添加第二個組mc_add_server($g1, ‘localhost:11211′)。 // 在第一個組中添加第一臺服務器mc_add_server($g1, ‘localhost:11212′)。 // 在第一個組中添加第二臺服務器mc_add_server($g2, ‘:11211′)。 // 在第二個組中添加第一臺服務器mc_add_server($g2, ‘:11211′)。 // 在第二個組中添加第二臺服務器mc_set(‘key’, ‘Hello’)。 // 寫入數(shù)據(jù)$key = mc_get(‘key’)。 // 讀出數(shù)據(jù)mc_del(‘key’)。 // 刪除數(shù)據(jù)mc_shutdown()。 // 關閉所有組?APR_Memcache的相關資料可以在這里找到，BSM_Memcache可以在本站下載?！駻PR環(huán)境介紹APR的全稱：Apache Portable Runtime。它是Apache軟件基金會創(chuàng)建并維持的一套跨平臺的C語言庫。它從Apache ，Apache 。APR提供了很多方便的API接口可供使用，包括如內存池、字符串操作、網絡、數(shù)組、hash表等實用的功能。開發(fā)Apache2 Module要接觸很多APR函數(shù)，當然APR可以獨立安裝獨立使用，可以用來寫自己的應用程序，不一定是Apache d的相關開發(fā)。ref： 內存分配管理Memcached快么？非?？?。Memcached使用了libevent（如果可以的話，在linux下使用epoll）來均衡任何數(shù)量的打開鏈接，使用非阻塞的網絡I/O，對內部對象實現(xiàn)引用計數(shù)(因此，針對多樣的客戶端，對象可以處在多樣的狀態(tài))， 使用自己的頁塊分配器和哈希表， 因此虛擬內存不會產生碎片并且虛擬內存分配的時間復雜度可以保證為O(1).。Danga Interactive為提升Danga Interactive的速度研發(fā)了Memcached。目前。而這些，是由一個由web服務器和數(shù)據(jù)庫服務器組成的集群完成的。Memcached幾乎完全放棄了任何數(shù)據(jù)都從數(shù)據(jù)庫讀取的方式，同時，它還縮短了用戶查看頁面的速度、更好的資源分配方式，以及Memcache失效時對數(shù)據(jù)庫的訪問速度。Slab Allocation機制：整理內存以便重復使用最近的memcached默認情況下采用了名為Slab Allocator的機制分配、管理內存。 在該機制出現(xiàn)以前，內存的分配是通過對所有記錄簡單地進行malloc和free來進行的。 但是，這種方式會導致內存碎片，加重操作系統(tǒng)內存管理器的負擔，最壞的情況下， 會導致操作系統(tǒng)比memcached進程本身還慢。Slab Allocator就是為解決該問題而誕生的。下面來看看Slab Allocator的原理。下面是memcached文檔中的slab allocator的目標：the primary goal of the slabs subsystem in memcached was to eliminate memory fragmentation issues totally by using fixedsize memory chunks ing from a few predetermined size classes.也就是說，Slab Allocator的基本原理是按照預先規(guī)定的大小，將分配的內存分割成特定長度的塊， 以完全解決內存碎片問題。Slab Allocation的原理相當簡單。 將分配的內存分割成各種尺寸的塊（chunk）， 并把尺寸相同的塊分成組（chunk的集合）（圖1）。 在Slab中緩存記錄的原理下面說明memcached如何針對客戶端發(fā)送的數(shù)據(jù)選擇slab并緩存到chunk中。memcached根據(jù)收到的數(shù)據(jù)的大小，選擇最適合數(shù)據(jù)大小的slab（圖2）。 memcached中保存著slab內空閑chunk的列表，根據(jù)該列表選擇chunk， 然后將數(shù)據(jù)緩存于其中。 Slab Allocator的缺點Slab Allocator解決了當初的內存碎片問題，但新的機制也給memcached帶來了新的問題。這個問題就是，由于分配的是特定長度的內存，因此無法有效利用分配的內存。 例如，將100字節(jié)的數(shù)據(jù)緩存到128字節(jié)的chunk中，剩余的28字節(jié)就浪費了（圖3）。圖3 chunk空間的使用對于該問題目前還沒有完美的解決方案，但在文檔中記載了比較有效的解決方案。The most efficient way to reduce the waste is to use a list of size classes that closely matches (if that39。s at all possible) mon sizes of objects that the clients of this particular installation of memcached are likely to store.就是說，如果預先知道客戶端發(fā)送的數(shù)據(jù)的公用大小，或者僅緩存大小相同的數(shù)據(jù)的情況下， 只要使用適合數(shù)據(jù)大小的組的列表，就可以減少浪費。但是很遺憾，現(xiàn)在還不能進行任何調優(yōu)，只能期待以后的版本了。 但是，我們可以調節(jié)slab class的大小的差別。 接下來說明growth factor選項。 memcached在數(shù)據(jù)刪除方面有效利用資源 數(shù)據(jù)不會真正從memcached中消失上次介紹過， memcached不會釋放已分配的內存。記錄超時后，客戶端就無法再看見該記錄（invisible，透明）， 其存儲空間即可重復使用。 Lazy Expirationmemcached內部不會監(jiān)視記錄是否過期，而是在get時查看記錄的時間戳，檢查記錄是否過期。 這種技術被稱為lazy（惰性）expiration。因此，memcached不會在過期監(jiān)視上耗費CPU時間。 LRU：從緩存中有效刪除數(shù)據(jù)的原理memcached會優(yōu)先使用已超時的記錄的空間，但即使如此，也會發(fā)生追加新記錄時空間不足的情況， 此時就要使用名為 Least Recently Used（LRU）機制來分配空間。 顧名思義，這是刪除“最近最少使用”的記錄的機制。 因此，當memcached的內存空間不足時（無法從slab class獲取到新的空間時），就從最近未被使用的記錄中搜索，并將其空間分配給新的記錄。 從緩存的實用角度來看，該模型十分理想。不過，有些情況下LRU機制反倒會造成麻煩。memcached啟動時通過“M”參數(shù)可以禁止LRU，如下所示：$ memcached M m 1024啟動時必須注意的是，小寫的“m”選項是用來指定最大內存大小的。不指定具體數(shù)值則使用默認值64MB。指定“M”參數(shù)啟動后，內存用盡時memcached會返回錯誤。 話說回來，memcached畢竟不是存儲器，而是緩存，所以推薦使用LRU。 memcached的最新發(fā)展方向memcached的roadmap上有兩個大的目標。一個是二進制協(xié)議的策劃和實現(xiàn)，另一個是外部引擎的加載功能。 關于二進制協(xié)議使用二進制協(xié)議的理由是它不需要文本協(xié)議的解析處理，使得原本高速的memcached的性能更上一層樓， 還能減少文本協(xié)議的漏洞。目前已大部分實現(xiàn)，開發(fā)用的代碼庫中已包含了該功能。 memcached的下載頁面上有代碼庫的鏈接。 二進制協(xié)議的格式協(xié)議的包為24字節(jié)的幀，其后面是鍵和無結構數(shù)據(jù)（Unstructured Data）。 實際的格式如下（引自協(xié)議文檔）： Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +++++ 0/ HEADER / / / / / / / +++++ 24/ COMMANDSPECIFIC EXTRAS (as needed) / +/ (note length in th extras length header field) / +++++ m/ Key (as needed) / +/ (note length in key length header field) / +++++ n/ Value (as needed) / +/ (note length is total body length header field, minus / +/ sum of the extras and key length body fields) / +++++ Total 24 bytes如上所示，包格式十分簡單。需要注意的是，占據(jù)了16字節(jié)的頭部(HEADER)分為 請求頭（Request Header）和響應頭（Response Header）兩種。 頭部中包含了表示包的有效性的Magic字節(jié)、命令種類、鍵長度、值長度等信息，格式如下：Request Header Byte/ 0 | 1 | 2 | 3 | / | | | | |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| +++++ 0| Magic | Opcode | Key length | +++++ 4| Extras length | Data type | Reserved |