Redisチートシート - 基本データ型・TTL・安全な操作

最頻出10項目

Redisではキー名、データ型、TTLをセットで設計します。本番で KEYS *、FLUSHDB、FLUSHALL を安易に実行せず、探索には SCAN、大きな値の削除には UNLINK を検討します。

redis-cliへ接続

redis-cli -h localhost -p 6379

認証が必要な場合、redis-cli -a password はパスワードがコマンド履歴やプロセス一覧へ露出する可能性があるため推奨しません。

対話セッションで AUTH を入力する方法があります。

redis-cli -h redis.example.com -p 6379 --tls

AUTH username password
PING

または環境変数を利用できます。

export REDISCLI_AUTH='your-secret'
redis-cli -h redis.example.com -p 6379 --tls
unset REDISCLI_AUTH

環境変数も同一ユーザーのプロセスやログから露出する可能性があります。利用環境の秘密情報管理手段を優先し、シェル初期化ファイルやリポジトリへ保存しません。通信経路が外部ネットワークを通る場合はTLSを利用します。

接続先と状態を確認

PING
CLIENT INFO
DBSIZE
INFO server
INFO memory

破壊操作の前に、ホスト、ポート、ユーザー、選択DB、キーの名前空間を確認します。Redis Clusterでは SELECT を使えず、通常DB 0のみです。環境ごとに異なるキー接頭辞を使うと誤操作を減らせます。

String

SET user:1:name Ada
GET user:1:name
MSET user:1:city Tokyo user:1:active true
MGET user:1:city user:1:active

TTL付きで保存します。

SET session:abc active EX 3600
TTL session:abc
EXPIRE session:abc 7200

既存キーへ SET すると、以前の値とTTLが置き換わる場合があります。既存TTLを保持したい場合は KEEPTTL など、利用バージョンのオプションを確認します。

TTL

TTL session:abc
PTTL session:abc
EXPIRE session:abc 3600
PERSIST session:abc

TTL の主な戻り値は、正の数が残り秒数、-1 が期限なし、-2 がキーなしです。キャッシュやセッションでは、期限なしのキーが意図せず蓄積しないよう監視します。

TTLは期限後ちょうどその瞬間に物理削除されることを保証するものではありませんが、期限切れキーは取得できません。永続化やフェイルオーバーを含む要件は、利用するRedis構成で確認します。

キーの状態を確認

EXISTS session:abc
TYPE session:abc
OBJECT ENCODING session:abc
MEMORY USAGE session:abc

同じキーへ異なる型のコマンドを使うと型エラーになります。命名規則で用途を分かりやすくし、書き込み前に既存キーとの衝突を考慮します。RENAME は移動先を上書きするため、存在確認なしで実行しないでください。

Hash

関連する複数フィールドを1キーへ保存します。

HSET user:1 name Ada age 18 active true
HGET user:1 name
HMGET user:1 name age
HGETALL user:1
HINCRBY user:1 login_count 1
HDEL user:1 temporary_field

非常に大きなHashへ HGETALL を使うと、応答と通信量が大きくなります。必要なフィールドを取得するか HSCAN を使います。

List

Listは順序付きの文字列列です。

RPUSH queue:email job-1 job-2
LPOP queue:email
LRANGE queue:email 0 19
LLEN queue:email

大きなListで LRANGE key 0 -1 を実行すると大量データを返します。本番では範囲を制限します。信頼性の必要なキューでは、失敗時の再試行、確認応答、重複処理を設計できるRedis Streamsなども検討します。

Set

Setは重複しない文字列の集合です。

SADD course:1:members user-1 user-2
SISMEMBER course:1:members user-1
SMEMBERS course:1:members
SCARD course:1:members
SREM course:1:members user-2

集合演算も利用できます。

SINTER course:1:members course:2:members
SUNION course:1:members course:2:members
SDIFF course:1:members course:2:members

大きなSetでは SMEMBERS や巨大な集合演算が負荷になります。反復には SSCAN、重い集計はデータ量と実行場所を確認します。

Sorted Set

スコア順のランキングや期限順の一覧に使います。

ZADD ranking 120 user-1 95 user-2
ZRANGE ranking 0 9 REV WITHSCORES
ZSCORE ranking user-1
ZINCRBY ranking 10 user-2
ZREM ranking user-1

同じスコアではメンバー文字列の辞書順が関係します。順位条件、同点の扱い、スコアの精度を用途に合わせて設計します。

SCAN

SCAN 0 MATCH user:* COUNT 100

戻り値は「次のカーソル」と「今回のキー一覧」です。返されたカーソルが 0 になるまで繰り返します。

COUNT は返却件数の保証ではなく処理量の目安です。反復中にデータが変わると、重複して返る場合や結果が一定でない場合があります。重複しても安全な処理にします。

redis-cli --scan --pattern 'user:*'

KEYS pattern はキー空間全体を一度に走査し、データ量によってサーバーを長くブロックする可能性があります。デバッグ目的でも本番では避けます。

削除

EXISTS cache:page:1
TYPE cache:page:1
UNLINK cache:page:1

DEL は削除処理を同期的に行います。大きなList・Hash・Setなどは UNLINK により実体の解放を非同期化できます。ただし、キー自体は直ちに見えなくなります。

FLUSHDB は選択DB、FLUSHALL は全DBのキーを削除します。実行前にバックアップ・復元要件、接続先、レプリカやClusterへの影響を確認します。通常のアプリ運用では、これらを実行できない権限設計を検討します。

トランザクション

MULTI
INCR account:1:points
SADD campaign:members user-1
EXEC

MULTI 後のコマンドはキューに入り、EXEC で順番に実行されます。中止する場合は DISCARD を使います。

WATCH stock:item-1
GET stock:item-1
MULTI
DECR stock:item-1
EXEC

WATCH したキーが EXEC 前に変更されると、トランザクションは実行されません。アプリ側で結果を確認し、必要なら上限付きで再試行します。

Redisのトランザクションは、一般的なRDBのようなロールバック機能を提供しません。EXEC 中に一部コマンドが実行時エラーになっても、他のコマンドが取り消されるわけではありません。複数操作の条件付き原子実行にはLuaスクリプトも選択肢ですが、長時間処理はサーバーをブロックします。

単一コマンドで表現できる処理は、トランザクションより単一コマンドを優先します。たとえばカウンターの更新は、GET 後に計算して SET するより INCRBY の方が競合を避けられます。

INCRBY article:1:view_count 1
SET lock:report worker-1 NX EX 30

SET ... NX EX ... は条件付き保存と期限設定を1回で行います。ただし、分散ロックには所有者だけが解除できる仕組み、期限切れ、処理時間超過などの設計が必要です。単純な DEL lock:report だけでは、別の処理が取得し直したロックを消す危険があります。

複数キーを使う操作はRedis Clusterで配置制約を受ける場合があります。Cluster利用時は、キーのハッシュスロットと利用コマンドの制約を公式資料で確認します。

運用確認

INFO memory
INFO stats
DBSIZE
SLOWLOG GET 10

メモリ上限と削除ポリシー、TTLのないキー、ヒット率、遅いコマンドを監視します。MONITOR は全コマンドを表示して負荷と秘密情報露出の原因になり得るため、本番で常用しません。

永続化にはRDBスナップショットとAOFがあります。可用性、許容できるデータ損失、復旧時間に合わせて構成し、バックアップを別の障害領域へ保管します。バックアップ取得だけで終わらせず、別環境への復元を定期的に検証します。

参考リソース

• Redis documentation
• Redis commands
• redis-cli
• Transactions
• SCAN

×

PR

×

PR