memcache是一种和redis类似的高速缓存服务器,但是memcache只提供键值对这种简单的存储方式,相对于redis支持的存储方式多样化,memcache就比较简单了。memcache通过tcp或者udp连接来实现memcache客户端和服务端的交互。memcache的协议是自定的,也分为两种:一种是文本协议(这是我们今天讨论的重点),另一种是二进制协议(在我们今天讨论的范围),这里仅仅介绍用tcp连接以及文本协议通信的memcache协议。如有描述不当的地方请大家指出。

memcache文本协议

存储命令

add/replace/set/append/prepend命令格式如下:

<command name> <key> <flags> <exptime> <bytes>\r\n

<data block>\r\n

格式的介绍如下:

<command name>可以是add(即增加不存在的键值对),replace(即替换存在的键值对),set(上述两种的功能都具有),append(在存在的键对应的值后增加对应的内容)以及prepend(在存在的键对应的值之前增加对应的内容)。

<key> 是数据项的键名。

<flags>是在取回内容时,与数据和发送块一同保存服务器上的任意16位无符号整形(用十进制来书写),一般为0。

<exptime> 是有效时间。如果为0,该项永不过期,如果非0,该项将在<exptime> 后删除。

<bytes>是<data block>的长度,是数据项的长度。

<data block>是数据项的数据。

add/replace/set/append/prepend命令回复

"STORED\r\n"表明存储成功。

"NOT_STORED\r\n"表明数据没有被存储,但不是因为发生错误。这通常意味着add , replace的条件不满足或者项目已经位列删除队列(参考后文的“delete”命令)。

cas命令格式如下:

cas <key> <flags> <exptime> <bytes> <cas unique> [noreply]\r\n

<data block>\r\n

<key> ,<flags>,<exptime>, <bytes>以及<data block>同add/replace/set/append/prepend命令

<cas unique> 是一个与已存数据条目相关的全局唯一的64位数。客户端应该使用"gets"命令返回的该值来进行"cas"更新操作。

[noreply]是可选项指示不要回复。注意:如果请求行格式错误,服务器不一定能可靠地解析"noreply"选项。在此种情况下,它可能会发送错误信息给客户端,如果客户端没有读取该信息的话会带来问题。客户端应该只构造合法的请求。

cas命令回复如下:

"EXIST\r\n" 指示要更新的数据自你上次取过后已经过修改。

"NO_FOUND\r\n" 指示要修改的数据并不存在。

delete格式命令如下:

delete <key> <time>\r\n

delete是删除对应的键名。

<key> 是需要删除的键名。

<time>是一个单位为秒的时间,在该时间内服务器会拒绝对于此键名的“add”和“replace”命令。此时内容被放入delete队列,无法再通过“get”得到该内容,也无法是用“add”和“replace”命令(但是“set”命令可用)。直到指定时间,这些内容被最终从服务器的内存中彻底清除。

delete命令回复如下:

"DELETED\r\n"表示执行成功

"NOT_FOUND\r\n"表示没有找到这项内容

读取命令

get/gets命令格式如下:

get/gets <key>*\r\n

<key>*指的是多个以空格分割的键名。

get/gets命令回复如下:

VALUE <key> <flags> <bytes> [<cas unique>]\r\n

<data block>\r\n

<key>是数据项的键名

<flags>是由存储命令设置的flags,一般为0

<bytes>是数据块的长度

<cas unique>是一个64位整数,唯一标识了一个特定的数据项。

<data block>是数据项的数据。

这里的所有数据以"END"结束。

incr/desc命令格式如下:

incr/desc <key> <value> [noreply]\r\n

<key>是数据项的键名

<value>是对数据项incr(递增)/desc(递减)的值。它是一个64位的无符号十进制整数。

[norply]是可选参数,不要回复。

incr/desc命令回复:

"NOT_FOUND\r\n" 指示这个数据项找不到。

"<value>\r\n", 其中<value>是这个数据项在经过递增/递减操作后的新值。

memcache文本协议的请求的解析

这个是在proto/memcache.c里的memcache_parse_req函数

