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

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

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

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

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

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

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

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

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

1、 格式示例

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

在該協議下所有發送至 Redis 服務器的參數都是二進制安全（binary safe）的

2、打印示例

*3
$3
SET
$5
mykey
$7
myvalue

3、實際協議值

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

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

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

狀態回復（status reply）的第一個字節是 "+"

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

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

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

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

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