redis怎么解决app与服务器通信

简介

几乎所有的主流编程语言都有Redis的客户端，不考虑Redis非常流行的原因，如果站在技术的角度看原因还有两个：

客户端与服务端之间的通信协议是在 TCP 协议之上构建的。

客户端和服务器通过 TCP 连接来进行数据交互， 服务器默认的端口号为 6379 。

客户端和服务器发送的命令或数据一律以 \r\n （CRLF）结尾。

Redis制定了 RESP（REdis Serialization Protocol，Redis序列化协议）实现客户端与服务端的正常交互，这种协议简单高效，既能够被机器解析，又容易被人类识别。

发送命令

RESP 在 Redis 1.2 版本中引入谨慧歼， 并最终在 Redis 2.0 版本成为 Redis 服务器通信的标准方式。

在这个协议中， 所有发送至 Redis 服务器的祥冲参数都是二进制安全（binary safe）的。

RESP 的规定一条命令的格式如下：

*<参数数量>CR LF

$<参数 1 的字节数量>CR LF

<参数 1 的数据>CR LF

...

$<参数 N 的字节数量>CR LF

<参数 N 的数据>CR LF

命令本身也作为协议的其中一个参数来发送。

例如我们经常执行的 SET 命令，在命令行中我们输入如下：

SET key value

使用 RESP 协议规定的格式：

*3

$3

SET

$3 # 这里 key 一共三个字节

key

$5 # 这里 value 一共五个字节

value

这个命令的实际协议值如下：

"*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n"

回复

Redis 命令会返回多种不同类型的回复。

通过检查服务器发回数据的第一个字节， 可以确定这个回复是什么类型：

状态回复（status reply）的第一个字节是 "+"

错误回复（error reply）的第一个字节是 "-"

整数回复（integer reply）的第一个字节是 ":"

批量回复（bulk reply）的第一个字节是 "$"

多条批量回复（multi bulk reply）的第一个字节是 "*"

我们知道redis-cli只能看到最终的执行结果，那是因为redis-cli本身就按照RESP进行结果解析的，所以看不到中间结果，redis-cli.c 源码对命令结果的解析结构如下：

static sds cliFormatReplyTTY(redisReply *r, char *prefix) {

   sds out = sdsempty()

switch (r->type) {

                // 处理错误回复

case REDIS_REPLY_ERROR:

out = sdscatprintf(out,"(error) %s\n", r->str)

break

// 处理状态回复

case REDIS_REPLY_STATUS:

out = sdscat(out,r->str)

out = sdscat(out,"\n")

break

// 处理整数回复

case REDIS_REPLY_INTEGER:

out = sdscatprintf(out,"(integer) %lld\n",r->integer)

break

// 处理字符串回复

case REDIS_REPLY_STRING:

/* If you are producing output for the standard output we want

* a more interesting output with quoted characters and so forth */

out = sdscatrepr(out,r->str,r->len)

out = sdscat(out,"\n")

break

// 处理 nil

case REDIS_REPLY_NIL:

out = sdscat(out,"(nil)\n")

break

// 处理多回复

case REDIS_REPLY_ARRAY:

if (r->碧早elements == 0) {

out = sdscat(out,"(empty list or set)\n")

} else {

unsigned int i, idxlen = 0

char _prefixlen[16]

char _prefixfmt[16]

sds _prefix

sds tmp

/* Calculate chars needed to represent the largest index */

i = r->elements

do {

idxlen++

i /= 10

} while(i)

/* Prefix for nested multi bulks should grow with idxlen+2 spaces */

memset(_prefixlen,' ',idxlen+2)

_prefixlen[idxlen+2] = '\0'

_prefix = sdscat(sdsnew(prefix),_prefixlen)

/* Setup prefix format for every entry */

   snprintf(_prefixfmt,sizeof(_prefixfmt),"%%s%%%ud) ",idxlen)

for (i = 0i <r->elementsi++) {

/* Don't use the prefix for the first element, as the parent

* caller already prepended the index number. */

out = sdscatprintf(out,_prefixfmt,i == 0 ? "" : prefix,i+1)

/* Format the multi bulk entry */

                        tmp = cliFormatReplyTTY(r->element[i],_prefix)

out = sdscatlen(out,tmp,sdslen(tmp))

sdsfree(tmp)

}

sdsfree(_prefix)

}

break

default:

fprintf(stderr,"Unknown reply type: %d\n", r->type)

exit(1)

}

return out

}

在 发送命令 一节中使用的格式除了用作命令请求协议之外， 也用在命令的回复协议中： 这种只有一个参数的回复格式被称为批量回复（Bulk Reply）。

统一协议请求原本是用在回复协议中， 用于将列表的多个项返回给客户端的， 这种回复格式被称为多条批量回复（Multi Bulk Reply）。

一个多条批量回复以 *<argc>\r\n 为前缀， 后跟多条不同的批量回复， 其中 argc 为这些批量回复的数量。

状态回复

