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

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

Go、PHP、Java... 都有那么多包來(lái)支撐你使用 Redis，那你是否有想過(guò)

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

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

Redis 的客戶端和服務(wù)端是通過(guò) TCP 連接來(lái)進(jìn)行數(shù)據(jù)交互， 服務(wù)器默認(rèn)的端口號(hào)為 6379

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

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

本文是基于新版協(xié)議來(lái)實(shí)現(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ù)都是二進(jìn)制安全（binary safe）的

2、打印示例

*3
$3
SET
$5
mykey
$7
myvalue

3、實(shí)際協(xié)議值

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

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

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

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

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

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

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

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

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