簡介

redis是一個非常優(yōu)秀的軟件，它可以用作內(nèi)存數(shù)據(jù)庫或者緩存。因為他的優(yōu)秀性能，redis被應用在很多場合中。

redis是一個客戶端和服務器端的模式，客戶端和服務器端是通過TCP協(xié)議進行連接的，客戶端將請求數(shù)據(jù)發(fā)送到服務器端，服務器端將請求返回給客戶端。這樣一個請求流程就完成了。

當然在最開始的時候，因為用的人很少，系統(tǒng)還不夠穩(wěn)定，通過TCP協(xié)議傳輸?shù)臄?shù)據(jù)不規(guī)范的。但是當用的人越來越多，尤其是希望開發(fā)適用于不同語言和平臺的redis客戶端的時候，就要考慮到兼容性的問題了。

這時候客戶端和服務器端就需要一個統(tǒng)一的交互協(xié)議，對于redis來說這個通用的交互協(xié)議就叫做Redis serialization protocol(RESP)。

RESP是在Redis 1.2版本中引入的，并在Redis 2.0中成為了與 Redis 服務器通信的標準方式。

這就是說，從Redis 2.0之后，就可以基于redis protocol協(xié)議開發(fā)出自己的redis客戶端了。

redis的高級用法

一般來說，redis的客戶端和服務器端組成的是一個請求-響應的模式，也就是說客戶端向服務器端發(fā)送請求，然后得到服務器端的響應結(jié)果。

請求和響應是redis中最簡單的用法。熟悉redis的朋友可能會想到了兩個redis的高級用法，這兩個用法并不是傳統(tǒng)意義上的請求-響應模式。

到底是哪兩種用法呢?

第一種就是redis支持pipline，也就是管道操作，管道的好處就是redis客戶端可以一次性向服務器端發(fā)送多條命令，然后等待服務器端的返回。

第二種redis還支持Pub/Sub，也就是廣播模型，在這一種情況下，就不是請求和響應的模式了，在Pub/Sub下，切換成了服務器端推送的模式。

Redis中的pipline

為什么要用pipline呢？

因為redis是一個典型的請求響應模式，我們來舉個常見的incr命令的例子：

Client: INCR X Server: 1 Client: INCR X Server: 2 Client: INCR X Server: 3 Client: INCR X Server: 4

事實上客戶端只想得到最終的結(jié)果，但是每次客戶端都需要等待服務器端返回結(jié)果之后，才能發(fā)送下一次的命令。這樣就會導致一個叫做RTT(Round Trip Time)的時間浪費。

雖然每次RTT的時間不長，但是累計起來也是一個非常客觀的數(shù)字。

那么可不可以將所有的客戶端命令放在一起發(fā)送給服務器呢? 這個優(yōu)化就叫做Pipeline。

piepline的意思就是客戶端可以在沒有收到服務器端返回的時候繼續(xù)向服務器端發(fā)送命令。

上面的命令可以用pipline進行如下改寫：

(printf "INCR X\r\nINCR X\r\nINCR X\r\nINCR X\r\n"; sleep 1) | nc localhost 6379
:1
:2
:3
:4

因為redis服務器支持TCP協(xié)議進行連接，所以我們可以直接用nc連到redis服務器中執(zhí)行命令。

在使用pipline的時候有一點要注意，因為redis服務器會將請求的結(jié)果緩存在服務器端，等到pipline中的所有命令都執(zhí)行完畢之后再統(tǒng)一返回，所以如果服務器端返回的數(shù)據(jù)比較多的情況下，需要考慮內(nèi)存占用的問題。

那么pipline僅僅是為了減少RTT嗎？

熟悉操作系統(tǒng)的朋友可能有聽說過用戶空間和操作系統(tǒng)空間的概念，從用戶輸入讀取數(shù)據(jù)然后再寫入到系統(tǒng)空間中，這里涉及到了一個用戶空間的切換，在IO操作中，這種空間切換或者拷貝是比較耗時的，如果頻繁的進行請求和響應，就會造成這種頻繁的空間切換，從而降低了系統(tǒng)的效率。

使用pipline可以一次性發(fā)送多條指令，從而有效避免空間的切換行為。

Redis中的Pub/Sub

和Pub/Sub相關(guān)的命令是SUBSCRIBE, UNSUBSCRIBE 和 PUBLISH。

為什么要用Pub/Sub呢？其主要的目的就是解耦，在Pub/Sub中消息發(fā)送方不需要知道具體的接收方的地址，同樣的對于消息接收方來說，也不需要知道具體的消息發(fā)送方的地址。他們只需要知道關(guān)聯(lián)的主題即可。

subscribe和publish的命令比較簡單，我們舉一個例子，首先是客戶端subscribe topic：

redis-cli -h 127.0.0.1
127.0.0.1:6379> subscribe topic
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "topic"
3) (integer) 1

然后在另外一個終端，調(diào)用publish命令：

redis-cli -h 127.0.0.1
127.0.0.1:6379> publish topic "what is your name?"
(integer) 1

可以看到客戶端會收到下面的消息：

1) "message"
2) "topic"
3) "what is your name?"

RESP protocol

RESP協(xié)議有5種類型，分別是imple Strings, Errors, Integers, Bulk Strings 和 Arrays。

不同的類型以消息中的第一個byte進行區(qū)分，如下所示：

protocol中不同的部分以 "\r\n" (CRLF)來進行區(qū)別。

Simple Strings

Simple Strings的意思是簡單的字符串。

通常用在服務器端的返回中，這種消息的格式就是"+"加上文本消息，最后以"\r\n"結(jié)尾。

