第3章 Memcached 的删除机制和发展方向
Memcached 是缓存，所以数据不会永久保存在服务器上，这是向系统中引入 Memcached 的前提。本次介绍 Memcached 的数据删除机制，以及 Memcached 的最新发展方向：二进制协议（Binary Protocol）和外部引擎支持。
3.1 Memcached 在数据删除方面有效利用资源
数据不会真正从 Memcached 中消失
上一章介绍过， Memcached 不会释放已分配的内存。记录超时后，客户端就无法再看见该记录（invisible 透明），其存储空间即可重复使用。
Lazy Expiration
Memcached 内部不会监视记录是否过期，而是在get时查看记录的时间戳，检查记录是否过期。这种技术被称为 lazy（惰性）expiration。因此 Memcached 不会在过期监视上耗费 CPU 时间。
3.2 LRU：从缓存中有效删除数据的原理
Memcached 会优先使用已超时的记录的空间，但即使如此，也会发生追加新记录时空间不足的情况，此时就要使用名为 Least Recently Used（LRU）机制来分配空间。顾名思义，这是删除 最近最少使用 的记录的机制。因此当 Memcached 的内存空间不足时（无法从 slab class 获取到新的空间时），就从最近未被使用的记录中搜索，并将其空间分配给新的记录。从缓存的实用角度来看，该模型十分理想。
不过有些情况下 LRU 机制反倒会造成麻烦。Memcached 启动时通过 M 参数可以禁止 LRU，如下所示：
$ memcached M m 1024启动时必须注意的是，小写的 m 选项是用来指定最大内存大小的。不指定具体数值则使用默认值 64MB。
指定 M 参数启动后，内存用尽时 Memcached 会返回错误。话说回来，Memcached 毕竟不是存储器，而是缓存，所以推荐使用 LRU。
3.3 Memcached 的最新发展方向
Memcached 的 roadmap 上有两个大的目标。一个是二进制协议的策划和实现，另一个是外部引擎的加载功能。
关于二进制协议
使用二进制协议的理由是它不需要文本协议的解析处理，使得原本高速的 Memcached 的性能更上一层楼，还能减少文本协议的漏洞。目前已大部分实现，开发用的代码库中已包含了该功能。 Memcached 的下载页面上有代码库的链接。
http://danga.com/memcached/download.bml
二进制协议的格式
协议的包为 24 字节的帧，其后面是键和无结构数据（Unstructured Data）。实际的格式如下（引自协议文档）：
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如上所示，包格式十分简单。需要注意的是，占据了16字节的头部(HEADER)分为请求头（Request Header）和响应头（Response Header）两种。头部中包含了表示包的有效性的Magic字节、命令种类、键长度、值长度等信息，格式如下：
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 |
+++++
8| Total body length |
+++++
12| Opaque
+++++
16| CAS |
| |
+++++
Response 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 | Status |
+++++
8| Total body length |
+++++
12| Opaque |
+++++
16| CAS |
| |
+++++如希望了解各个部分的详细内容，可以 checkout 出 Memcached 的二进制协议的代码树，参考其中的 docs 文件夹中的 protocol_binary.txt 文档。
HEADER 中引人注目的地方
看到 HEADER 格式后我的感想是，键的上限太大了，现在的 Memcached 规格中，键长度最大为 250 字节，但二进制协议中键的大小用 2 字节表示。因此理论上最大可使用 65536 字节（216）长的键。尽管 250 字节以上的键并不会太常用，二进制协议发布之后就可以使用巨大的键了。
二进制协议从下一版本 1.3 系列开始支持。
3.4 外部引擎支持
我去年曾经试验性地将 Memcached 的存储层改造成了可扩展的（pluggable）。
http://alpha.mixi.co.jp/blog/?p=129 MySQL 的 Brian Aker 看到这个改造之后，就将代码发到了 Memcached 的邮件列表。Memcached 的开发者也十分感兴趣，就放到了 roadmap 中。现在由我和 Memcached 的开发者 Trond Norbye 协同开发（规格设计、实现和测试）。和国外协同开发时时差是个大问题，但抱着相同的愿景，最后终于可以将可扩展架构的原型公布了。代码库可以从 memcached的下载页面 上访问。
外部引擎支持的必要性
世界上有许多 Memcached 的派生软件，其理由是希望永久保存数据、实现数据冗余等，即使牺牲一些性能也在所不惜。我在开发 Memcached 之前，在 mixi 的研发部也曾经考虑过重新发明 Memcached。 外部引擎的加载机制能封装 Memcached 的网络功能、事件处理等复杂的处理。因此现阶段通过强制手段或重新设计等方式使 Memcached 和存储引擎合作的困难就会烟消云散，尝试各种引擎就会变得轻而易举了。
简单 API 设计的成功的关键
该项目中我们最重视的是 API 设计。函数过多，会使引擎开发者感到麻烦；过于复杂，实现引擎的门槛就会过高。因此最初版本的接口函数只有 13 个。具体内容限于篇幅，这里就省略了，仅说明一下引擎应当完成的操作：
- 引擎信息（版本等）
- 引擎初始化
- 引擎关闭
- 引擎的统计信息
- 在容量方面，测试给定记录能否保存
- 为item（记录）结构分配内存
- 释放 item（记录）的内存
- 删除记录
- 保存记录
- 回收记录
- 更新记录的时间戳
- 数学运算处理
- 数据的flush
对详细规格有兴趣的读者，可以 checkout engine 项目的代码，阅读器中的 engine.h。
重新审视现在的体系
Memcached 支持外部存储的难点是，网络和事件处理相关的代码（核心服务器）与内存存储的代码紧密关联。这种现象也称为 tightly coupled（紧密耦合）。必须将内存存储的代码从核心服务器中独立出来，才能灵活地支持外部引擎。因此基于我们设计的 API，Memcached 被重构成下面的样子：
图 3.1：新的 Memcached 架构重构之后，我们与 1.2.5 版、二进制协议支持版等进行了性能对比，证实了它不会造成性能影响。在考虑如何支持外部引擎加载时，让 Memcached 进行并行控制（concurrency control）的方案是最
为容易的，但是对于引擎而言，并行控制正是性能的真谛，因此我们采用了将多线程支持完全交给引擎的设计方案。以后的改进，会使得 Memcached 的应用范围更为广泛。
3.5 总结
本次介绍了 Memcached 的超时原理、内部如何删除数据等，在此之上又介绍了二进制协议和外部引擎支持等 Memcached 的最新发展方向。这些功能要到 1.3 版才会支持，敬请期待！
下一章介绍 Memcached 的应用知识和应用程序兼容性等内容。