memcached 介绍及启动

1、memcached 介绍

1.1 memcached 是什么？

memcached 是以LiveJournal旗下Danga Interactive 公司的Brad Fitzpatric 为首开发的一款软件。现在已成为mixi、hatena、Facebook、Vox、LiveJournal 等众多服务中提高Web

应用扩展性的重要因素。许多Web 应用都将数据保存到RDBMS 中，应用服务器从中读取数据并在浏览器中显示。但随着数据量的增大、访问的集中，就会出现RDBMS 的负担加重、数据库响应恶化、网站显示延迟等重大影响。这时就该memcached 大显身手了。memcached 是高性能的分布式内存缓存服务器。一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web 应用的速度、提高可扩展性。

内置内存存储方式

研究memcached这个产品，首先从它的内存模型开始：我们知道c++里分配内存有两种方式，预先分配和动态分配，显然，预先分配内存会使程序比较快，但是它的缺点是不能有效利用内存，而动态分配可以有效利用内存，但是会使程序运行效率下降，memcached的内存分配就是基于以上原理，显然为了获得更快的速度，有时候我们不得不以空间换时间。

Memcached的高性能源于两阶段哈希（two-stage hash）结构。Memcached就像一个巨大的、存储了很多<key,value>对的哈希表。通过key，可以存储或查询任意的数据。 客户端
可以把数据存储在多台memcached上。当查询数据时，客户端首先参考节点列表计算出key的哈希值（阶段一哈希），进而选中一个节点；客户端将请求发送给选中的节点，然后
memcached节点通过一个内部的哈希算法（阶段二哈希），查找真正的数据（item）并返回给客户端。从实现的角度看，memcached是一个非阻塞的、基于事件的服务器程序。

为了提高性能，memcached 中保存的数据都存储在memcached 内置的内存存储空间中。由于数据仅存在于内存中，因此重启memcached、重启操作系统会导致全部数据消失。另外，内容容量达到指定值之后，就基于LRU(Least Recently Used)算法自动删除不使用的缓存。memcached 本身是为缓存而设计的服务器，因此并没有过多考虑数据的永久性问题

memcached 不互相通信的分布式

memcached 尽管是“分布式”缓存服务器，但服务器端并没有分布式功能。各个

memcached 不会互相通信以共享信息。那么，怎样进行分布式呢？这完全取决于客户端的实现。

2. memcached 启动

memcached 启动的命令在安装目录的bin 二级目录下，如/home/test/app/memcahced-1.4.2/bin/memcached -p 11222 -m 128 -d -c 256 -P /tmp/memcached.pid

常用的一些启动选项介绍选项说明

-p 侦听的端口，默认为11211

-m 分配给memcache使用的内存大小，单位是MB，默认的64m

-d 作为daemon 在后台启动

-vv 用very vrebose 模式启动，调试信息和错误输出到控制台

-l 侦听的地址，默认为所有可以访问的地址

-M 用于在内存溢出的时候，返回一个错误，禁止自动的移出数据，替代的是返回一个error

-P Pid 文件存在的路径，仅限加上-d 参数是用

-c 最大同时的连接数，默认为1024

其它的一些选项，可以通过–h 命令来进行查看

2.3命令行访问memcached

下面假设memcached 启动时的-p 参数为11311，命令操作在启动memcached

本机首先telnet 连接到memcached 服务器

telnet 127.0.0.1 11311

telnet 成功之后，大概会显示下面的信息

Trying 127.0.0.1...

Connected to localhost.localdomain (127.0.0.1).

Escape character is '^]'.

3. 适用memcached的业务场景？

1）如果网站包含了访问量很大的动态网页，因而数据库的负载将会很高。由于大部分数据库请求都是读操作，那么memcached可以显著地减小数据库负载。

2）如果数据库服务器的负载比较低但CPU使用率很高，这时可以缓存计算好的结果（ computed objects ）和渲染后的网页模板（enderred templates）。

3）利用memcached可以缓存session数据、临时数据以减少对他们的数据库写操作。

4）缓存一些很小但是被频繁访问的文件。

5）缓存Web 'services'（非IBM宣扬的Web Services，译者注）或RSS feeds的结果.。

