memcache 的总体轮廓一览

川长思鸟来 2022-08-06 04:17 104阅读 0赞

memcache的server模型以及分布式的一些概念、算法很值得研究

最近打算读一读源代码，先转一下其他同学的一些看法

1.关于本文档  
       本文档所有的分析都是在1.2版本之上,偶尔会提到比较1.1版本.其他版本没有阅读.  
        一个星期时间的工作,不可能对memcache有很深刻的分析.文档本身的目的在于为以后的研究准备一个总结资料.刚接触memcache时,对其设计分布式的思路感到十分欣喜,因为在中间层以极小的代价实现简单分布式无疑成为一些要求不是很高的分布式应用的一个很好的设计思路,这个特性决定memcache本身在分布式应用中,单个结点之间是Server相互独立,不会存在同级之间的通信.一个结点拒绝访问,如果没有相应的冗余策略,将导致该结点的数据丢失.同时,memcache的Server结点对数据的存储操作都是在内存中完成,而memcache对内存分配和回收采用了曾在SunOS实现的分页机制,预分配一个大内存(默认是 <= 200M),然后分页切块,对每个数据对象的存储便在所切的块中进行操作.这个特点决定memcache没有设计到任何磁盘IO操作,那么所有的关于memcache的性能瓶颈都在网络通信部分,而memcache正是将这一部分抛给了一个中间层完成.可以说真正的memcache是一个单进程,单线程,监听某个网络端口的daemon(或非daemon),是一个轻量级的应用服务进程.这些特性决定了memcache的应用范围,性能瓶颈和优化策略.  
       本文档的目的也就诣在探讨查看memcache源码后的一些观点.  
       文档分为六个部分:  
       1.  文档介绍.主要介绍文档组织和文档目的.  
       2.  memcache的代码分析.分析memcache的源代码,指出核心的数据结构和算法.  
       3.  memcache的使用优化.分析memcache的特点,结合实际应用给出一些优化memcache的策略.  
       4.  memcache的测试分析.初略测试了memcache,给出优化方案的例证.  
       5.  memcache的中间层客户端编写.分析memcache的通信协议,模拟编写了一个简单的memcache中间层客户端.  
       6.  libevent简介.memcache采用的是libevent进行网络IO处理,libevent作为一种新的网络IO方式以高效的方法(epoll/kqueue)组织IO.  
       其中第六章可以不看.对于系统管理员,需要查看第一,三,四部分;进行二次开发的程序员可以查看第一,二,四,五,六部分.  
  
2.memcache代码分析  
       1. memcache main流程  
[![点击在新窗口中浏览此图片][memcache_f1.jpg]][memcache_f1.jpg]  
图2.1 memcache main流程  
       libevent的事件处理机制在main进程里体现在处理网络IO上.在TCP memcache的服务流程里,也是利用event处理事件的.  
       2. memcache服务流程(TCP)  
[![点击在新窗口中浏览此图片][memcache_f2.jpg]][memcache_f2.jpg]  
图2.2 memcache服务流程图(TCP)  
       3. memcache状态转换和通信协议处理  
