網路協議之:redis protocol 詳解
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\n5\r\nredis\r\n6\r\nserver\r\n"
RESP Arrays中的原始不僅可以使用不同型別,還能包含RESP Arrays,也就是array的巢狀:
"*3\r\n5\r\nredis\r\n6\r\nserver\r\n*1\r\n$4\r\ngood\r\n"
為了方便觀察,我們將上面的訊息格式一下:
"*3\r\n 5\r\nredis\r\n6\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\n3\r\nget\r\n5\r\nworld\r\n"
我們嘗試一下將上述命令使用nc傳遞到redis server上:
(printf "*2\r\n3\r\nget\r\n5\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 63795 hello
可以看到輸出的結果和直接使用redis-cli一致。
以上就是RESP協議的基本內容和手動使用的例子,有了RESP,我們就可以根據協議中定義的格式來建立redis客戶端。
可能大家又會問了,為什麼只是redis客戶端呢?有了協議是不是redis伺服器端也可以建立呢?答案當然是肯定的,只需要按照協議進行訊息傳輸即可。主要的問題在於redis伺服器端的實現比較複雜,不是那麼容易實現的。
- 網路協議之:redis protocol 詳解
- flutter系列之:flutter架構什麼的,看完這篇文章就全懂了
- 密碼學系列之:PEM和PKCS7,PKCS8,PKCS12
- netty系列之:在netty中使用TCP協議請求DNS伺服器
- netty系列之:epoll傳輸協議詳解
- netty系列之:kequeue傳輸協議詳解
- netty系列之:在netty中使用native傳輸協議
- netty系列之:在netty中實現執行緒和CPU繫結
- netty系列之:HashedWheelTimer一種定時器的高效實現
- SpringBoot之:SpringBoot的HATEOAS基礎
- 網路協議之:sctp流控制傳輸協議的協議訊息包詳解
- java高階用法之:JNA中的Memory和Pointer
- netty系列之:netty中的核心編碼器base64
- netty系列之:netty中的核心MessageToMessage編碼器
- java高階用法之:JNA型別對映應該注意的問題
- java高階用法之:在JNA中將本地方法對映到JAVA程式碼中
- 網路協議之:socket協議詳解之Unix domain Socket
- 網路協議之:socket協議詳解之Socket和Stream Socket
- java高階用法之:呼叫本地方法的利器JNA
- java高階用法之:無所不能的java,本地方法呼叫實況