4. 不适用memcached的业务场景？

1）缓存对象的大小大于1MB

Memcached本身就不是为了处理庞大的多媒体（large media）和巨大的二进制块（streaming huge blobs）而设计的。

2）key的长度大于250字符

3）虚拟主机不让运行memcached服务。如果应用本身托管在低端的虚拟私有服务器上，像vmware, xen这类虚拟化技术并不适合运行memcached。Memcached需要接管和控制大块的内存，如果memcached管理的内存被OS或 hypervisor交换出去，memcached的性能将大打折扣。

4）应用运行在不安全的环境中

Memcached为提供任何安全策略，仅仅通过telnet就可以访问到memcached。如果应用运行在共享的系统上，需要着重考虑安全问题。

5）业务本身需要的是持久化数据或者说需要的应该是database

5. 不能能够遍历memcached中所有的item

     这个操作的速度相对缓慢且阻塞其他的操作（这里的缓慢时相比memcached其他的命令）。memcached所有非调试（non-debug）命令，例如add, set, get, fulsh等无论

memcached中存储了多少数据，它们的执行都只消耗常量时间。任何遍历所有item的命令执行所消耗的时间，将随着memcached中数据量的增加而增加。当其他命令因为等待（遍历所有item的命令执行完毕）而不能得到执行，因而阻塞将发生。

6. memcached能接受的key的最大长度是250个字符

memcached能接受的key的最大长度是250个字符。需要注意的是，250是memcached服务器端内部的限制。如果使用的Memcached客户端支持"key的前缀"或类似特性，那么key（前缀+原始key）的最大长度是可以超过250个字符的。推荐使用较短的key，这样可以节省内存和带宽。

7. 单个item的大小被限制在1M byte之内

因为内存分配器的算法就是这样的。

8. memcached对item的过期时间有什么限制？

item对象的过期时间最长可以达到30天。memcached把传入的过期时间（时间段）解释成时间点后，一旦到了这个时间点，memcached就把item置为失效状态，这是一个简单但obscure的机制。

9. 什么是二进制协议，是否需要关注？

二进制协议尝试为端提供一个更有效的、可靠的协议，减少客户端/服务器端因处理协议而产生的CPU时间。根据Facebook的测试，解析ASCII协议是memcached中消耗CPU时间最多的

环节。

10. memcached的内存分配器是如何工作的？为什么不适用malloc/free！？为何要使用slabs？

实际上，这是一个编译时选项。默认会使用内部的slab分配器，而且确实应该使用内建的slab分配器。最早的时候，memcached只使用malloc/free来管理内存。然而，这种方式不能与OS的内存管理以前很好地工作。反复地malloc/free造成了内存碎片，OS最终花费大量的时间去查找连续的内存块来满足malloc的请求，而不是运行memcached进程。slab分配器就是为了解决这个问题而生的。内存被分配并划分成chunks，一直被重复使用。因为内存被划分成大小不等的slabs，如果item的大小与被选择存放它的slab不是很合适的话，就会浪费一些内存。

11. memcached是原子的吗？

所有的被发送到memcached的单个命令是完全原子的。如果您针对同一份数据同时发送了一个set命令和一个get命令，它们不会影响对方。它们将被串行化、先后执行。即使在多线程模式，所有的命令都是原子的。然是，命令序列不是原子的。如果首先通过get命令获取了一个item，修改了它，然后再把它set回memcached，系统不保证这个item没有被其他进程（process，未必是操作系统中的进程）操作过。memcached 1.2.5以及更高版本，提供了gets和cas命令，它们可以解决上面的问题。如果使用gets命令查询某个key的item，memcached会返回该item当前值的唯一标识。如果客户端程序覆写了这个item并想把它写回到memcached中，可以通过cas命令把那个唯一标识一起发送给memcached。如果该item存放在memcached中的唯一标识与您提供的一致，写操作将会成功。如果另一个进程在这期间也修改了这个item，那么该item存放在memcached中的唯一标识将会改变，写操作就会失败。

转自：http://blog.csdn.net/codetomylaw/article/details/41481955

http://zhihuzeye.com/archives/2361