redis server与client通信协议介绍

今天在整理以前开发相关时的一些资料，其中对于redis protocol的解析有些小记录，记录在此：

一.reidis client-server协议是有如下特点

1.实现简单

2.能够被计算机快速解析。

3.使用者也容易理解

二.通信

client与redis server建立TCP连接，每个命令与数据传送最后都以\r\n结尾。

Redis跟据不同的命令进行不同的回复。redis server回复的内容类型通过第一个参数可以判断：

1."+"号开头表示单行字符串的回复 如:+OK

2."-"号开头表示错误的信息回复。 如:-wrong date type

3.":"号开头表示一个整数回复。 如":0\r\n"

4."$"号开头表示一个批量的回复。 如GET mykey 返回$6\r\nfoobar\r\n 其中6为字节数，foobar为实现的字符串数据。

5."*"号开头表示多个批量回复。

批量回复

对于$得到单个批量的回复,如果请求不存在数据块，返回$-1,这种情况对于客户端API返回的是null对象还不是空串.

多个批量回复

例如:

C: LRANGE mylist 0 3

s: *4

s: $3

s: foo

s: $3

s: bar

s: $5

s: Hello

s: $5

s: World

参上返回四个参数:

*4\r\n$3\r\nfoo\r\n$3\r\nbar\r\n$5\r\nHello\r\n$5\r\nWorld\r\n

对于LRANGE nokey0 1

返回*0,此情况说明key不存在，返回空的list,而对于命令超时异常时，此时返回*-1.

对于client发送给server端的指令也是跟以上相关组装指令的方式一样，相关指令的name被以String.encode序列化，传送到server，然后相应的解析。

从以上可以看到，redis的server与client通信协议相对而言很简单，相关client的编写其实也很简单。

三.谈谈zipmap与ziplist编码方式

对于redis中的hash结构会使用zipmap编码格式，而ziplist会采用ziplist编码格式，而其中主要通过

hash-max-zipmap-entries 64   hash-max-zipmap-value 512

与

list-max-ziplist-entries 64    list-max-ziplist-value 512 

以上两组参数控制，当结构的数量小于64，数据value值小于512时，可以采用一维数组的方式来存储相应的数据，而且一维数组采用了Varint编码方式，这样的话对于通用数据，会节省内存空间的开销。

在此值得说明的，以上参数是可以配制。

另外由于配制的参数不要过大，都是常数，所以在get操作时虽然是O(n)的开销，但也会很快。

对于Varint编码方式的在此简单介绍下：

Redis使用了跟protobuf一样的编码方式：Varint中的每个 byte 的最高位 bit 有特殊的含义，如果该位为 1，表示后续的 byte 也是该数字的一部分，如果该位为 0，则结束。其他的 7 个 bit 都用来表示数字。因此小于 128 的数字都可以用一个 byte表示。大于 128 的数字，比如 300，会用两个字节来表示：1010 1100 0000 0010。基于以上方式，可以节省ziplist与zipmap存储占用空间。（当然，在可配制下的存储数下，使用一维数组存储，才是这两种结构存储的关键，所以数据结构设计时需要考虑这些）

以上为通信协议的简单介绍，相关资料可以参考官网：（http://redis.io/topics/protocol）