比如服務器端返回OK,那么對應的消息就是：

"+OK\r\n"

上面的消息是一個非二進制安全的消息，如果想要發(fā)送二進制安全的消息，則可以使用Bulk Strings。

什么是非二進制安全的消息呢？對于Simple Strings來說，因為消息是以"\r\n"結(jié)尾，所以消息中間不能包含"\r\n"這兩個特殊字符，否則就會產(chǎn)生錯誤的含義。

Bulk Strings

Bulk Strings是二進制安全的。這是因為Bulk Strings包含了一個字符長度字段，因為是根據(jù)長度來判斷字符長度的，所以并不存在根據(jù)字符中某個特定字符來判斷是否字符結(jié)束的缺點。

具體而言Bulk Strings的結(jié)構(gòu)是"$"+字符串長度+"\r\n"+字符串+"\r\n"。

以O(shè)K為例，如果以Bulk Strings來表示，則如下所示:

"$2\r\nok\r\n"

Bulk Strings還可以包含空字符串：

"$0\r\n\r\n"

當然還可以表示不存在的Null值：

"$-1\r\n"

RESP Integers

這是redis中的整數(shù)表示，具體的格式是":"+整數(shù)+"\r\n"。

比如18這個整數(shù)就可以用下面的格式來表示：

":18\r\n"

RESP Arrays

redis的多個命令可以以array來表示，服務器端返回的多個值也可以用arrays來表示。

RESP Arrays的格式是"*"+數(shù)組中的元素個數(shù)+其他類似的數(shù)據(jù)。

所以RESP Arrays是一個復合結(jié)構(gòu)的數(shù)據(jù)。比如一個數(shù)組中包含了兩個Bulk Strings:"redis","server"則可以用下面的格式來表示：

"*2\r\n$5\r\nredis\r\n$6\r\nserver\r\n"

RESP Arrays中的原始不僅可以使用不同類型，還能包含RESP Arrays，也就是array的嵌套：

"*3\r\n$5\r\nredis\r\n$6\r\nserver\r\n*1\r\n$4\r\ngood\r\n"

為了方便觀察，我們將上面的消息格式一下：

"*3\r\n
$5\r\nredis\r\n
$6\r\nserver\r\n
*1\r\n
$4\r\ngood\r\n"

上面的消息是一個包含三個元素的數(shù)組，前面兩個元素是Bulk Strings，最后一個是包含一個元素的數(shù)組。

RESP Errors

最后，RESP還可以表示錯誤消息。RESP Errors的消息格式是"-"+字符串，如下所示：

"-Err something wrong\r\n"

一般情況下，"-"后面的第一個單詞表示的是錯誤類型，但是這只是一個約定俗成的規(guī)定，并不是RESP協(xié)議中的強制要求。

另外，經(jīng)過對比，大家可能會發(fā)現(xiàn)RESP Errors和Simple Strings是消息格式是差不多的。

這種對不同消息類型的處理是在客戶端進行區(qū)分的。

Inline commands

如果完全按RESP協(xié)議的要求，當我們連接到服務器端的時候需要包含RESP中定義消息的所有格式，但是這些消息中包含了額外的消息類型和回車換行符，所以直接使用協(xié)議來執(zhí)行的話會比較困惑。

于是redis還提供一些內(nèi)聯(lián)的命令，也就是協(xié)議命令的精簡版本，這個精簡版本去除了消息類型和回車換行符。

我們以"get world"這個命令為例。來看下不同方式的連接情況。

首先是使用redis-cli進行連接：

redis-cli -h 127.0.0.1
127.0.0.1:6379> get world
"hello"

因為redis-cli是redis的客戶端，所以可以直接使用inline command來執(zhí)行命令。

如果使用telnet,我們也可以使用同樣的命令來獲得結(jié)果：

telnet 127.0.0.1 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
get world
$5
hello

可以看到返回的結(jié)果是"$5\r\nhello\r\n"。

如果要使用協(xié)議消息來請求redis服務器應該怎么做呢？

我們要請求的命令是"get world",將其轉(zhuǎn)換成為RESP的消息則是：

"*2\r\n$3\r\nget\r\n$5\r\nworld\r\n"

我們嘗試一下將上述命令使用nc傳遞到redis server上：

(printf "*2\r\n$3\r\nget\r\n$5\r\nworld\r\n"; sleep 1) |  nc localhost 6379
-ERR Protocol error: expected '$', got ' '

很遺憾我們得到了ERR，那么是不是不能直接使用RESP消息格式進行傳輸呢？當然不是，上面的問題在于$符號是一個特殊字符，我們需要轉(zhuǎn)義一下：

(printf "*2\r\n\$3\r\nget\r\n\$5\r\nworld\r\n"; sleep 1) |  nc localhost 6379
$5
hello

可以看到輸出的結(jié)果和直接使用redis-cli一致。

總結(jié)

以上就是RESP協(xié)議的基本內(nèi)容和手動使用的例子，有了RESP，我們就可以根據(jù)協(xié)議中定義的格式來創(chuàng)建redis客戶端。

可能大家又會問了，為什么只是redis客戶端呢？有了協(xié)議是不是redis服務器端也可以創(chuàng)建呢？答案當然是肯定的，只需要按照協(xié)議進行消息傳輸即可。主要的問題在于redis服務器端的實現(xiàn)比較復雜，不是那么容易實現(xiàn)的。

以上就是redis protocol通信協(xié)議及使用詳解的詳細內(nèi)容，更多關(guān)于redis protocol通信協(xié)議的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論