简介
前面讲到了memcached的文本协议，虽然文本协议看起来非常简单,但是对于客户端来说一般还是会选择效率更高的二进制协议。
二进制协议的本质和文本协议是一样的，只是他们的表现方式不同而已。本文将会详细介绍memcached中二进制协议的实现细节。
memcached的协议包
对于memcached的请求包和响应包来说，除了请求头有所区别之外，其他的格式都是一样的。
所以对memcached的请求和响应都可以用同一个包的格式来表示:
前面的24个byte是包头部分，接下来的是命令行的额外数据extra,memcached中的key和value。
上面也提到了，请求包和响应包的区别就是header,下面是请求包头和响应包头的定义：
请求包头：
响应包头：
包头中各个字段的含义如下：
- Magic: 魔法数字，用来区分包头是请求包头还是响应包头
如果是请求,那么对应的Magic= 0x80，如果是响应,那么对应的Magic= 0x81。
在最初的设计中，Magic应该和协议的版本相对应的，当版本升级之后，对应的Magic也要进行相应的调整。但是到目前为止，binary协议的magic值还没有变化过。
- Opcode: 操作符，也就是对应的命令
memcached协议中有下面这些操作符：
其中带星号的表示该命令未定，未来可能会有修改。
以Q结尾的命令，表示这个命令是一个quiet的版本，它会忽略不感兴趣的返回数据。
- Key length: key的长度
- Status: 请求响应response的状态
response的值有下面几种：
- Extras length: command extras的长度
- Data type:保留字段
data type是一个保留字段，目前只有一个固定的值：0x00。
- vbucket id: 命令对应的virtual bucket
- Total body length:extra key value的总长度
- Opaque: 请求生成的一个数据，会被原封不动在对应的响应中返回
- CAS:数据的一个唯一标记
memcached命令举例
为了更好的理解memcached的二进制协议，我们以几个常用的命令为例，来看一下memcached具体的请求和响应流程。
最常用的就是get请求，用于向服务器端请某个key对应的值。
假如现在客户端要向服务器端get一个key=hello的数据，那么请求的包如下所示：
其中Magic=0x80, Opcode=0x00,Key length=0x0005,Total body=0x00000005,Key=”Hello”
如果服务器端存在对应的key的值，那么将会返回如下的数据包：
我们要注意下面几个跟request值不同的字段：
其中Magic=0x81表示这个是一个response, 因为这是一个response,所以对应的Key length=0x0000。
另外response中包含了get请求中并不存在的Extra length和Extras Flags,这里他们的值分别是0x04和0xdeadbeef，表示Extra length是4个bytes，它的值是0xdeadbeef。
那么这个Extras Flags值是哪里来的呢？如果对比之前讲到的text协议，就可以知道，Extras Flags是在set key value的时候传入的，这个Flags会存放到服务器端，并在get请求中返回。
最后，response中包含了要返回的值”World”。
如果服务器端并没有这个key的值，那么对应的返回包可能是这样的：
其中Status=0x0001，表示是一个异常返回。
对应的value是：”Not found”。
之前还提到了一个以Q结尾的命令行版本，比如getQ，它和get的区别是getQ会把请求的key也放在response包中返回：
因为最后的值中包含了key，所以这里的Key length是有值的，他就是key的长度=0x0005。
最后的返回数据部分包含了两部分，分别是Key=”Hello”,value=”World”。
总结
以上我们介绍了memcached二进制协议的基本格式，并举例说明了get请求的具体使用和包的内容。有了这些知识，我们就可以开发一个支持memcached二净值协议的客户端了。
更多内容请参考 http://www.flydean.com/24-memcached-binary-protocol/
