摘要：用來了解一下通訊協(xié)議原文地址用來了解一下通訊協(xié)議都有那么多包來支撐你使用，那你是否有想過有了服務(wù)端，有了客戶端，他們倆是怎樣通訊，又是基于什么通訊協(xié)議做出交互的呢介紹基于我們的目的，本文主要講解和實踐的通訊協(xié)議的客戶端和服務(wù)端是通過連接來進

原文地址：用 Go 來了解一下 Redis 通訊協(xié)議

Go、PHP、Java... 都有那么多包來支撐你使用 Redis，那你是否有想過

有了服務(wù)端，有了客戶端，他們倆是怎樣通訊，又是基于什么通訊協(xié)議做出交互的呢？

基于我們的目的，本文主要講解和實踐 Redis 的通訊協(xié)議

Redis 的客戶端和服務(wù)端是通過 TCP 連接來進行數(shù)據(jù)交互， 服務(wù)器默認的端口號為 6379

客戶端和服務(wù)器發(fā)送的命令或數(shù)據(jù)一律以 （CRLF）結(jié)尾（這是一條約定）

在 Redis 中分為請求和回復(fù)，而請求協(xié)議又分為新版和舊版，新版統(tǒng)一請求協(xié)議在 Redis 1.2 版本中引入，最終在 Redis 2.0 版本成為 Redis 服務(wù)器通信的標準方式

本文是基于新版協(xié)議來實現(xiàn)功能，不建議使用舊版（1.2 挺老舊了）。如下是新協(xié)議的各種范例：

1、 格式示例

*<參數(shù)數(shù)量> CR LF
$<參數(shù) 1 的字節(jié)數(shù)量> CR LF
<參數(shù) 1 的數(shù)據(jù)> CR LF
...
$<參數(shù) N 的字節(jié)數(shù)量> CR LF
<參數(shù) N 的數(shù)據(jù)> CR LF

在該協(xié)議下所有發(fā)送至 Redis 服務(wù)器的參數(shù)都是二進制安全（binary safe）的

2、打印示例

*3
$3
SET
$5
mykey
$7
myvalue

3、實際協(xié)議值

"*3
$3
SET
$5
mykey
$7
myvalue
"

這就是 Redis 的請求協(xié)議規(guī)范，按照范例1編寫客戶端邏輯，最終發(fā)送的是范例3，相信你已經(jīng)有大致的概念了，Redis 的協(xié)議非常的簡潔易懂，這也是好上手的原因之一，你可以想想?yún)f(xié)議這么定義的好處在哪？

Redis 會根據(jù)你請求協(xié)議的不同（執(zhí)行的命令結(jié)果也不同），返回多種不同類型的回復(fù)。在這個回復(fù)“協(xié)議”中，可以通過檢查第一個字節(jié)，確定這個回復(fù)是什么類型，如下：

狀態(tài)回復(fù)（status reply）的第一個字節(jié)是 "+"

錯誤回復(fù)（error reply）的第一個字節(jié)是 "-"

整數(shù)回復(fù)（integer reply）的第一個字節(jié)是 ":"

批量回復(fù)（bulk reply）的第一個字節(jié)是 "$"

多條批量回復(fù)（multi bulk reply）的第一個字節(jié)是 "*"

有了回復(fù)的頭部標識，結(jié)尾的 CRLF，你可以大致猜想出回復(fù)“協(xié)議”是怎么樣的，但是實踐才能得出真理，斎知道怕是你很快就忘記了