它也是用有限状态机去完成解析的

     enum {
SW_START,
SW_REQ_TYPE,
SW_SPACES_BEFORE_KEY,
SW_KEY,
SW_SPACES_BEFORE_KEYS,
SW_SPACES_BEFORE_FLAGS,
SW_FLAGS,
SW_SPACES_BEFORE_EXPIRY,
SW_EXPIRY,
SW_SPACES_BEFORE_VLEN,
SW_VLEN,
SW_SPACES_BEFORE_CAS,
SW_CAS,
SW_RUNTO_VAL,
SW_VAL,
SW_SPACES_BEFORE_NUM,
SW_NUM,
SW_RUNTO_CRLF,
SW_CRLF,
SW_NOREPLY,
SW_AFTER_NOREPLY,
SW_ALMOST_DONE,
SW_SENTINEL
} state;

这里的有限状态机图如下:

storage就是存储命令,即add/replace/set/append/prepend/cas命令,retreval就是读取命令,即get\gets命令,other就是除了存储命令,get\gets命令,touch命令,incr/desc命令之外的命令。

例如get\gets命令,先是SW_REQ_TYPE,就是get\gets字符串,再是SW_SPACES_BEFORE_KEY,即空格,然后使SW_KEY,就是键名,接着回到SW_SPACES_BEFORE_KEY,不断往复。

memcache文本协议的回复的解析

这个是在proto/memcache.c里的memcache_parse_rsp函数

它也是用有限状态机去完成解析的,下面是这些状态。

    enum {
SW_START,
SW_RSP_NUM,
SW_RSP_STR,
SW_SPACES_BEFORE_KEY,
SW_KEY,
SW_SPACES_BEFORE_FLAGS, /* 5 */
SW_FLAGS,
SW_SPACES_BEFORE_VLEN,
SW_VLEN,
SW_RUNTO_VAL,
SW_VAL, /* 10 */
SW_VAL_LF,
SW_END,
SW_RUNTO_CRLF,
SW_CRLF,
SW_ALMOST_DONE, /* 15 */
SW_SENTINEL
} state; 

这里的有限状态机图如下:

例如,如果是get和gets的回复就会先进入SW_RSP_STR,即“VALUE”,接着进入SW_SPACES_BEFOER_KEY这条线,知道这行的结束SW_RUNTO_CRLF,然后进入数据块SW_RUNTO_VAL这条线,知道SW_RSP_STR,直至到SW_RSP_STR中解析出“END”,会到SW_CRLF这条线。

总结

本文主要介绍了memcache的文本协议以及tweproxy如何解析memcache请求包和memcache回复包。

twemproxyMemcache协议解析探索——剖析twemproxy代码正编补充的更多相关文章

  1. twemproxyRedis协议解析探索——剖析twemproxy代码正编

    这篇文章会对twemproxyRedis协议解析代码部分进行一番简单的分析,同时给出twemproxy目前支持的所有Redis命令.在这篇文章开始前,我想大家去简单地理解一下有限状态机,当然不理解也是 ...

  2. twemproxy发送流程探索——剖析twemproxy代码正编

    本文想要完成对twemproxy发送流程--msg_send的探索,对于twemproxy发送流程的数据结构已经在<twemproxy接收流程探索--剖析twemproxy代码正编>介绍过 ...

  3. twemproxy接收流程探索——剖析twemproxy代码正编

    本文旨在帮助大家探索出twemproxy接收流程的代码逻辑框架,有些具体的实现需要我们在未来抽空去探索或者大家自行探索.在这篇文章开始前,大家要做好一个小小的心理准备,由于twemproxy代码是一份 ...

  4. twemproxy代理主干流程——剖析twemproxy代码正编

    在twemproxy的发送和接收流程剖析中,我们已经完全弄清楚twemproxy如何将客户端以及服务端发来的包切分成msg,获得一个独立的msg后twemproxy应该如何处理?这是本文这次需要重点介 ...

  5. twemproxy分片处理原理--剖析twemproxy代码正编

    twemproxy在redis上能处理多命令流程只有mset,mget,del的命令,例如mset的话是mset k1 v1 k2 v2 k3 k3,mget的话是mget k1 k2 k3,del的 ...

  6. twemproxy代码框架概述——剖析twemproxy代码前编

    本篇将去探索twemproxy源码的主干流程,想来对于想要开始啃这份优秀源码生肉的童鞋会有不小的帮助.这里我们首先要找到 twemproxy正确的打开方式--twemproxy的文件结构,接着介绍tw ...

  7. twemproxy架构分析——剖析twemproxy代码前编

    twemproxy背景 在业务量剧增的今天,单台高速缓存服务器已经无法满足业务的需求, 而相较于大容量SSD数据存储方案,缓存具备速度和成本优势,但也存在数据安全性的挑战.为此搭建一个高速缓存服务器集 ...

  8. twemproxy接收流程探索——twemproxy代码分析正编

    在这篇文章开始前,大家要做好一个小小的心理准备,由于twemproxy代码是一份优秀的c语言,为此,在twemproxy的代码中会大篇幅使用c指针.但是不论是普通类型的指针还是函数指针,都可以让我们这 ...

  9. 剖析twemproxy前言

    又是喜闻乐见的新坑,前面的mysql协议,当我在解读go-mysql包的时候,会重新讲到,至于Leetcode的更新会与go语言同步.关于这个redis的新坑,目前打算通过剖析twemproxy源码来 ...

