参考了以下资源和 memcached-1.2.5的源代码，画了一个memcached模型图，作为下面资源的补充。
slab内存模型的优点(减少碎片，速度快)和缺点(有空间浪费)下面的链接里面都有讲，Tim也没有什么新观点，就不重复了。

参考资源：
Current memcached memory management:
http://lists.danga.com/pipermail/memcached/2003-September/000214.html

LRU淘汰算法只是在每个SLAB内部使用，下面文章说将来版本考虑使用一个全局LRU淘汰算法。
New proposal:
http://lists.danga.com/pipermail/memcached/2003-October/000302.html

还有一篇网上流传比较多的中文的文章，写得很详细，包括hash算法都有介绍。Memcached深度分析

3/8补充：
看到另外一个白板图memcache使用小结,具体内容和我的基本类似。

这几天听说了memcachedb

memcachedb故名思义就是 memcached + bdb，是基于memcached Socket层和berkeley-db存储层结构的实现， 是新浪互动社区技术团队2007年的一项重大的技术成果，现在应用于新浪互动社区多个产品线中，其中包括新浪博客等重头产品。能够实现任意memcache api的调用、数据实时落地以及主辅实时备份。

初步感觉用处不大，无非就是利用memcache协议的一个db，性能应该不会很高。如果有分布式需要用手工分数据库的方法也可以实现。但看了介绍http://blog.csdn.net/simonlsy/archive/2008/01/07/2027933.aspx说性能可以达到读写5000次/秒，觉得还是有它的价值。所以简单测试了一下

1. 环境
OS: Linux, Ubuntu 7.04 64-bit
Memory: 4G
CPU: Intel(R) Pentium(R) D CPU 2.66GHz
SCSI DISK, ext3 file system

libevent 1.3e
Memcached 1.2.4
Berkeley DB 4.6.21
Java 1.6.0
memcachedb 0.1.1 安装方法 http://blog.csdn.net/simonlsy/

2. 测试方法
client/server在同一机上，使用ethernet interface连接, 不是localhost
本Linux同时在作 ADSL route gateway，可能会对测试造成小量影响。

JAVA CLIENT, 使用3线程
Key: 数字,1~100万
数据：100字节字符串


3. 测试结果
Memcached 写速度
平均速度: 16222 次/秒
最大速度 18799 次/秒

Memcached 读速度
平均速度: 20971 次/秒
最大速度 22497 次/秒

Memcachedb 写速度
平均速度: 8958 次/秒
最大速度 10480 次/秒

Memcachedb 读速度
平均速度: 6871 次/秒
最大速度 12542 次/秒

由于硬件环境，网络环境，线程数，编程语言不同，可能测试结果差别也很大，本测试结果只起相对参考作用。即比较memcached/memcachedb在相同环境下的性能区别。

去年，我曾经多 1.3.2 版本的 java client 很不满意，具体见

http://hi.baidu.com/jabber/blog/category/Memcached

今年，它推出了两个新版本，据说

02-28-2007

12-17-2006

http://www.whalin.com/memcached/

最近终于抽空测试了一下。


GET 测试方法是向服务器查询一个随机的 key, 不知道匹配不到会不会影响速度。测试结果表现较差。
SET 是存取一个随机KEY, VALUE是0.1k的字符串。

在我的测试环境下，6个线程性能达到最佳，GET上限是9000，SET上限是13000。

memcached 在另外一台服务器，CPU占用在5%以下，应该不会成为瓶颈。

结论：set的速度已经趋于可以接受，get的速度待提高。

Performance compare:

Tim  http://hi.baidu.com/jabber/blog/category/Memcached

memcached 1.2.0
MySQL 5.0.26 with MEMORY (heap) engine

记录数：50万~100万条

单机，client 从另外一台机访问
数据：单条 0.1K左右

memcached set/get 15,000 / s
MySQL memory table: insert/select 5,000 / s

