memcached总结.docVIP

Memcached总结 简述 memcached是以LiveJournal旗下Danga Interactive公司的Brad Fitzpatric为首开发的一款软件。现在已成为mixi、hatena、Facebook、Vox、LiveJournal等众多服务中提高Web应用扩展性的重要因素。许多Web应用都将数据保存到RDBMS中，应用服务器从中读取数据并在浏览器中显示。但随着数据量的增大、访问的集中，就会出现RDBMS的负担加重、数据库响应恶化、网站显示延迟等重大影响。这时就该memcached大显身手了。memcached是高性能的分布式内存缓存服务器。一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、提高可扩展性。 特点 1）协议简单：memcached的服务器客户端通信并不使用复杂的XML等格式，而使用简单的基于文本行、二进制的协议。因此，通过telnet也能在memcached上保存数据、取得数据。 2）基于libevent的事件处理：libevent是个程序库，它将Linux的epoll、BSD类操作系统的kqueue等事件处理功能封装成统一的接口。即使对服务器的连接数增加，也能发挥O(1)的性能。memcached使用这个libevent库，因此能在Linux、BSD、Solaris等操作系统上发挥其高性能。 3）内置内存存储方式：为了提高性能，memcached中保存的数据都存储在memcached内置的内存存储空间中。由于数据仅存在于内存中，因此重启memcached、重启操作系统会导致全部数据消失。另外，内容容量达到指定值之后，就基于LRU(Least Recently Used)算法自动删除不使用的缓存。memcached本身是为缓存而设计的服务器，因此并没有过多考虑数据的永久性问题。 4）memcached不互相通信的分布式：memcached尽管是“分布式”缓存服务器，但服务器端并没有分布式功能。各个memcached不会互相通信以共享信息。那么，分布式是完全取决于客户端的实现。 Memcached处理的原子是每一个(key,value)对(以下简称KV对)，key 会通过一个hash算法转化成hash-key，便于查找、对比以及做到尽可能的散列。同时，memcached用的是一个二级散列，通过一张大hash表来维护。Memcached有两个核心组件组成:服务端(ms)和客户端(mc)，在一个memcached的查询中，mc先通过计算key的hash值来确定kv对所在的ms位置。当ms确定后，客户端就会发送一个查询请求给对应的ms，让它来查找确切的数据。因为这之间没有交互以及多播协议，所以memcached交互带给网络的影响是最小的。 工作原理 Slab Allocation机制 整理内存以便重复使用 Slab Allocator的基本原理是按照预先规定的大小，将分配的内存分割成特定长度的块，以完全解决内存碎片问题将分配的内存分割成各种尺寸的块（chunk），并把尺寸相同的块分成组（chunk的集合） slab allocator还有重复使用已分配的内存的目的。也就是说，分配到的内存不会释放，而是重复利用。Slab Allocation主要术语 Slab 缓存记录原理 memcached根据收到的数据的大小，选择最适合数据大小的slab。 memcached中保存着slab内空闲chunk的列表，根据该列表选择chunk，然后将数据缓存于其中。 Slab Allocator缺点 Slab Allocator解决了当初的内存碎片问题，但新的机制也给memcached带来了新的问题。 这个问题就是，由于分配的是特定长度的内存，因此无法有效利用分配的内存。例如，将100字节的数据缓存到128字节的chunk中，剩余的28字节就浪费了。 item基本总是小于chunk的，chunk size - item size这段空间被浪费。平均而言，浪费的内存和总内存的比将会达到 (factor - 1) / 2，factor为1.25时，这个比值为12.5%。减少这种内存浪费的一个办法是减小factor的值，让chunk大小增长更缓慢。当然，过小的factor值也会带来一个问题，因为最多只能有200个slab class，所以需要计算好。 有很多slab class中可能会没有item或只有很少的，这取决于你的item大小是分散分布的还是集中分布的。极端情况下，你的item是定长的，那它只会分布在一个slab class中，其他class初始化时分配的一个slab大小的空间都是浪费的。 使用Growth Factor进行调优 memcached在启动时指定 Growth Fa