[KVS][Redis] Redis プロトコル仕様

• 概要
• ネットワーク層
• シンプルなインラインコマンド
• バルクコマンド
• バルクリプライ
• マルチバルクリプライ
• マルチバルクリプライの中の Nil 要素
• 単一行リプライ
• 整数リプライ
• 複数のコマンドとパイプライン

Redis のプロトコル仕様について、公式ドキュメントを参考にメモ(ほぼ、簡易な訳のみ)。

• ProtocolSpecification - redis - Project Hosting on Google Code

• クライアントが Redis サーバに接続するために、6379 番ポートへの TCP 接続を作る
• Redis のコマンドおよびデータは "\r\n" (CRLF) で終了する

以下は、C をクライアント、S をサーバとした通信例。

C: PING
S: +PONG

クライアントが CRLF で終了するインラインコマンドをサーバに送ると、サーバは以下のいずれかの種類の応答を返す。

• エラーメッセージ(先頭の 1 byte が "-")
• 単一行の応答(先頭の 1 byte が "+")
• 値の配列である複数のまとまったデータ(先頭の 1 byte が "*")
• 整数(先頭の 1 倍とが ":")

以下、整数が返るインラインコマンド。

C: EXISTS someky
S: :0

• EXISTS コマンドは 1 つの引数をとる
• 引数は一つの空白で区切られる

バルクコマンドはインラインコマンドと全くだが、サーバにデータを送信するために、コマンドの最後の引数が送信するストリームのバイト数でなければならない。

以下は、SET コマンドの例。

C: SET mkey 6
C: foobar
S: +OK

• SET コマンドの最後の引数 "6" が後に続くデータのバイト数
• 全てのバルクコマンドはこの形式に従う
  • "SET mkey 6\r\nfoobar\r\n"

サーバはインラインコマンドおよびバルクコマンドにバルクリプライを返す。

C: GET mkey
S: $6
S: foobar

• サーバが返す最初の行は、後に続くデータのバイト数を "$" の直後につけたもので、次の行がデータ
  • "$6\r\nfoobar\r\n"

指定したキーに対応する値がなければ、特別な値である "-1" を返す。

C: GET notexistingkey
S: $-1

• クライアントライブラリの API は、リクエストしたオブジェクトが存在しない場合に、空文字列を返すべきではなく、nil を返すべき
  • 例えば、Ruby では nil を返すべきだし、C ライブラリなら NULL を返すべき

LRANGE の様なコマンドは、複数の値を返す必要がある。最初の行で後にいくつの塊が続くかを示す事で、実現している。

C: LRANGE mylist 0 3
S: *4
S: $3
S: foo
S: $3
S: bar
S: $5
S: Hello
S: $5
S: World

• サーバが送ってきた最初の行 "*4\r\n" は後に 4 つの塊が書き込まれる事を示している
• 指定したキーに対応する値がなければ、特別な値である "-1" を返す

C: LRANGE nokey 0 1
S: *-1

要素が失われて空文字列ではない事を示すために、マルチバルクリプライの要素に長さ -1 を示すものがあるかもしれない。 これは、指定したキーが失われた時に GET パターンオプションを使った SORT コマンドで起きる事がある。

S: *3
S: $3
S: foo
S: $-1
S: $3
S: bar

• 2 番目の要素が空(nul)

["foo",nil,"bar"]

"+" で始まり "\r\n" で終わる、単一行のリプライ。

S: +OK

例えば、 以下のコマンドは応答コードを返す。

• PING
• SET
• SELECT
• SAVE
• BGSAVE
• SHUTDOWN
• RENAME
• LPUSH
• RPUSH
• LSET
• LTRIM

":" で始まって数字が続き、"\r\n" で終わるリプライ。

• ":0\r\n"
• ":1000\r\n"

例えば、以下のコマンドは数値リプライを返す。

• SETNX
• DEL
• EXISTS
• INCR
• INCRBY
• DECR
• DECRBY
• DBSIZE
• LASTSAVE
• RENAMENX
• MOVE
• LLEN
• SADD
• SREM
• SISMEMBER
• SCARD

クライアントは、複数のコマンドを発行するために、同一のコネクションを利用できる。 パイプラインがサポートされているため、次のコマンドのためにサーバからのリプライを必要としないなら、クライアントの単一書き込み命令によって複数のコマンドを送る事ができる。

通常、Redis のクライアントとサーバは高速につながっているため、この特徴をクライアントがサポートする事は重要ではない。非常に多くのコマンドを短時間で処理する必要があるなら、パイプラインを利用する方がより高速ではある。