[![点击在新窗口中浏览此图片][memcache_f3.jpg]][memcache_f3.jpg]    
图2.3 memcache状态转换和通信协议处理  
       需要说明的是,这里需要排除所有出错处理.很显然,不管是哪种操作下,一旦出错,信息需要通过conn\_write状态往client写入出错信息的,那么在string\_out时,必定转入conn\_write状态.  
       而且,很多细节也没有在流程图中给出,如统计信息的处理,超时后get操作时删除等等.对于在memcache协议中定义的其他操作,如stats,version,quit,flush\_all,own,disown等等由于使用很少,在流程中没有详细给出,可以查看源代码.  
       4.  memcache核心数据结构  
               1. item结构  
       item是存储在memcache的key-value对的抽象.由于组织item存放是按照LRU算法组织的.那么在其中有几个成员在修改源代码时必须注意,time是最近访问时间.exptime是item消亡时间.item是一个双向列表.同时还挂在一个Hash table上.  
               2. conn结构  
       conn结构是联系上下文的关键对象.对于每个连接的到来,都有一个conn结构与其对应,并且对应到某个连接状态,进入状态转换而完成操作.  
       conn在程序开始也进行了一次预分配,分配200个连接空间.当200个使用完之后便是按需分配,到达一个分配一个.  
       conn和item,iovec(内核级别缓冲结构)关联.  
               3. slabclass\_t结构  
       slabclass\_t保存了分级大小的空间槽,以分别适用于不同大小的item存放.取决于两个命令行参数,-f和-n.在应用slabclass\_t时,定义的是一个数组,该数组长度取决于增长的指数级别和初始值大小(32+chunk\_size),每个空间槽是不允许大于1M的,也就是1048576.  
               4. settings结构  
        系统获取的命令行参数保存的地方.  
               5. stats结构:  
       统计信息保存地方,可以考虑对其进行操作以适应不同的统计信息处理,如获取某个时间段的get命中率等等操作.  
       5.  memcache核心算法  
       事件触发处理连接,LRU算法挂载item,加锁并事后处理删除操作,预分配空间和按需请求不够空间策略获取存储空间,freelist方式管理空闲空间.名为new\_hash的hash算法计算key的hash值[http://burtleburtle.net/bob/hash/evahash.html][http_burtleburtle.net_bob_hash_evahash.html]

3.memcache使用优化  
       在优化memcache的工作之前,需要了解memcache体系的工作流程.一个分布式的memcache的运作是需要三个部分的,多台提供memcache服务的servers(简称S),一个进行分布式映射的中间层lib(其实这个也可以当作客户端的一部分,简称L),和进行memcache请求的客户端(简称C).  
       在memcache工作时,有以下四个步骤:  
       1.  C通过带有特性化的Key值的命令串,向L请求memcache服务,L将命令串进行分解,并通过对key的某种Hash算法决定S的地址  
       2.  L将分解的(Comm Key-Value)或者(Comm Key)向相关的S请求memcache服务.  
       3.  相关的S根据memcache协议向L返回服务结果.  
       4.  L将结果进行聚集包装后返回给C一个人性化的响应.  
       这个流程可以用图3.1进行描述.  
[![点击在新窗口中浏览此图片][memcache_w1.jpg]][memcache_w1.jpg]  
图3.1 memcache工作步骤  
       在每个S端,请求处理的Key-Value对当作一个对象(不过这个对象的结构是单一的),再进行另一步hash之后,存储在内存里.存储算法在第二部分有详细的描述.这种通过双层hash来分开处理分布式和缓存两个功能的方法值得学习.  
       从上面的分析可以看出,分布式的memcache服务是需要很大的网络开销的.对于一般的应用而言,是否都要进行memcache的优化,甚至是否需要用到memcache,都需要进行权衡分析.如果只是本地小规模的应用,在数据库可承受的范围内,是宁愿采用数据库+文件缓存的方式.1.1版本的memcache走TCP模式在本地应用的处理速度甚至比不上Mysql数据的Unix域套接口的处理速度的一半,当然会更加比不上在程序内部直接操作内存了.虽然1.2版本的memcache已经提供了-s参数指定Unix域套口和-u指定udp模式.而且如果不需要用到分布式的话,不推荐使用memcache,除非你的内存足够大到浪费的程度.  
       因此,在进行优化之前,需要看看是否真的需要优化memcache,是否真正需要用到memcache.  
       优化可以从以下几个方面进行：  
       1.  命中率.  
       对于缓存服务而言,命中率是至关重要的.命中率的提升可以通过多种方案实现.其一,提高服务获取的内存总量.这无疑是增加命中的最直接的办法,将缓存数据完全放入数据池中.只要连接不失效,就一定命中.其二,提高空间利用率,这实际上也是另一种方式的增加内存总量.具体实现在下一个方面给出.其三,对于一些很特别的memcache应用,可以采用多个memcache服务进行侦听,分开处理,针对服务提供的频繁度划分服务内存,相当于在应用一级别上再来一次LRU.其四,对于整体命中率,可以采取有效的冗余策略,减少分布式服务时某个server发生服务抖动的情况.如,14台机器实现分布式memcache,划分两组服务,其中一组13台做一个分布式的memcache,一组1台做整个的memcache备份.对于update操作,需要进行两边,get操作只需要一遍,一旦访问失效,则访问备份服务器.这样,对于备份服务器需要内存比较大,而且只适应于读操作大于写操作的应用中.这可以认为是RAID3,当然,也可以采用RAID1完全镜像.  
       2.  空间利用率.  
       对于使用memcache做定长数据缓存服务而言,是可以在空间利用率上进行优化.甚至最简单的办法可以不用更改memcache的源码遍可以完成由-f和-n参数的配合可以做到定长优化,不过极可能需要浪费掉预分配的199M内存空间.当然前提是memcache的版本是1.2,同时如果使用的是1.2.0和1.2.1的话,需要更改掉一个BUG,那就是getopt时将opt串中最后一个”s”改成”n”,希望memcache能在以后的版本发现这个BUG.例如,如果key是一个定长id(如一个8位的流水号00000001),value是一个定长的串(如16位的任意字符串),对应于一个chunk\_size可以这么计算:chunk\_size = sizeof(item) + nkey + \*nsuffix + nbytes = 32 + 9 + (flag的数位长度 )2+ (16)的数位长度) 2+(两换行的长度)4 + 17 = 40 + 10 + 16 = 66,那么可以通过 -f 1.000001 -n  \`expr 66 - 32\`,即 -f 1.000001 -n 34 来启动memcache.这种情况下,会浪费掉memcache预先分配的200M空间中的199M.从第2个预分配等级到第200个预分配等级将不会用到.然而,存在解决办法,那就是在编译memcache是加入编译参数-DDONT\_PREALLOC\_SLABS,或者在源代码中加入\#define DONT\_PREALLOC\_SLABS即可,只是会去除memcache的预分配内存机制.  
       如果需要memcache的预分配内存机制,那么需要对其源代码进行修改.修改如下:

引用

1. 在slabs.c中,将函数slabs\_clsid改成:  
     unsigned int slabs\_clsid(size\_t size)  
     \{   unsigned int res = POWER\_SMALLEST;  
       if(size==0)  
                 return 0;  
       res = (size)%power\_largest;  
       return res;  
     \}  
   2. 在item.c中,将函数 item\_make\_header改为:  
     int item\_make\_header(char \*key, uint8\_t nkey, int flags, int nbytes,  
                    char \*suffix, int \*nsuffix)  
     \{  
           \*nsuffix = sprintf(suffix, " %u %u/r/n", flags, nbytes - 2);  
           return sizeof(item)+ nkey + \*nsuffix + nbytes + hash(key,nkey,0);  
     \}  
   3. 在item.c中,将函数 item\_free改为:  
     void item\_free(item \*it)  
     \{  unsigned int ntotal = it->slabs\_clsid;  
           assert((it->it\_flags & ITEM\_LINKED) == 0);  
           assert(it != heads\[it->slabs\_clsid\]);  
           assert(it != tails\[it->slabs\_clsid\]);  
           assert(it->refcount == 0);  
  
           it->slabs\_clsid = 0;  
           it->it\_flags |= ITEM\_SLABBED;  
           slabs\_free(it, ntotal);  
     \}

做一个轮流存储的机制使用预分配的内存,这样的好处是其他地方不需要做任何修改就可以了,当然你可以在源代码中加入上面的代码,并将它们放在一个自定义的宏后面.  
       3.  加速比.  
       加速比,也即事件的处理效率.是否可以修改libevent的事件处理效率,需要研究.如果内存空间很大,可以将freeconn的数值调大,增加预分配的conn内存大小.  
       是否可以将memcache做成多线程处理,但在处理多线程数据同步是个问题.  
        如果有时间,愿意来试试这个策略.  
       4.  安全性能.  
       memcache还存在一个比较显著的问题,那就是其安全性能.只要了解memcache监听的端口,对于能够使用分布式memcache进行数据通信的网络环境的机器,都可以通过memcache协议于memcache服务器进行通信,获取或种植数据.不能保证种植进内存里的数据不会被别有心意的人再利用.也不能保证服务器的内存不被漫天遍地的垃圾数据所堆积,造成命中极低.  
       memcache的设计理念在一个轻字,如果对每次Client的通讯需要校验身份,那么恐怕memcache也就达不到其想要的效果了.存在解决办法缓解这个问题,一般而言,需要使用memcache服务的机器,可以在Server维持一张红色列表.这张表上的机器便可以获取服务.很显然,memcache并非任意Client都能访问,只有信任的机器访问,那么为什么不将这些信任的机器放在一个/etc/mem\_passwd下呢.  
       还有,memcached走udp时,很大几率接受到upd时,都会使服务死掉,特别是set,add,replace时,这个问题需要去考究一下.不过没有时间了.  
  
4.memcache测试分析  
       服务器端memcache在命令行运行的参数:

引用

\# memcached –d –m 512 –l \*.\*.\*.\* -u \*\* -f 1.00001 –n 16 –c 10000 -vv

1.  读写memcache指令测试  
       在利用了memcache官方推荐的c客户端libmemcache和自己编写的一个简单客户端测试之后,在set/get/add/del指令的运行速度如表4.1和图4.1所示:  
[![点击在新窗口中浏览此图片][memcache_t1.jpg]][memcache_t1.jpg]  
表4.1 memcache的指令运行速度  
图4.1 memcache的指令运行速度  
       2.  并发连接  
       由于在memcache服务器端,一个结点运行的是单进程单线程的daemon(或非daemon)服务,同时对于采用了libevent处理网络IO而言,其并发连接的数目是和libevent采用的机制相关连的.很显然,accept函数在接收到connection后将Client的socket放进event库中,等待处理.而libevent库在LINUX中使用的是epoll,监听EPOLLIT水平触发.因此从理论上讲,memcache的并发连接可以达到infinite,前提是event池和内存空间足够大.而没有和linux的线程处理有关系.事实上,在后面的测试中便可发现,在单结点连接压力测试时,瞬时并发连接可以达到5000多个.只是等待触发时间上的长短和有效无效的区别.  
       在表4.2中可以清晰的看到并发连接的一些数据.  
       3.  服务端系统负载  
       通过自己编写的服务器端,对单结点的memcache进行了连接压力测试.其中测试用例的编写是这样的:启用七个客户端,每个客户端串行运行1000个进程,每个进程开3000线程,每个线程执行10次memcache的读操作或者写操作(操作相同).客户端并发连接.  
       1.  客户端(7)的环境:Intel(R) Xeon(R) CPU 5120 @ 1.86GHz,4G memory.  
       2.  服务器端(1)的环境:Intel(R) Xeon(R) CPU 5120 @ 1.86GHz,4G memory.  
       3.  网络环境:100M网卡,Cisco交换机.  
       4.  数据记录:见表4.2和图4.2.  
[![点击在新窗口中浏览此图片][memcache_t2.jpg]][memcache_t2.jpg]  
表4.2 memcache连接和系统负载  
图4.2 memcache连接和系统负载  
       很显然,memcache的运行在系统cpu的消耗上占十分少的比重,即便是很恐怖的并发连接也不会给系统带来多大的负载,因为其磁盘IO free(所有操作都在内存中)和相应的内存分配机制决定其占用cpu的极少,而相反,在网络IO上却花费很大的时间.  
       4.  空间分配,命中率  
       由于本地测试式的get数据非常固定,因此命中率基本为100%.在10.68.1.31上运行了一个有前端应用的memcachce服务器,运行时间已经有364个多小时了.  
       因此通过10.68.1.31上的数据说明(版本为1.1.13).通过memcache的统计协议可以清楚的看到其命中率高达95.9%,如表4.3所示:  
[![点击在新窗口中浏览此图片][memcache_t3.jpg]][memcache_t3.jpg]  
表4.3 memcache空间分配和命中  
  
5.memcache客户端编写  
       1.  [memcache协议][memcache]  
       在memcache协议中规定了Client和Server的通信规则.  
       在源码分析中,主要分析了update/get/del/incr/decr几类的处理过程.其具体的规则可以在官方文档中有说明(),这里做简单的解释.

**协议**  
memcached 的客户端使用TCP链接 与 服务器通讯。（UDP接口也同样有效，参考后文的 “UDP协议” ）一个运行中的memcached服务器监视一些（可设置）端口。客户端连接这些端口，发送命令到服务器，读取回应，最后关闭连接。

结束会话不需要发送任何命令。当不再需memcached服务时，要客户端可以在任何时候关闭连接。需要注意的是，鼓励客户端缓存这些连接，而不是每次需要存取数据时都重新打开连接。这是因为memcached 被特意设计成及时开启很多连接也能够高效的工作（数百个，上千个如果需要的话）。缓存这些连接，可以消除建立连接所带来的开销（/\*/相对而言，在服务器端建立一个新连接的准备工作所带来的开销，可以忽略不计。）。

在memcache协议中发送的数据分两种：文本行 和 自由数据。 文本行被用于来自客户端的命令和服务器的回应。自由数据用于客户端从服务器端存取数据时。同样服务器会以字节流的方式传回自由数据。/\*/服务器不用关心自由数据的字节顺序。自由数据的特征没有任何限制；但是通过前文提到的文本行，这项数据的接受者（服务器或客户端），便能够精确地获知所发送的数据库的长度。

文本行固定以“/r/n”(回车符紧跟一个换行符)结束。 自由数据也是同样会以“/r/n”结束，但是 /r(回车符)、/n(换行符)，以及任何其他8位字符，均可出现在数据中。因此，当客户端从服务器取回数据时，必须使用数据区块的长度来确定数据区块的结束位置，而不要依据数据区块末尾的“/r/n”，即使它们固定存在于此。

**键值**  
存储在memcached中的数据通过键值来标识。键值是一个文本字符串，对于需要存取这项数据的客户端而言，它必须是唯一的。键值当前的长度限制设定为250字符（当然，客户端通常不会用到这么长的键）；键值中不能使用制表符和其他空白字符（例如空格，换行等）。

**命令**  
所有命令分为3种类型：  
存储命令（有3项：’set’、’add’、’repalce’）指示服务器储存一些由键值标识的数据。客户端发送一行命令，后面跟着数据区块；然后，客户端等待接收服务器回传的命令行，指示成功与否。  
取回命令（只有一项：’get’）指示服务器返回与所给键值相符合的数据（一个请求中右一个或多个键值）。客户端发送一行命令，包括所有请求的键值；服务器每找到一项内容，都会发送回客户端一行关于这项内容的信息，紧跟着是对应的数据区块；直到服务器以一行“END”回应命令结束。  
/\*?\*/其他的命令都不能携带自由数据。在这些命令中，客户端发送一行命令，然后等待（由命令所决定）一行回应，或最终以一行“END”结束的多行命令。

一行命令固定以命令名称开始，接着是以空格隔开的参数（如果有参数的话）。命令名称大小写敏感，并且必须小写。一些客户端发送给服务器的命令会包含一些时限（针对内容或客户端请求的操作）。这时，时限的具体内容既可以是Unix时间戳（从1970年1月1日开始的秒钟数），或当前时间开始的秒钟数。对后者而言，不能超过 60\*60\*24\*30（30天）；如果超出，服务器将会理解为Unix时间戳，而不是从当前时间起的秒偏移。

**错误字串**  
每一个由客户端发送的命令，都可能收到来自服务器的错误字串回复。这些错误字串会以三种形式出现：  
\- “ERROR/r/n”  
意味着客户端发送了不存在的命令名称。  
\- “CLIENT\_ERROR <error>/r/n”  
意味着输入的命令行里存在一些客户端错误，例如输入未遵循协议。<error>部分是人类易于理解的错误解说……  
\- “SERVER\_ERROR <error>/r/n”  
意味着一些服务器错误，导致命令无法执行。<error>部分是人类易于理解的错误解说。在一些严重的情形下（通常应该不会遇到），服务器将在发送这行错误后关闭连接。这是服务器主动关闭连接的唯一情况。  
在后面每项命令的描述中，这些错误行不会再特别提到，但是客户端必须考虑到这些它们存在的可能性。

**存储命令**  
首先，客户端会发送一行像这样的命令：  
<command name> <key> <flags> <exptime> <bytes>/r/n  
\- <command name> 是 set, add, 或者 repalce

*  set 意思是 “储存此数据”
 *  add 意思是 “储存此数据，只在服务器\*未\*保留此键值的数据时”
 *  replace意思是 “储存此数据，只在服务器\*曾\*保留此键值的数据时”

\- <key> 是接下来的客户端所要求储存的数据的键值  
\- <flags> 是在取回内容时，与数据和发送块一同保存服务器上的任意16位无符号整形（用十进制来书写）。客户端可以用它作为“位域”来存储一些特定的信息；它对服务器是不透明的。  
\- <exptime> 是终止时间。如果为0，该项永不过期(虽然它可能被删除，以便为其他缓存项目腾出位置)。如果非0（Unix时间戳或当前时刻的秒偏移），到达终止时间后，客户端无法再获得这项内容。  
\- <bytes> 是随后的数据区块的字节长度，不包括用于分野的“/r/n”。它可以是0（这时后面跟随一个空的数据区块）。

在这一行以后，客户端发送数据区块。  
<data block>/r/n  
\- <data block> 是大段的8位数据，其长度由前面的命令行中的<bytes>指定。

发送命令行和数据区块以后，客户端等待回复，可能的回复如下：  
\- “STORED/r/n”  
表明成功.  
\- “NOT\_STORED/r/n”  
表明数据没有被存储，但不是因为发生错误。这通常意味着add 或 replace命令的条件不成立，或者，项目已经位列删除队列（参考后文的“delete”命令）。

**取回命令**  
一行取回命令如下：  
get <key>\*/r/n  
\- <key>\* 表示一个或多个键值，由空格隔开的字串  
这行命令以后，客户端的等待0个或多个项目，每项都会收到一行文本，然后跟着数据区块。所有项目传送完毕后，服务器发送以下字串：  
“END/r/n”  
来指示回应完毕。  
服务器用以下形式发送每项内容：  
VALUE <key> <flags> <bytes>/r/n  
<data block>/r/n  
\- <key> 是所发送的键名  
\- <flags> 是存储命令所设置的记号  
\- <bytes> 是随后数据块的长度，\*不包括\* 它的界定符“/r/n”  
\- <data block> 是发送的数据

如果在取回请求中发送了一些键名，而服务器没有送回项目列表，这意味着服务器没这些键名（可能因为它们从未被存储，或者为给其他内容腾出空间而被删除，或者到期，或者被已客户端删除）。

**删除**  
命令“delete”允许从外部删除内容：  
delete <key> <time>/r/n  
\- <key> 是客户端希望服务器删除的内容的键名  
\- <time> 是一个单位为秒的时间（或代表直到某一刻的Unix时间），在该时间内服务器会拒绝对于此键名的“add”和“replace”命令。此时内容被放入delete队列，无法再通过“get”得到该内容，也无法是用“add”和“replace”命令（但是“set”命令可用）。直到指定时间，这些内容被最终从服务器的内存中彻底清除。  
<time>参数 是可选的，缺省为0（表示内容会立刻清除，并且随后的存储命令均可用）。  
此命令有一行回应：  
\- “DELETED/r/n”  
表示执行成功  
\- “NOT\_FOUND/r/n”  
表示没有找到这项内容

参考随后的“flush\_all”命令使所有内容无效

**增加/减少**  
命令 “incr” 和 “decr”被用来修改数据，当一些内容需要 替换、增加 或减少时。这些数据必须是十进制的32位无符号整新。如果不是，则当作0来处理。修改的内容必须存在，当使用“incr”/“decr”命令修改不存在的内容时，不会被当作0处理，而是操作失败。

客户端发送命令行：  
incr <key> <value>/r/n  
或  
decr <key> <value>/r/n  
\- <key> 是客户端希望修改的内容的建名  
\- <value> 是客户端要增加/减少的总数。

回复为以下集中情形：  
\- “NOT\_FOUND/r/n”  
指示该项内容的值，不存在。  
\- <value>/r/n ，<value>是 增加/减少 。  
注意”decr”命令发生下溢：如果客户端尝试减少的结果小于0时，结果会是0。”incr” 命令不会发生溢出。

**状态**  
命令”stats” 被用于查询服务器的运行状态和其他内部数据。有两种格式。不带参数的：  
stats/r/n  
这会在随后输出各项状态、设定值和文档。另一种格式带有一些参数：  
stats <args>/r/n  
通过<args>，服务器传回各种内部数据。因为随时可能发生变动，本文不提供参数的种类及其传回数据。

**各种状态**  
受到无参数的”stats”命令后，服务器发送多行内容，如下：  
STAT <name> <value>/r/n  
服务器用以下一行来终止这个清单：  
END/r/n  
在每行状态中，<name> 是状态的名字，<value> 使状态的数据。 以下清单，是所有的状态名称，数据类型，和数据代表的含义。  
在“类型”一列中，”32u”表示32位无符号整型，”64u”表示64位无符号整型，”32u:32u”表示用冒号隔开的两个32位无符号整型。

<table style="width: 94%;"> 
 <tbody> 
  <tr> 
   <td align="center"><strong>名称</strong></td> 
   <td align="center"><strong>类型</strong></td> 
   <td colspan="2" align="center"><strong>含义</strong></td> 
  </tr> 
  <tr> 
   <td>pid</td> 
   <td>32u</td> 
   <td>服务器进程ID</td> 
  </tr> 
  <tr> 
   <td>uptime</td> 
   <td>32u</td> 
   <td>服务器运行时间，单位秒</td> 
  </tr> 
  <tr> 
   <td>time</td> 
   <td>32u</td> 
   <td>服务器当前的UNIX时间</td> 
  </tr> 
  <tr> 
   <td>version</td> 
   <td>string</td> 
   <td>服务器的版本号</td> 
  </tr> 
  <tr> 
   <td>rusage_user</td> 
   <td>32u:32u</td> 
   <td>该进程累计的用户时间<br>(秒:微妙)</td> 
  </tr> 
  <tr> 
   <td>rusage_system</td> 
   <td>32u:32u</td> 
   <td>该进程累计的系统时间<br>(秒:微妙)</td> 
  </tr> 
  <tr> 
   <td>curr_items</td> 
   <td>32u</td> 
   <td>服务器当前存储的内容数量</td> 
  </tr> 
  <tr> 
   <td>total_items</td> 
   <td>32u</td> 
   <td>服务器启动以来存储过的内容总数</td> 
  </tr> 
  <tr> 
   <td>bytes</td> 
   <td>64u</td> 
   <td>服务器当前存储内容所占用的字节数</td> 
  </tr> 
  <tr> 
   <td>curr_connections</td> 
   <td>32u</td> 
   <td>连接数量</td> 
  </tr> 
  <tr> 
   <td>total_connections</td> 
   <td>32u</td> 
   <td>服务器运行以来接受的连接总数</td> 
  </tr> 
  <tr> 
   <td>connection_structures</td> 
   <td>32u</td> 
   <td>服务器分配的连接结构的数量</td> 
  </tr> 
  <tr> 
   <td>cmd_get</td> 
   <td>32u</td> 
   <td>取回请求总数</td> 
  </tr> 
  <tr> 
   <td>cmd_set</td> 
   <td>32u</td> 
   <td>存储请求总数</td> 
  </tr> 
  <tr> 
   <td>get_hits</td> 
   <td>32u</td> 
   <td>请求成功的总次数</td> 
  </tr> 
  <tr> 
   <td>get_misses</td> 
   <td>32u</td> 
   <td>请求失败的总次数</td> 
  </tr> 
  <tr> 
   <td>bytes_read</td> 
   <td>64u</td> 
   <td>服务器从网络读取到的总字节数</td> 
  </tr> 
  <tr> 
   <td>bytes_written</td> 
   <td>64u</td> 
   <td>服务器向网络发送的总字节数</td> 
  </tr> 
  <tr> 
   <td>limit_maxbytes</td> 
   <td>32u</td> 
   <td>服务器在存储时被允许使用的字节总数</td> 
  </tr> 
 </tbody> 
</table>

**其它命令**  
“flush\_all”命令有一个可选的数字参数。它总是执行成功，服务器会发送“OK/r/n”回应。它的效果是使已经存在的项目立即失效（缺省），或在指定的时间后。此后执行取回命令，将不会有任何内容返回（除非重新存储同样的键名）。flush\_all 实际上没有立即释放项目所占用的内存，而是在随后陆续有新的项目被储存时执行。flush\_all 效果具体如下：它导致所有更新时间早于flush\_all所设定时间的项目，在被执行取回命令时命令被忽略。  
“version”命令没有参数：  
version/r/n  
在回应中，服务器发送：  
“VERSION <version>/r/n”  
<version> 是服务器的版本字串。  
“quit”命令没有参数：  
quit/r/n  
接收此命令后，服务器关闭连接。不过，客户端可以在不再需要时，简单地关闭连接就行，并不一定需要发送这个命令。

**UDP 协议**  
当来自客户端的连接数远大于TCP连接的上限时，可以使用基于UDP的接口。UDP接口不能保证传输到位，所以只有在不要求成功的操作中使用；比如被用于一个“get”请求时，会因不当的缓存处理而发生错误或回应有遗失。

每个UDP数据包都包含一个简单的帧头，数据之后的内容与TCP协议的描述类似。在执行所产生的数据流中，请求必须被包含在单独的一个UDP数据包中，但是回应可能跨越多个数据包。（只有“get”和“set”请求例外，跨越了多个数据包）

帧头有8字节长，如下（均由16位整数组成，网络字节顺序，高位在前）：

*  0-1 请求ID
 *  2-3 序号
 *  4-5 该信息的数据包总数
 *  6-7 保留位，必须为0

请求ID有客户端提供。一般它会是一个从随机基数开始的递增值，不过客户端想用什么样的请求ID都可以。服务器的回应会包含一个和请求中的同样的ID。客户端使用请求ID来区分每一个回应。任何一个没有请求ID的数据包，可能是之前的请求遭到延迟而造成的，应该被丢弃。序号的返回是从0到n-1，n是该条信息的数据包数量。

2.  针对协议的一个简单实现  
       在这个例子中简单实现了一个能进行update/get/delete操作测试用例,只是简单socket的应用而已.如果可以,模仿这个写一个简单的客户端应该难度不大.

引用

/\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*/  
\*            mem\_benchmark\_conn2.c  
\*  
\*  Mon Mar 7 10:52:30 2007  
\*  Copyright  2007  Spark Zheng  
\*  Mail  
\*  v0.1 Mar 5 2007 file:mem\_benchmark\_conn.c  
/\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*/  
  
\#include < stdio.h>  
\#include < stdlib.h>  
\#include < string.h>  
\#include < ctype.h>  
  
\#include < unistd.h>  
\#include < pthread.h>  
\#include < time.h>  
\#include < sys/types.h>  
\#include < sys/time.h>  
\#include < sys/resource.h>  
//\#include < sys/socket.h>  
//\#include < netdb.h>  
//\#include < arpa/inet.h>  
  
\#ifndef MEM\_SERVER  
\#define MEM\_SERVER "10.210.71.25"  
\#endif  
  
\#ifndef MEM\_PORT  
\#define MEM\_PORT 11211  
\#endif  
  
void p\_usage(void);  
void \*conn\_mem(void);  
int NonbSocket(const char \*server, int port);  
int mem\_set(int sock,const char \*key,const char \*value);  
int mem\_add(int sock,const char \*key,const char \*value);  
int mem\_get(int sock,const char \*key,char \*value);  
int mem\_del(int sock,const char \*key);  
  
int main(int argc,char \*\*argv)  
\{  
       int conn=0;  
       int i=0;  
       pthread\_t ptid\[10000\];  
       struct rlimit rlim;  
       struct timeval tv1,tv2;  
  
       if(argc < 2)  
       \{  
               p\_usage();  
               exit(255);  
       \}  
  
       conn = atoi(argv\[1\]);  
  
       if(getrlimit(RLIMIT\_NOFILE,&rlim) != 0)  
       \{  
               fprintf(stderr,"getrlimit error in line %d/n",\_\_LINE\_\_);  
               exit(254);  
       \}  
  
       if((conn > rlim.rlim\_cur) && (2\*conn > 1024))  
       \{  
               rlim.rlim\_cur = 2\*conn;  
       \}  
       if(rlim.rlim\_cur > rlim.rlim\_max)  
       \{  
               rlim.rlim\_max = rlim.rlim\_cur;  
       \}  
  
       if(setrlimit(RLIMIT\_NOFILE,&rlim) != 0)  
       \{  
               fprintf(stderr,"setrlimit error in line %d/n",\_\_LINE\_\_);  
               exit(254);  
       \}  
  
       gettimeofday(&tv1,NULL);  
  
       while(i++ < conn)  
       \{  
               if(pthread\_create(&ptid\[i\],NULL,(void \*)conn\_mem,NULL) != 0)  
               \{  
                       perror("pthread\_create error/n");  
                       exit(253);  
               \}  
       \}  
  
       i=0;  
  
       while(i++ < conn)  
       \{  
               if(pthread\_join(ptid\[i\],NULL) != 0)  
               \{  
                       perror("pthread\_join error/n");  
                       exit(253);  
               \}  
       \}  
  
       gettimeofday(&tv2,NULL);  
  
       printf("time is %f,conn is %f persecond/n",((tv2.tv\_sec-tv1.tv\_sec)+(tv2.tv\_usec-tv1.tv\_usec)/1000000.0),conn/((tv2.tv\_sec-tv1.tv\_sec)+(tv2.tv\_usec-tv1.tv\_usec)/1000000.0));  
  
       return 0;  
\}  
  
void p\_usage(void)  
\{  
       printf("Usage:./mem\_benchmark\_conn < conn\_num >/n");  
       printf("Notice: the conn\_num must <= 10000/n");  
       return;  
\}  
  
void \*conn\_mem(void)  
\{  
       int sock;  
       char \*key = "test\_a";  
       char \*value = "this is a";  
  
       if((sock=NonbSocket(MEM\_SERVER,MEM\_PORT)) < 0)  
       \{  
               fprintf(stderr,"socket error in line %d/n",\_\_LINE\_\_);  
               return NULL;  
       \}  
  
int i=0;  
while(i++ < 10)  
\{  
///\*  
       mem\_set(sock,key,value);  
//\*/  
/\*  
       char \*key2="test\_b";  
       char \*value2="this is b";  
       mem\_add(sock,key2,value2);  
\*/  
/\*  
       char buf\[101\];  
       mem\_get(sock,key,buf);  
       printf("get value for %s is %s/n",key,buf);  
\*/  
/\*  
       char \*key3="test\_c";  
       mem\_del(sock,key);  
\*/  
\}  
       close(sock);  
  
       return NULL;  
\}  
  
int mem\_set(int sock,const char \*key,const char \*value)  
\{  
       char set\[101\];  
       char recv\_buf\[101\];  
  
       sprintf(set,"set %s 0 0 %d/r/n%s/r/n",key,strlen(value),value);  
  
       if(write(sock,set,strlen(set)) < 0)  
       \{  
               fprintf(stderr,"write error in line %d/n",\_\_LINE\_\_);  
               return -1;  
       \}  
  
       if(read(sock,recv\_buf,100) < 0)  
       \{  
               fprintf(stderr,"read error in line %d/n",\_\_LINE\_\_);  
               return -2;  
       \}  
  
       printf("in set %s/n",recv\_buf);  
  
       return 0;  
\}  
  
int mem\_add(int sock,const char \*key,const char \*value)  
\{  
       char add\[101\];  
       char recv\_buf\[101\];  
  
       sprintf(add,"add %s 0 0 %d/r/n%s/r/n",key,strlen(value),value);  
  
       if(write(sock,add,strlen(add)) < 0)  
       \{  
               fprintf(stderr,"write error in line %d/n",\_\_LINE\_\_);  
               return -1;  
       \}  
  
       if(read(sock,recv\_buf,100) < 0)  
       \{  
               fprintf(stderr,"read error in line %d/n",\_\_LINE\_\_);  
               return -2;  
       \}  
  
       printf("in add %s/n",recv\_buf);  
  
       return 0;  
\}  
  
int mem\_get(int sock,const char \*key,char \*value)  
\{  
       char get\[101\];  
       char recv\_buf\[101\];  
  
       sprintf(get,"get %s/r/n",key);  
  
       if(write(sock,get,strlen(get)) < 0)  
       \{  
               fprintf(stderr,"write error in line %d/n",\_\_LINE\_\_);  
               return -1;  
       \}  
  
       if(read(sock,recv\_buf,100) < 0)  
       \{  
               fprintf(stderr,"read error in line %d/n",\_\_LINE\_\_);  
               return -2;  
       \}  
  
       strncpy(value,recv\_buf,strlen(recv\_buf));  
  
       printf("in get %s/n",recv\_buf);  
  
       return 0;  
\}  
  
int mem\_del(int sock,const char \*key)  
\{  
       char del\[101\];  
       char recv\_buf\[101\];  
  
       sprintf(del,"delete %s 0/r/n",key);  
  
       if(write(sock,del,strlen(del)) < 0)  
       \{  
               fprintf(stderr,"write error in line %d/n",\_\_LINE\_\_);  
               return -1;  
       \}  
  
       if(read(sock,recv\_buf,100) < 0)  
       \{  
               fprintf(stderr,"read error in line %d/n",\_\_LINE\_\_);  
               return -2;  
       \}  
  
       printf("in del %s/n",recv\_buf);  
  
       return 0;  
\}

3.  分布式的实现  
       分布式的实现可以这么完成,构建一个struct用于存放server信息.对于每个请求的key值,用很简单的hash算法(如libmemcache用的是crc32)映射到server数组中的某个数组,然后对其进行通信.获取处理结果之后,将结果美化返回client.  
  
6.[libevent][]简介  
       1.  libevent  
       libevent是一个事件触发的网络库,适用于windows,linux,bsd等多种平台,内部使用iopc/epoll/kqueue等系统调用管理事件机制,而且根据libevent官方网站上公布的数据统计,似乎也有着非凡的性能.  
       从代码中看,libevent支持用户使用三种类型的事件,分别是网络IO,定时器,信号三种,在定时器的实现上使用了红黑树(RB tree)的数据结构,以达到高效查找,排序,删除定时器的目的,网络IO上,libevent的epoll居然用的EPOLLLT水平触发的方式,不容易出错,但是在效率上可能比EPOLLET要低一些.跟网络无关的,libevent也有一些缓冲区管理的函数,libevent没有提供缓存的函数.而且libevent的接口形式非常值得参考.  
       2.  epoll  
在linux中,libevent用的是epoll.如果有兴趣的话,可以查看man epoll页面.或者看前面blog上引用的libevent的资源.

[memcache_f1.jpg]: http://wf.xplore.cn/pics/memcache_f1.jpg
[memcache_f2.jpg]: http://wf.xplore.cn/pics/memcache_f2.jpg
[memcache_f3.jpg]: http://wf.xplore.cn/pics/memcache_f3.jpg
[http_burtleburtle.net_bob_hash_evahash.html]: http://burtleburtle.net/bob/hash/evahash.html
[memcache_w1.jpg]: http://wf.xplore.cn/pics/memcache_w1.jpg
[memcache_t1.jpg]: http://wf.xplore.cn/pics/memcache_t1.jpg
[memcache_t2.jpg]: http://wf.xplore.cn/pics/memcache_t2.jpg
[memcache_t3.jpg]: http://wf.xplore.cn/pics/memcache_t3.jpg
[memcache]: http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt
[libevent]: http://www.monkey.org/~provos/libevent/