Redis 的作者認爲數據庫系統的瓶頸一般不在於網絡流量，而是數據庫自身內部邏輯處理上。所以即使 Redis 使用了浪費流量的文本協議，依然可以取得極高的訪問性能。Redis 將所有數據都放在內存，用一個單線程對外提供服務，單個節點在跑滿一個 CPU 核心的情況下可以達到了 10w/s 的超高 QPS。
RESP(Redis Serialization Protocol)
RESP 是 Redis 序列化協議的簡寫。它是一種直觀的文本協議，優勢在於實現異常簡單，解析性能極好。
Redis 協議將傳輸的結構數據分爲 5 種最小單元類型，單元結束時統一加上回車換行符號\r\n。
1.單行字符串 以 + 符號開頭。
2.多行字符串 以 $ 符號開頭，後跟字符串長度。
3.整數值 以 : 符號開頭，後跟整數的字符串形式。
4.錯誤消息 以 - 符號開頭。
5.數組 以 * 號開頭，後跟數組的長度。
單行字符串 hello world
+hello world\r\n
多行字符串 hello world
$11\r\nhello world\r\n
多行字符串當然也可以表示單行字符串。
整數 1024
:1024\r\n
錯誤 參數類型錯誤
-WRONGTYPE Operation against a key holding the wrong kind of value\r\n
數組 [1,2,3]
*3\r\n:1\r\n:2\r\n:3\r\n
NULL 用多行字符串表示，不過長度要寫成-1。
$-1\r\n
空串 用多行字符串表示，長度填 0。
$0\r\n\r\n
注意這裏有兩個\r\n。爲什麼是兩個?因爲兩個\r\n之間,隔的是空串。
客戶端 -> 服務器
客戶端向服務器發送的指令只有一種格式，多行字符串數組。比如一個簡單的 set 指令set author codehole會被序列化成下面的字符串。
*3\r\n$3\r\nset\r\n$6\r\nauthor\r\n$8\r\ncodehole\r\n
在控制檯輸出這個字符串如下，可以看出這是很好閱讀的一種格式。
*3
$3
set
$6
author
$8
codehole
服務器 -> 客戶端
服務器向客戶端回覆的響應要支持多種數據結構，所以消息響應在結構上要複雜不少。不過再複雜的響應消息也是以上 5 中基本類型的組合。
單行字符串響應
127.0.0.1:6379> set author codehole
OK
這裏的 OK 就是單行響應，沒有使用引號括起來。
+OK
錯誤響應
127.0.0.1:6379> incr author
(error) ERR value is not an integer or out of range
試圖對一個字符串進行自增，服務器拋出一個通用的錯誤。
-ERR value is not an integer or out of range
整數響應
127.0.0.1:6379> incr books
(integer) 1
這裏的1就是整數響應
:1
多行字符串響應
127.0.0.1:6379> get author
"codehole"
這裏使用雙引號括起來的字符串就是多行字符串響應
$8
codehole
數組響應
127.0.0.1:6379> hset info name laoqian
(integer) 1
127.0.0.1:6379> hset info age 30
(integer) 1
127.0.0.1:6379> hset info sex male
(integer) 1
127.0.0.1:6379> hgetall info
1) "name"
2) "laoqian"
3) "age"
4) "30"
5) "sex"
6) "male"
這裏的 hgetall 命令返回的就是一個數組，第 0|2|4 位置的字符串是 hash 表的 key，第 1|3|5 位置的字符串是 value，客戶端負責將數組組裝成字典再返回。
*6
$4
name
$6
laoqian
$3
age
$2
30
$3
sex
$4
male
嵌套
127.0.0.1:6379> scan 0
1) "0"
2) 1) "info"
2) "books"
3) "author"
scan 命令用來掃描服務器包含的所有 key 列表，它是以遊標的形式獲取，一次只獲取一部分。
scan 命令返回的是一個嵌套數組。數組的第一個值表示遊標的值，如果這個值爲零，說明已經遍歷完畢。如果不爲零，使用這個值作爲 scan 命令的參數進行下一次遍歷。數組的第二個值又是一個數組，這個數組就是 key 列表。
*2
$1
0
*3
$4
info
$5
books
$6
author
小結
Redis 協議裏有大量冗餘的回車換行符，但是這不影響它成爲互聯網技術領域非常受歡迎的一個文本協議。有很多開源項目使用 RESP 作爲它的通訊協議。在技術領域性能並不總是一切，還有簡單性、易理解性和易實現性，這些都需要進行適當權衡。