Memcached的最佳实践和内部机制(译)

MEMCACHED 的最佳实践和内部机制 译) 的最佳实践和内部机制(译
原始文章 Memcached Internals 是在 2008 年 MySQL Conf 上的一篇 /2008/04/22/mysql-conf-memcached-internals/ 本文对 memcached 的使用提出了一些建议,并讲述了一些 memcached 内部的一些实现机制.是我们 可以更好的理解应用 memcached.
MEMCACHED 的最佳实践
Memcached 是一个高性能的分布式缓存系统,它是独立应用的,当前被许多大型的网站使用,比如 Facebook(在 2008 年第一季度有 2TB 的缓存), Livejournal, Mixi, Hi5 等,然而他也是一个极端简单 的软件:所有的逻辑在客户端,没有安全模型,容灾处理,备份机制或持久化.然而这些并不影响他被开 发这发布到各种情况的环境中,如下有 Brian 做的一些关于 memcached 的最佳时间的建议: 1.不要想行级别(数据库)的缓存,考虑复杂对象. 2.不要在数据库服务器上运行 memcached,给你的数据库提供一切可能使用的内存. 3.不要担心 TCP 的延迟-本机的 TCP/IP 已经被优化为内存拷贝. 4.考虑 multi-get-在任何可能的情况下用并发来处理事情. 5.不是所有的 memcached 客户端都是等同的,做你自己的调研.-提示使用 Brians 的.
片分配器-MEMCACHED 的心脏 片分配器
memcached 的心脏是他的内存片分配器,第一感觉令人有点畏惧,但是当你明白他架构中所采用的平衡 机制等,你会从内心中体会出他确实是一个高雅的解决方案. 1.memcached 所能分配的内存最大值仅由系统的架构决定(32/64 位) 2.key 值大小限制到 250 字节,data 值大小限制到 1mb 3.在启动时,memcached 获取需要的内存-在性能前浪费内存 4.分配的内存由片分配器切分为不同大小的桶. 5.默认情况下片分配器将创建 32-39 个桶用来存放最大到 1mb 大小的对象. 6.你可以在编译时设置页大小,并在启动时设置片大小. 7.每一个被存储的对象存在最相近大小的桶中-是的,内存是被浪费的. 8.碎片是个问题-无论是定义片大小或时常回收/冲刷你的缓存. 9.如果在一个不同的片类中没有未被使用的内存,该内存将在需要的时候被重分配. 10.保证 no-paging,禁用你系统的交换空间(swap)-实用的是将他变小来避免出问题.
内存管理
内存管理使用的是 LRU 算法 1.每一个片类有他自己的 LRU-回收目标依赖于对象的大小 2.没秒钟检查一次截止时间戳-最小寿命是 1 秒 3.异步处理被标志为删除的对象-每 5 秒检查回收一次 4.上面两个时间的不一致会导致次最佳回收规则 5.可以完全禁用 LRU-这样做自己担当风险
关于失效和截止期的最佳实践
Memcached 不提供任何关于删除一个相关联 key 集合(对象,名称等等)的机制.不管是好是坏,你需要 在 prepend 和 append 命令的帮助下自己实现该功能,然而,需要小心这个 1mb 大小的限制.一个非常 简单的处理该情况的方式是完全放弃一起失效过程.

1.在任何可能的时候通过设置截止时间来使你的数据失效-memcached 会做所有的工作. 2.生成有提示性的 key-比如,在更新,添加一个版本号,将成为 key 的一部分 3.作为奖励点,在 memcached 中存储版本号-称作一代 4.后面的将会很快添加到 memcached 中-只要 Brian 考虑做他.
ROADMAP 和未来展望
1.二进制协议在处理中 2.支持代处理-前面章节提到 3.多引擎支持:基于字符的,持久的,队列的 4.Facebook 已经修改过的核心,有望被贡献出来. 感谢 Brian 和 Alan 的伟大工作,不要忘记做书签并常回来看看(指原文).