簡介
redis是一個非常優秀的軟件，它可以用作內存數據庫或者緩存。因爲他的優秀性能，redis被應用在很多場合中。
redis是一個客戶端和服務器端的模式，客戶端和服務器端是通過TCP協議進行連接的，客戶端將請求數據發送到服務器端，服務器端將請求返回給客戶端。這樣一個請求流程就完成了。
當然在最開始的時候，因爲用的人很少，系統還不夠穩定，通過TCP協議傳輸的數據不規範的。但是當用的人越來越多，尤其是希望開發適用於不同語言和平臺的redis客戶端的時候，就要考慮到兼容性的問題了。
這時候客戶端和服務器端就需要一個統一的交互協議，對於redis來說這個通用的交互協議就叫做Redis serialization protocol(RESP)。
RESP是在Redis 1.2版本中引入的，並在Redis 2.0中成爲了與 Redis 服務器通信的標準方式。
這就是說，從Redis 2.0之後，就可以基於redis protocol協議開發出自己的redis客戶端了。
redis的高級用法
一般來說，redis的客戶端和服務器端組成的是一個請求-響應的模式，也就是說客戶端向服務器端發送請求，然後得到服務器端的響應結果。
請求和響應是redis中最簡單的用法。熟悉redis的朋友可能會想到了兩個redis的高級用法，這兩個用法並不是傳統意義上的請求-響應模式。
到底是哪兩種用法呢?
第一種就是redis支持pipline，也就是管道操作，管道的好處就是redis客戶端可以一次性向服務器端發送多條命令，然後等待服務器端的返回。
第二種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
事實上客戶端只想得到最終的結果，但是每次客戶端都需要等待服務器端返回結果之後，才能發送下一次的命令。這樣就會導致一個叫做RTT(Round Trip Time)的時間浪費。
雖然每次RTT的時間不長，但是累計起來也是一個非常客觀的數字。
那麼可不可以將所有的客戶端命令放在一起發送給服務器呢? 這個優化就叫做Pipeline。
piepline的意思就是客戶端可以在沒有收到服務器端返回的時候繼續向服務器端發送命令。
上面的命令可以用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協議進行連接，所以我們可以直接用nc連到redis服務器中執行命令。
在使用pipline的時候有一點要注意，因爲redis服務器會將請求的結果緩存在服務器端，等到pipline中的所有命令都執行完畢之後再統一返回，所以如果服務器端返回的數據比較多的情況下，需要考慮內存佔用的問題。
那麼pipline僅僅是爲了減少RTT嗎？
熟悉操作系統的朋友可能有聽說過用戶空間和操作系統空間的概念，從用戶輸入讀取數據然後再寫入到系統空間中，這裏涉及到了一個用戶空間的切換，在IO操作中，這種空間切換或者拷貝是比較耗時的，如果頻繁的進行請求和響應，就會造成這種頻繁的空間切換，從而降低了系統的效率。
使用pipline可以一次性發送多條指令，從而有效避免空間的切換行爲。
Redis中的Pub/Sub
和Pub/Sub相關的命令是SUBSCRIBE, UNSUBSCRIBE 和 PUBLISH。
爲什麼要用Pub/Sub呢？其主要的目的就是解耦，在Pub/Sub中消息發送方不需要知道具體的接收方的地址，同樣的對於消息接收方來說，也不需要知道具體的消息發送方的地址。他們只需要知道關聯的主題即可。
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
然後在另外一個終端，調用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協議有5種類型，分別是imple Strings, Errors, Integers, Bulk Strings 和 Arrays。
不同的類型以消息中的第一個byte進行區分，如下所示：
| 類型 | 第一個byte |
|---|---|
| Simple Strings | + |
| Errors | - |
| Integers | : |
| Bulk Strings | $ |
| Arrays | * |
protocol中不同的部分以 "\r\n" (CRLF)來進行區別。
Simple Strings
Simple Strings的意思是簡單的字符串。
通常用在服務器端的返回中，這種消息的格式就是"+"加上文本消息，最後以"\r\n"結尾。
比如服務器端返回OK,那麼對應的消息就是：
"+OK\r\n"
上面的消息是一個非二進制安全的消息，如果想要發送二進制安全的消息，則可以使用Bulk Strings。
什麼是非二進制安全的消息呢？對於Simple Strings來說，因爲消息是以"\r\n"結尾，所以消息中間不能包含"\r\n"這兩個特殊字符，否則就會產生錯誤的含義。
Bulk Strings
Bulk Strings是二進制安全的。這是因爲Bulk Strings包含了一個字符長度字段，因爲是根據長度來判斷字符長度的，所以並不存在根據字符中某個特定字符來判斷是否字符結束的缺點。
具體而言Bulk Strings的結構是"$"+字符串長度+"\r\n"+字符串+"\r\n"。
以OK爲例，如果以Bulk Strings來表示，則如下所示:
"$2\r\nok\r\n"
Bulk Strings還可以包含空字符串：
"$0\r\n\r\n"
當然還可以表示不存在的Null值：
"$-1\r\n"
RESP Integers
這是redis中的整數表示，具體的格式是":"+整數+"\r\n"。
比如18這個整數就可以用下面的格式來表示：
":18\r\n"
RESP Arrays
redis的多個命令可以以array來表示，服務器端返回的多個值也可以用arrays來表示。
RESP Arrays的格式是"*"+數組中的元素個數+其他類似的數據。
所以RESP Arrays是一個複合結構的數據。比如一個數組中包含了兩個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"
上面的消息是一個包含三個元素的數組，前面兩個元素是Bulk Strings，最後一個是包含一個元素的數組。
RESP Errors
最後，RESP還可以表示錯誤消息。RESP Errors的消息格式是"-"+字符串，如下所示：
"-Err something wrong\r\n"
一般情況下，"-"後面的第一個單詞表示的是錯誤類型，但是這只是一個約定俗成的規定，並不是RESP協議中的強制要求。
另外，經過對比，大家可能會發現RESP Errors和Simple Strings是消息格式是差不多的。
這種對不同消息類型的處理是在客戶端進行區分的。
Inline commands
如果完全按RESP協議的要求，當我們連接到服務器端的時候需要包含RESP中定義消息的所有格式，但是這些消息中包含了額外的消息類型和回車換行符，所以直接使用協議來執行的話會比較困惑。
於是redis還提供一些內聯的命令，也就是協議命令的精簡版本，這個精簡版本去除了消息類型和回車換行符。
我們以"get world"這個命令爲例。來看下不同方式的連接情況。
首先是使用redis-cli進行連接：
redis-cli -h 127.0.0.1
127.0.0.1:6379> get world
"hello"
因爲redis-cli是redis的客戶端，所以可以直接使用inline command來執行命令。
如果使用telnet,我們也可以使用同樣的命令來獲得結果：
telnet 127.0.0.1 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
get world
$5
hello
可以看到返回的結果是"$5\r\nhello\r\n"。
如果要使用協議消息來請求redis服務器應該怎麼做呢？
我們要請求的命令是"get world",將其轉換成爲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消息格式進行傳輸呢？當然不是，上面的問題在於$符號是一個特殊字符，我們需要轉義一下：
(printf "*2\r\n\$3\r\nget\r\n\$5\r\nworld\r\n"; sleep 1) | nc localhost 6379
$5
hello
可以看到輸出的結果和直接使用redis-cli一致。
總結
以上就是RESP協議的基本內容和手動使用的例子，有了RESP，我們就可以根據協議中定義的格式來創建redis客戶端。
可能大家又會問了，爲什麼只是redis客戶端呢？有了協議是不是redis服務器端也可以創建呢？答案當然是肯定的，只需要按照協議進行消息傳輸即可。主要的問題在於redis服務器端的實現比較複雜，不是那麼容易實現的。