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

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

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

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

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

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

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

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

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

1、 格式示例

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

在該協(xié)議下所有發(fā)送至 Redis 服務器的參數都是二進制安全（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，相信你已經有大致的概念了，Redis 的協(xié)議非常的簡潔易懂，這也是好上手的原因之一，你可以想想協(xié)議這么定義的好處在哪？

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

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

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

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

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

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

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