随机推荐

  1. Java 多线程详解(四)------生产者和消费者

    Java 多线程详解(一)------概念的引入:http://www.cnblogs.com/ysocean/p/6882988.html Java 多线程详解(二)------如何创建进程和线程: ...

  2. Linux 常 用 命 令

    一:关机命令 1:shutdown 语 法:shutdown [-efFhknr][-t 秒数][时间][警告信息] 说明:shutdown指令可以关闭所有程序,并依用户的需要,进行重新开机或关机的动 ...

  3. 第 15 章 可扩展性设计之 Cache 与 Search 的利用

    前言: 前面章节部分所分析的可扩展架构方案,基本上都是围绕在数据库自身来进行的,这样是否会使我们在寻求扩展性之路的思维受到“禁锢”,无法更为宽广的发散开来.这一章,我们就将跳出完全依靠数据库自身来改善 ...

  4. 汽车Vin码识别——可以嵌入到手机里的新OCR识别技术

              汽车Vin码识别(车架号识别),顾名思义,就是识别汽车的Vin码(车架号),汽车Vin码识别(车架号识别)利用的是OCR识别技术,支持视频流获取图像,自动触发识别,另外汽车Vin码 ...

  5. VR全景智慧城市—你的掌上步行街

    "春风十里,不如有你",不知不觉间,身边的人已对VR不再陌生,VR眼镜的热销,VR体验店的火爆,VR游戏的向往等等.可见VR就是为生活而诞生! 2015年被称作VR行业的产业元年, ...

  6. vmware和centOS的安装

    如果勾上了,会立即在本机开辟20g的空间,需要很长时间 选择电脑中ISO镜像的位置,之后点击开启虚拟机! 这个密码是root用户的密码!管理员密码! 可以选择我们的Minimal没有界面的!

  7. php处理表单中的复选框问题以及js实现全选

    做的一个项目中遇到了全选和取消全选的问题,这是一个很普遍的功能,,虽然我们经常用到,但是真正做起来却发现行不通,在网上找了些,大部分都是ie,但是谷歌内核浏览器不能正常实现,所以经过小小的调整,今天就 ...

  8. php curl 的几个实例

    使用PHP的cURL库可以简单和有效地去抓网页.你只需要运行一个脚本,然后分析一下你所抓取的网页,然后就可以以程序的方式得到你想要的数据了.无论是你想从从一个链接上取部分数据,或是取一个XML文件并把 ...

  9. iOS项目评估报告

    1.整体项目无分层概念,结构混乱,代码耦合严重. 影响:后期扩展困难,维护困难. 解决方案:1.整体采用mvc模式. 2.在原来的基础再抽离出业务层 3.业务层按模块管理,合理分层分包. 4.做好共用 ...

  10. c++ 库函数返回的字符串指针是否需要手动释放

    #include <stdio.h> char * tmpnam(char *s); tmpnam函数返回一个不与任何已存在文件同名的有效文件名,如果字符串s不为空,文件名也会写入它.对t ...