结论：
memcached 读写速度是 mysql memory table 3倍左右

优点：
MySQL: 适合对 cache 数据进行Select条件查询。
MemCached: 可以设置 exptime (超时时间)，无需自己管理

想用刀去杀怪的时候，却发现刀是生锈的……当你想用高速缓存的时候，却发现访问缓存的工具很慢，memcached java client API 就是这样一把生锈的刀

java memcached client 是一个第三方提供的访问 memcached 的 library，所以我对他的性能一直抱怀疑的态度。在碰到增加线程不能提高速度并且client CPU 99%的情况之后更坚定了我的看法。经过分析他的代码，找到了两个主要问题：

1. synchronized 的问题
java memcached client源文件的大量方法里面都直接使用 synchronized 如 getConnection(), checkin() 等，而SockIOPool类似一个Singleton, 因此造成多线程失去了意义。同时 synchronized 方法里面又大量使用了 Hashtable 等synchronized保护的集合类。

2. InputStream 不优化的用法：

未加Buffer
private DataInputStream in = new DataInputStream( sock.getInputStream() );

一次读一字节
while (in.read(b, 0, 1) != -1)...
虽然说局域网的网速不存在问题，但是这样操作的话速度可想而知。

改了这些问题之后，访问速度每秒由6,666变成15,000左右。

上面两个是主要的，其他还有一些小问题，比如 socket 每次使用都需要从两个hashtable中checkin, checkout，也会造成大量的同步锁等待，这个问题还没改，因为他的整个思路都是基于这个的，改了这个地方基本上要全部重写了。

另外如果再使用Java NIO，加上同步锁的一些问题得到改善的话，估计每秒可优化到20,000次左右。

今天写了个Java程序从 MySQL 读入数据，然后写到LAN中另外一台Server的 memcached, 通过memcached Java Client API进行访问，瓶颈明显在 memcached 这边，MySQL 读入数据用我前几天改进的 limit 改进方法速度太快了，根本不用关心。程序测试当中发现memcached RPS最高达到20k，以为问题解决了，后来又发现是统计方法错误，最后优化再优化RPS结果是6,666。 好数字，可惜没达到我的期望值。

测试写入数据
1 million, 100 万条
key = Integer
Value = 32个字节的 string

Client 环境
线程: 5个，发现再加线程也没有用了
Java 5.0
Windows XP
CPU: P4 2.8G
CPU 占用率：> 60%

Memcached 环境
CPU: Xeon 3G
CPU 占用率：< 20%
RAM: 1024M for memcached
Linux 64-bit
LAN: 1G

疑问：
1. set 能不能批量写？现在每次只能写一条，据说 Get 可以批量返回结果。
2. client api 为什么每个 set 都需要复杂的计算使用哪个 connection, 为什么 connection 不能重用？
3. 为什么client增加线程不起作用？为什么client CPU占用率高，感觉 Java Client API有问题。

我期望的结果应该要10k以上，因为client/server之间是重用连接，就象http keep-alive一样，网络的开销应该非常小。


摘录自作者的一段话
A final optimization worth noting is that the protocol allows fetching multiple keys at once. This is useful if your application knows it needs to load a few hundred keys. Instead of retrieving them all sequentially, which would take a fraction of a second in network round-trips, the application can fetch them all in one request. When necessary, the client libraries automatically split multi-key loads from the application into separate parallel multi-key loads to the Memcached instances. Alternatively, applications can provide explicit hash values with keys to keep groups of data on the same instance. That also saves the client library a bit of CPU time by not needing to calculate hash values.
原文：http://www.linuxjournal.com/article/7451

网上另外还有个人比较每种语言的速度，得出的结论是php client最快，可惜他的CPU太慢(P3 650)，样本空间太小（1万条），线程比我多（20个），最后他的结果最快的速度是我的1/100，所以他这个结果对我来说没什么借鉴意义。
http://dealnews.com/developers/memcached.html

有时间还要进一步分析。