lampabc.com,lamp学习本应更简单, 互帮 互助 共享 ~~~

memcached学习3:删除机制及分步式算法

三、 memcached的删除机制
1,memcached 内部不会监视记录是否过期,而是在 get 时查看记录的时间戳,检查记录是否过期。这
种技术被称为 lazy(惰性)expiration。因此,memcached 不会在过期监视上耗费 CPU 时间。

2,LRU:从缓存中有效删除数据的原理
memcached 会优先使用已超时的记录的空间,但即使如此,也会发生追加新记录时空间不足的情况, 此时就要使用名为 Least Recently Used(LRU)机制来分配空间。顾名思义,这是删除“最近最少 使用”的记录的机制。因此,当 memcached 的内存空间不足时(无法从 slab class 获取到新的空间 时),就从最近未被使用的记录中搜索,并将其空间分配给新的记录。从缓存的实用角度来看,该 模型十分理想。
memcached 启动时通过“­M”参数可以禁止 LRU,如 下所示:
$ memcached ­M ­m 1024
启动时必须注意的是,小写的“­m”选项是用来指定最大内存大小的。不指定具体数值则使用默认 值 64MB。
指定“­M”参数启动后,内存用尽时 memcached 会返回错误。话说回来,memcached 毕竟不是存储 器,而是缓存,所以推荐使用 LRU。


四,emcached的分布式算法
memcached的分布式
正如第 1 章中介绍的那样,memcached 虽然称为“分布式”缓存服务器,但服务器端并没有“分布 式”功能。
至于 memcached 的分布式,则是完全由客户端程序库实现的。这种分布式是 memcached 的最大特点。
现在开始简单地介绍一下“分布式”原理,各个客户端的实现基本相同。
下面假设 memcached 服务器有 node1~node3 三台,应用程序要保存。

首先向 memcached 中添加“tokyo”。将“tokyo”传给客户端程序库后,客户端实现的算法就会根据
“键”来决定保存数据的 memcached 服务器。服务器选定后,即命令它保存“tokyo”及其值。
同样,“kanagawa”、“chiba”、“saitama”、“gunma”都是先选择服务器再保存。


接下来获取保存的数据。获取时也要将要获取的键“tokyo”传递给函数库。函数库通过与数据保存 时相同的算法,根据“键”选择服务器。使用的算法相同,就能选中与保存时相同的服务器,然后 发送 get 命令。只要数据没有因为某些原因被删除,就能获得保存的值。

这样,将不同的键保存到不同的服务器上,就实现了 memcached 的分布式。memcached 服务器增多 后,键就会分散,即使一台 memcached 服务器发生故障无法连接,也不会影响其他的缓存,系统依 然能继续运行。