一个状态回复（或者单行回复，single line reply）是一段以 "+" 开始、 "\r\n" 结尾的单行字符串。

以下是一个状态回复的例子：

  +OK

客户端库应该返回 "+" 号之后的所有内容。 比如在在上面的这个例子中， 客户端就应该返回字符串 "OK" 。

状态回复通常由那些不需要返回数据的命令返回，这种回复不是二进制安全的，它也不能包含新行。

状态回复的额外开销非常少，只需要三个字节（开头的 "+" 和结尾的 CRLF）。

错误回复

错误回复和状态回复非常相似， 它们之间的唯一区别是， 错误回复的第一个字节是 "-" ， 而状态回复的第一个字节是 "+" 。

错误回复只在某些地方出现问题时发送： 比如说， 当用户对不正确的数据类型执行命令， 或者执行一个不存在的命令， 等等。

一个客户端库应该在收到错误回复时产生一个异常。

以下是两个错误回复的例子：

  -ERR unknown command 'foobar'

                       -WRONGTYPE Operation against a key holding the wrong kind of value

在 "-" 之后，直到遇到第一个空格或新行为止，这中间的内容表示所返回错误的类型。

ERR 是一个通用错误，而 WRONGTYPE 则是一个更特定的错误。 一个客户端实现可以为不同类型的错误产生不同类型的异常， 或者提供一种通用的方式， 让调用者可以通过提供字符串形式的错误名来捕捉（trap）不同的错误。

不过这些特性用得并不多， 所以并不是特别重要， 一个受限的（limited）客户端可以通过简单地返回一个逻辑假（false）来表示一个通用的错误条件。

整数回复

整数回复就是一个以 ":" 开头， CRLF 结尾的字符串表示的整数。

比如说， ":0\r\n" 和 ":1000\r\n" 都是整数回复。

返回整数回复的其中两个命令是 INCR 和 LASTSAVE 。 被返回的整数没有什么特殊的含义， INCR 返回键的一个自增后的整数值， 而 LASTSAVE 则返回一个 UNIX 时间戳， 返回值的唯一限制是这些数必须能够用 64 位有符号整数表示。

整数回复也被广泛地用于表示逻辑真和逻辑假： 比如 EXISTS 和 SISMEMBER 都用返回值 1 表示真， 0 表示假。

其他一些命令， 比如 SADD 、 SREM 和 SETNX ， 只在 *** 作真正被执行了的时候， 才返回 1 ， 否则返回 0 。

以下命令都返回整数回复： SETNX 、 DEL 、 EXISTS 、 INCR 、 INCRBY 、 DECR 、 DECRBY 、 DBSIZE 、 LASTSAVE 、RENAMENX 、 MOVE 、 LLEN 、 SADD 、 SREM 、 SISMEMBER 、 SCARD 。

批量回复

服务器使用批量回复来返回二进制安全的字符串，字符串的最大长度为 512 MB 。

客户端：GET mykey

服务器：foobar

服务器发送的内容中：

第一字节为 "$" 符号

       - 接下来跟着的是表示实际回复长度的数字值

- 之后跟着一个 CRLF

- 再后面跟着的是实际回复数据

- 最末尾是另一个 CRLF

对于前面的 GET 命令，服务器实际发送的内容为：

"$6\r\nfoobar\r\n"

如果被请求的值不存在， 那么批量回复会将特殊值 -1 用作回复的长度值， 就像这样：

客户端：GET non-existing-key

服务器：$-1

这种回复称为空批量回复（NULL Bulk Reply）。

当请求对象不存在时，客户端应该返回空对象，而不是空字符串： 比如 Ruby 库应该返回 nil ， 而 C 库应该返回NULL （或者在回复对象中设置一个特殊标志）， 诸如此类。

多条批量回复

像 LRANGE 这样的命令需要返回多个值， 这一目标可以通过多条批量回复来完成。

多条批量回复是由多个回复组成的数组， 数组中的每个元素都可以是任意类型的回复， 包括多条批量回复本身。

多条批量回复的第一个字节为 "*" ， 后跟一个字符串表示的整数值， 这个值记录了多条批量回复所包含的回复数量， 再后面是一个 CRLF 。

客户端： LRANGE mylist 0 3

服务器： *4

服务器： $3

服务器： foo

服务器： $3

服务器： bar

服务器： $5

服务器： Hello

服务器： $5

服务器： World

在上面的示例中，服务器发送的所有字符串都由 CRLF 结尾。

正如你所见到的那样， 多条批量回复所使用的格式， 和客户端发送命令时使用的统一请求协议的格式一模一样。 它们之间的唯一区别是：

统一请求协议只发送批量回复。

而服务器应答命令时所发送的多条批量回复，则可以包含任意类型的回复。

以下例子展示了一个多条批量回复， 回复中包含四个整数值， 以及一个二进制安全字符串：

  *5\r\n

:1\r\n

:2\r\n

:3\r\n

:4\r\n

$6\r\n

foobar\r\n

在回复的第一行， 服务器发送 *5\r\n ， 表示这个多条批量回复包含 5 条回复， 再后面跟着的则是 5 条回复的正文。

多条批量回复也可以是空白的（empty）， 就像这样：

客户端： LRANGE nokey 0 1

服务器： *0\r\n

无内容的多条批量回复（null multi bulk reply）也是存在的， 比如当 BLPOP 命令的阻塞时间超过最大时限时， 它就返回一个无内容的多条批量回复， 这个回复的计数值为 -1 ：

客户端： BLPOP key 1

服务器： *-1\r\n

客户端库应该区别对待空白多条回复和无内容多条回复： 当 Redis 返回一个无内容多条回复时， 客户端库应该返回一个 null 对象， 而不是一个空数组。

多条批量回复中的空元素

多条批量回复中的元素可以将自身的长度设置为 -1 ， 从而表示该元素不存在， 并且也不是一个空白字符串（empty string）。

当 SORT 命令使用 GET pattern 选项对一个不存在的键进行 *** 作时， 就会发生多条批量回复中带有空白元素的情况。

以下例子展示了一个包含空元素的多重批量回复：

服务器： *3

服务器： $3

服务器： foo

服务器： $-1

服务器： $3

服务器： bar

其中， 回复中的第二个元素为空。

对于这个回复， 客户端库应该返回类似于这样的回复：

["foo", nil, "bar"]

进程能够单独运行并且完成一些任务，但是也经常免不了和其他进程传输数据或互相通知消息，即需要进行通信，本文将简罩塌单介绍一些进程之间相互通信的技术--进程间通信（InterProcess Communication，IPC）。由于篇幅有限，本文不会对每一种进行详细介绍。

进程间通信常见方式如下：

管道

FIFO

消息队列

信号量

共享内存

UNXI域套接字

套接字（Socket）

管道是一种古老的IPC通信形式。它有两个特点：

半双工，即不能同时在两个方向上传输数据。有的系统可能支持全双工。

只能在父子进程间。经典的形式就是管道由父进程创建，进程fork子进程之后，就可以在父子进程之间使用了。

system()函数虽然也能够执行系统命令，但是无法获取执行状态码，而执行系统命令本质上就需要创建子进程来完成，因此利用管道可以很方便的获取子进程的输出内容。本文好闷敏不详友枝细展开。

FIFO也被称为命名管道，与管道不同的是，不相关的进程也能够进行数据交换。

而FIFO也常常有以下两个用途：

无需创建中间临时文件，复制输出流

多客户-服务进程应用中，通过FIFO作为汇聚点，传输客户进程和服务进程之间的数据

两个没有亲缘关系的进程可以通过FIFO进行通信。

消息队列可以认为是一个消息链表，存储在内核中，进程可以从中读写数据。与管道和FIFO不同，进程可以在没有另外一个进程等待读的情况下进行写。另外一方面，管道和FIFO一旦相关进程都关闭并退出后，里面的数据也就没有了，但是对于消息队列，一个进程往消息队列中写入数据后退出，另外一个进程仍然可以打开并读取消息。消息队列与后面介绍的UNIX域套接字相比，在速度上没有多少优势。

信号量是一个计数器，它主要用在多个进程需要对共享数据进行访问的时候。考虑这一的情况，不能同时有两个进程对同一数据进行访问，那么借助信号量就可以完成这样的事情。

它的主要流程如下：

检查控制该资源的信号量

如果信号量值大于0，则资源可用，并且将其减1，表示当前已被使用

如果信号量值为0，则进程休眠直至信号量值大于0

也就是说，它实际上是提供了一个不同进程或者进程的不同线程之间访问同步的手段。

共享内存允许多个进程共享一个给定的存储区，由于它们是共享一块内存数据，因此其速度非常快。但是需要另外提供手段来保证共享内存的同步访问，例如它可以用到前面所提到的信号量来实现访问同步。

UNIX域套接字和套接字很相似，但是它有更高的效率，因为它不需要执行协议处理，例如计算校验和，发送确认报文等等，它仅仅复制数据。

当然，它也只适用于同一台计算机上的进程间通信。

例如redis服务配置unixsocket启动后，通过redis-cli的-s参数就可以指定UNIX域套接字，连接到redis服务器。

它会比使用网络套接字的速度要快。

这个不用多说，它利用网络进行通信，与前面所提到的通信方式不同的是，它能用于不同计算机之间的不同进程间通信。

本文简单介绍了进程间通信的常见方式，其中对管道和命名管道我们使用了一个例子来简单说明，因为我们可能会经常见到它。对于FIFO，最后一个引用它的进程终止时，留在FIFO的数据也将会被删除，而对于消息队列却不是这样，它会一直留到被显示删除或者系统自举，另外消息队列于其他方式相比并没有特别的优势。而信号量实际上常用于共享数据的同步访问。共享内存在进程间传递数据非常高效，但是系统没有对访问进行同步，因此还需要另外实现数据的访问同步。套接字（socket）是应该目前应用最广泛的进程间通信方式。

---